https://wiki.mozilla.org/api.php?action=feedcontributions&user=Dbaron&feedformat=atomMozillaWiki - User contributions [en]2024-03-29T07:29:24ZUser contributionsMediaWiki 1.27.4https://wiki.mozilla.org/index.php?title=Modules/Core&diff=1233775Modules/Core2021-02-18T00:15:18Z<p>Dbaron: transfer ownership of Layout from me to Daniel Holbert</p>
<hr />
<div><noinclude><br />
'''Only module owners may edit this page.''' <br />
<br />
They may:<br />
<br />
* update any information about their module except the name of the owner<br />
* add or remove sub-modules<br />
* change the owner of a sub-module <br />
* add emeritus owners or peers<br />
<br />
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].<br />
</noinclude><br />
{{Module<br />
|name=Accessibility<br />
|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.<br />
|owner=[mailto:jteh@mozilla.com Jamie Teh]<br />
|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]<br />
|ownersemeritus=[mailto:aaron@moonset.net. Aaron Leventhal], [mailto:surkov.alexander@gmail.com Alexander Surkov]<br />
|peersemeritus=[mailto:dbolter@mozilla.com David Bolter], [mailto:tbsaunde+mozbugs@tbsaunde.org Trevor Saunders], [mailto:ginn.chen@oracle.com Ginn Chen], Evan Yan<br />
|group=dev-accessibility<br />
|source_dirs=accessible/<br />
|url=http://www.mozilla.org/access/<br />
|components=Core::Disability Access APIs<br />
}}<br />
<br />
{{Module<br />
|name=Animation<br />
|description=Declarative animations: CSS animations, CSS transitions, Web Animations API, and off-main thread animations.<br />
|owner=[mailto:brian@birchill.co.jp Brian Birtles] (:birtles)<br />
|peers=[mailto:boris@mozilla.com Boris Chiou] (:boris), [mailto:hikezoe.birchill@mozilla.com Hiroyuki Ikezoe] (:hiro), [mailto:mwoodrow@mozilla.com Matt Woodrow] (:mattwoodrow)<br />
|group=dev-tech-layout<br />
|source_dirs=dom/animation; and animation-related and interpolation-related code in layout/style, gfx/layers, servo/components/style and servo/ports/gecko<br />
|components=Core::DOM::Animation, Core::CSS Transitions and Animations<br />
}}<br />
<br />
{{Module<br />
|name=Anti-Tracking<br />
|description=Tracking detection and content-blocking.<br />
|owner=[mailto:amarchesini@Mozilla.com Andrea Marchesini]<br />
|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]<br />
|group=dev-platform<br />
|source_dirs=toolkit/components/antitracking/, several files under browser/ and netwerk/url-classifier/<br />
|components=Core::Privacy: Anti-Tracking<br />
}}<br />
<br />
{{Module<br />
|name=Browser WebAPI<br />
|description=Web API for rendering apps, browser windows and widgets.<br />
|owner=[mailto:Olli.Pettay@helsinki.fi Olli Pettay]<br />
|peers=[mailto:fabrice@mozilla.com Fabrice Desré]<br />
|ownersemeritus=[mailto:kchen@mozilla.com Kan-Ru Chen]<br />
|group=dev-webapi<br />
|source_dirs=dom/browser-element/<br />
|url=<br />
|components=Core::DOM<br />
}}<br />
<br />
{{Module<br />
|name=Build and Release Tools<br />
|description=Tools related to build and release automation and configuration of release builds.<br />
|owner=[mailto:nthomas@mozilla.com Nick Thomas]<br />
|peers=[mailto:bhearsum@mozilla.com Ben Hearsum], [mailto:coop@mozilla.com Chris Cooper]<br />
|group=release-engineering<br />
|source_dirs=browser/config/mozconfigs/, mobile/android/config/mozconfigs/, xulrunner/config/mozconfigs/, b2g/config/, tools/update-packaging/<br />
|url=https://wiki.mozilla.org/ReleaseEngineering<br />
|components=Release Engineering::*<br />
}}<br />
<br />
{{Module<br />
|name=Build Config<br />
|description=The build system for Gecko and several mozilla.org hosted Gecko-based applications.<br />
|owner=[mailto:mh@glandium.org Mike Hommey] (:glandium)<br />
|peers=[mailto:dmajor@mozilla.com David Major] (:dmajor), [mailto:mhentges@mozilla.com Mitchell Hentges]<br />
|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]), <br />
|peersemeritus=Ted Mielczarek, Ralph Giles, Gregory Szorc, Chris Manchester, Mike Shal, Nathan Froyd, Ricky Stewart<br />
|group=dev-builds<br />
|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/<br />
|url=http://www.mozilla.org/build/<br />
|components=Core::Build Config<br />
}}<br />
<br />
{{Module<br />
|name=Code Analysis and Debugging Tools<br />
|description=Tools for debugging Mozilla code or for analyzing speed, memory use, and other characteristics of it.<br />
|owner=[mailto:dbaron@dbaron.org David Baron]<br />
|peers=<br />
|group=dev-performance<br />
|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/, <br />
|url=<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=Content Security<br />
|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.<br />
|owner=[mailto:ckerschbaumer@mozilla.com Christoph Kerschbaumer]<br />
|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]<br />
|peersemeritus=[mailto:mozilla@sidstamm.com Sid Stamm], [mailto:jonas@sicking.cc Jonas Sicking], François Marier<br />
|group=dev-security<br />
|source_dirs=dom/security<br />
|components=Core::DOM: Security<br />
}}<br />
<br />
{{Module<br />
|name=Cookies<br />
|description=<br />
|owner=[mailto:amarchesini@mozilla.com Andrea Marchesini]<br />
|peers=[mailto:ehsan@mozilla.com Ehsan Akhgari], [mailto:honzab.moz@firemni.cz Honza Bambas] <br />
|ownersemeritus=Monica Chew<br />
|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)]<br />
|group=dev-platform<br />
|source_dirs=netwerk/cookie/<br />
|url=<br />
|components=Core::Networking: Cookies<br />
}}<br />
<br />
{{Module<br />
|name=Permissions<br />
|description=<br />
|owner=[mailto:ehsan@mozilla.com Ehsan Akhgari]<br />
|peers=[mailto:amarchesini@mozilla.com Andrea Marchesini], [mailto:honzab.moz@firemni.cz Honza Bambas]<br />
|ownersemeritus=Monica Chew<br />
|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)]<br />
|group=dev-platform<br />
|source_dirs=extensions/permissions/<br />
|url=<br />
|components=Core :: Permission Manager<br />
}}<br />
<br />
{{Module<br />
|name=Cycle Collector<br />
|description=Code to break and collect objects within reference cycles<br />
|owner=[https://mozillians.org/en-US/u/mccr8/ Andrew McCreight]<br />
|peers=Peter Van der Beken, Olli Pettay<br />
|peersemeritus=David Baron<br />
|source_dirs=xpcom/base/nsCycleCollector.* and some support headers<br />
|components=Core::XPCOM<br />
|group=dev-platform<br />
}}<br />
{{Module<br />
|name=C++/Rust usage, tools, and style<br />
|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<br />
|owner=[mailto:eakhgari@mozilla.com Ehsan Akhgari]<br />
|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]<br />
|source_dirs=non-third-party C++ and Rust code in the tree<br />
|components=Various components<br />
|group=dev-platform<br />
}}<br />
{{Module<br />
|name=docshell<br />
|description=<br />
|owner=[mailto:Olli.Pettay@helsinki.fi Olli Pettay], [mailto:nika@thelayzells.com Nika Layzell]<br />
|peers=[mailto:peterv@propagandism.org Peter Van der Beken], [mailto:afarre@mozilla.com Andreas Farre]<br />
|ownersemeritus=[mailto:bzbarsky@mit.edu Boris Zbarsky]<br />
|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]<br />
|group=dev-platform<br />
|source_dirs=docshell/, uriloader/<br />
|url=<br />
|components=Core::Document Navigation<br />
}}<br />
<br />
{{Module<br />
|name=Document Object Model<br />
|description=<br />
|owner=[mailto:peterv@propagandism.org Peter Van der Beken]<br />
|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],<br />
[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]<br />
|ownersemeritus=[mailto:jstenback@gmail.com Johnny Stenback]<br />
|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]<br />
|group=dev-tech-dom<br />
|source_dirs=dom/*, except directories covered by other modules<br />
|url=http://developer.mozilla.org/en/docs/DOM<br />
|components=Core::DOM, Core::DOM: CSS Object Model, Core::DOM: Core & HTML<br />
}}<br />
<br />
{{Module<br />
|name=DOM File<br />
|description=DOM Blob, File and FileSystem APIs <br />
|owner=[mailto:amarchesini@Mozilla.com Andrea Marchesini]<br />
|peers=[mailto:olli@pettay.fi Olli Pettay]<br />
|group=dev-platform<br />
|source_dirs=dom/file, dom/filesystem<br />
|url=http://developer.mozilla.org/en/docs/DOM<br />
|components=Core::DOM: File<br />
}}<br />
<br />
{{Module<br />
|name=Event Handling<br />
|description=DOM Events and Event Handling <br />
|owner=[mailto:olli@pettay.fi Olli Pettay], [mailto:masayuki@d-toybox.com Masayuki Nakano]<br />
|peers=[mailto:echen@mozilla.com Edgar Chen]<br />
|peersemeritus=[mailto:sshih@mozilla.com Stone Shih]<br />
|group=dev-platform<br />
|source_dirs=dom/events and event handling related code elsewhere <br />
|url=http://developer.mozilla.org/en/docs/DOM<br />
|components=Core::DOM: Events, Core::DOM: UI Events & Focus Handling<br />
}}<br />
<br />
{{Module<br />
|name=Web Workers<br />
|description=<br />
|owner=[mailto:asuth@mozilla.com Andrew Sutherland]<br />
|peers=[mailto:baku@mozilla.com Andrea Marchesini], [mailto:ytausky@mozilla.com Yaron Tausky]<br />
|ownersemeritus=[mailto:bent.mozilla@gmail.com Ben Turner]<br />
|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]<br />
|group=dev-platform<br />
|source_dirs=dom/workers/<br />
|url=https://developer.mozilla.org/En/Using_web_workers<br />
|components=Core::DOM: Workers<br />
}}<br />
<br />
{{Module<br />
|name=IndexedDB<br />
|description=<br />
|owner=[mailto:jvarga@mozilla.com Jan Varga]<br />
|peers=[mailto:btseng@mozilla.com Bevis Tseng], [mailto:bugmail@asutherland.org Andrew Sutherland], [mailto:baku@mozilla.com Andrea Marchesini]<br />
|ownersemeritus=[mailto:bent.mozilla@gmail.com Ben Turner]<br />
|peersemeritus=[mailto:jonas@sicking.cc Jonas Sicking], [mailto:me@kylehuey.com Kyle Huey]<br />
|group=dev-platform<br />
|source_dirs=dom/indexedDB/<br />
|url=https://developer.mozilla.org/en/IndexedDB<br />
|components=Core::DOM: IndexedDB<br />
}}<br />
<br />
{{Module<br />
|name=Editor<br />
|description=<br />
|owner=[mailto:masayuki@d-toybox.com Masayuki Nakano]<br />
|peers=[mailto:m_kato@ga2.so-net.ne.jp Makoto Kato]<br />
|ownersemeritus=[mailto:ehsan@mozilla.com Ehsan Akhgari]<br />
|group=dev-platform<br />
|source_dirs=editor/<br />
|url=http://www.mozilla.org/editor/<br />
|components=Core::Editor<br />
}}<br />
<br />
{{Module<br />
|name=Gecko Profiler<br />
|description=Gecko's built-in profiler<br />
|owner=[mailto:mstange@themasta.com Markus Stange]<br />
|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).<br />
|ownersemeritus=[mailto:b56girard@gmail.com Benoit Girard]<br />
|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<br />
|group=dev-platform<br />
|source_dirs=tools/profiler/<br />
|url=https://developer.mozilla.org/en-US/docs/Mozilla/Performance/Profiling_with_the_Built-in_Profiler<br />
|components=Core::Gecko Profiler<br />
}}<br />
<br />
{{Module<br />
|name=Global Key Bindings<br />
|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.<br />
|owner=[mailto:masayuki@d-toybox.com Masayuki Nakano]<br />
|peers=[mailto:neil@parkwaycc.co.uk Neil Rashbrook]<br />
|group=dev-accessibility<br />
|source_dirs=dom/events (and platform specific directories under it)<br />
|url=http://www.mozilla.org/projects/ui/accessibility/mozkeyintro.html<br />
|components=Core::Keyboard: Navigation<br />
}}<br />
<br />
{{Module<br />
|name=Graphics<br />
|description=Mozilla graphics API<br />
|owner=[mailto:jrmuizel@mozilla.com Jeff Muizelaar](Thebes, QCMS, YCbCr, Cairo/Pixman, Regions, OS X, Other)<br />
|ownersemeritus=[mailto:robert@ocallahan.org Robert O'Callahan]<br />
|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)<br />
|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]<br />
|group=dev-platform<br />
|source_dirs=gfx/, dom/canvas/<br />
|url=https://wiki.mozilla.org/Platform/GFX https://wiki.mozilla.org/Gecko:Layers https://wiki.mozilla.org/Gecko:2DGraphicsSketch<br />
|components=Core::Graphics, Core::Graphics: Layers, Core::Graphics: Text, Core::Graphics: WebRender, Core::GFX: Color Management, Core::Canvas: 2D, Core::Canvas: WebGL<br />
}}<br />
<br />
{{Module<br />
|name=WebGPU (Graphics submodule)<br />
|description=WebGPU implementation<br />
|owner=[mailto:dmalyshau@mozilla.com Dzmitry Malyshau]<br />
|peers=[mailto:josh@joshgroves.com Joshua Groves], [mailto:jgilbert@mozilla.com Jeff Gilbert],<br />
|group=dev-platform<br />
|source_dirs=dom/webgpu<br />
|url=https://wiki.mozilla.org/Platform/GFX/WebGPU<br />
|components=Core::Graphics::WebGPU<br />
}}<br />
<br />
{{Module<br />
|name=APZ (Graphics submodule)<br />
|description=Asynchronous panning and zooming<br />
|owner=[mailto:bballo@mozilla.com Botond Ballo]<br />
|ownersemeritus=[mailto:kgupta@mozilla.staktrace.com Kartikaya Gupta]<br />
|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]<br />
|group=dev-platform<br />
|source_dirs=gfx/layers/apz<br />
|url=https://wiki.mozilla.org/Platform/GFX/APZ<br />
|components=Core::Panning and Zooming<br />
}}<br />
<br />
{{Module<br />
|name=Moz2D (Graphics submodule)<br />
|description=Platform independent 2D graphics API<br />
|owner=[mailto:bschouten@mozilla.com Bas Schouten]<br />
|peers=[mailto:jmuizelaar@mozilla.com Jeff Muizelaar], [mailto:gwright@mozilla.com George Wright], [mailto:jwatt@jwatt.org Jonathan Watt]<br />
|group=dev-platform<br />
|source=gfx/2d<br />
|url=https://wiki.mozilla.org/Platform/GFX/Moz2D<br />
|components=Core::Graphics<br />
}}<br />
<br />
{{Module<br />
|name=Legacy HTML Parser<br />
|description=<br />
|owner=[mailto:mrbkap@gmail.com Blake Kaplan]<br />
|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]<br />
|peersemeritus=[mailto:jstenback@gmail.com Johnny Stenback]<br />
|source_dirs=parser/htmlparser<br />
|url=http://www.mozilla.org/newlayout/doc/parser.html<br />
|components=Core::HTML: Parser<br />
}}<br />
<br />
{{Module<br />
|name=HAL<br />
|description=Hardware Abstraction Layer<br />
|owner=[mailto:gsvelto@mozilla.com Gabriele Svelto]<br />
|peers=<br />
|group=dev-platform<br />
|source_dirs=hal/<br />
|components=Core::Hardware Abstraction Layer (HAL)<br />
}}<br />
<br />
{{Module<br />
|name=HTML Parser<br />
|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++.<br />
|owner=[mailto:hsivonen@iki.fi Henri Sivonen]<br />
|peers=[mailto:wchen@mozilla.com William Chen]<br />
|group=dev-platform<br />
|source_dirs=parser/html<br />
|url=http://about.validator.nu/<br />
|components=Core::HTML: Parser<br />
}}<br />
<br />
{{Module<br />
|name=I18N Library<br />
|description=<br />
|owner=[mailto:hsivonen@hsivonen.fi Henri Sivonen (encoding)], [mailto:jfkthame@gmail.com Jonathan Kew (except to encoding)]<br />
|peers=[mailto:VYV03354@nifty.ne.jp Masatoshi Kimura], [mailto:gandalf@aviary.pl Zibi Braniecki], [mailto:m_kato@ga2.so-net.ne.jp Makoto Kato]<br />
|ownersemeritus=[mailto:jshin1987@gmail.com Jungshik Shin], [mailto:smontagu@smontagu.org Simon Montagu]<br />
|group=dev-i18n<br />
|source_dirs=intl/<br />
|url=http://mozilla.org/projects/intl/index.html<br />
|components=Core::Internationalization<br />
}}<br />
<br />
{{Module<br />
|name=ImageLib<br />
|description=<br />
|owner=[mailto:tnikkel@gmail.com Timothy Nikkel]<br />
|peers=[mailto:aosmond@mozilla.com Andrew Osmond], [mailto:jmuizelaar@mozilla.com Jeff Muizelaar]<br />
|peersemeritus=[mailto:seth.bugzilla@blackhail.net Seth Fowler], [mailto:netzen@gmail.com Brian Bondy], [mailto:justin.lebar@gmail.com Justin Lebar]<br />
|group=dev-platform<br />
|source_dirs=media/libjpeg/, media/libpng/, image/, modules/zlib/<br />
|url=<br />
|components=Core::ImageLib<br />
}}<br />
<br />
{{Module<br />
|name=IPC<br />
|description=Native message-passing between threads and processes<br />
|owner=[mailto:jld@mozilla.com Jed Davis]<br />
|ownersemeritus=Chris Jones, Bill McCloskey<br />
|peers=[mailto:nika@thelayzells.com Nika Layzell], [mailto:jmathies@mozilla.com Jim Mathies], [mailto:amccreight@mozilla.com Andrew McCreight]<br />
|peersemeritus=[mailto:benjamin@smedbergs.us Benjamin Smedberg], [mailto:bent.mozilla@gmail.com Ben Turner], David Anderson, Kan-Ru Chen, Bevis Tseng, Ben Kelly<br />
|group=dev-platform<br />
|source_dirs=ipc/glue/, ipc/ipdl/, ipc/chromium/<br />
|url=<br />
|components=Core::IPC}}<br />
<br />
{{Module<br />
|name=JavaScript<br />
|description=JavaScript engine (SpiderMonkey)<br />
|owner=[mailto:jorendorff@mozilla.com Jason Orendorff]<br />
|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:luke@mozilla.com Luke Wagner], [mailto:sunfish@mozilla.com Dan Gohman], [mailto:bobbyholley@gmail.com Bobby Holley]<br />
|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], Nicholas Nethercote<br />
|group=dev-tech-js-engine<br />
|source_dirs=js/src<br />
|url=http://www.mozilla.org/js/spidermonkey,<br />
http://developer.mozilla.org/en/docs/About_JavaScript<br />
|components=Core::JavaScript Engine<br />
}}<br />
<br />
{{Module<br />
|name=JavaScript JIT<br />
|description=JavaScript engine's JIT compilers (IonMonkey, Baseline)<br />
|owner=[mailto:jdemooij@mozilla.com Jan de Mooij]<br />
|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]<br />
|peersemeritus=[mailto:danderson@mozilla.com David Anderson], [mailto:shu@mozilla.com Shu-yu Guo], [mailto:hv1989@gmail.com Hannes Verschore]<br />
|group=dev-tech-js-engine-internals<br />
|source_dirs=js/src/jit<br />
|url=http://www.mozilla.org/js/spidermonkey<br />
|components=Core::JavaScript Engine: JIT<br />
}}<br />
<br />
{{Module<br />
|name=jsat<br />
|description=Javascript screen reader that is used in Android and B2G<br />
|owner=[mailto:eitan@monotonous.org Eitan Isaacson]<br />
|peers=[mailto:yzenevich@mozilla.com Yura Zenevich]<br />
|group=dev-accessibility<br />
|source_dirs=accessible/jsat/<br />
|url=http://www.mozilla.org/access/<br />
|components=Core::Disability Access APIs<br />
}}<br />
<br />
{{Module<br />
|name=js-ctypes<br />
|description=A foreign function interface which allows privileged JS code to interact with binary code without using XPCOM/XPConnect.<br />
|owner=[mailto:jorendorff@mozilla.com Jason Orendorff]<br />
|peers=[mailto:bobbyholley@gmail.com Bobby Holley]<br />
|group=dev-tech-js-engine<br />
|source_dirs=js/src/ctypes/<br />
|url=https://wiki.mozilla.org/JSctypes<br />
|components=Core::js-ctypes<br />
}}<br />
<br />
{{Module<br />
|name=js-tests<br />
|description=JavaScript test suite<br />
|owner=[mailto:bclary@bclary.com Bob Clary]<br />
|peers=<br />
|group=dev-tech-js-engine<br />
|source_dirs=js/tests/<br />
|url=http://www.mozilla.org/js/tests/library.html<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=Layout Engine<br />
|description=rendering tree construction, layout (reflow), etc.<br />
|owner=[mailto:dholbert@mozilla.com Daniel Holbert]<br />
|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]<br />
|ownersemeritus=[mailto:dbaron@dbaron.org David Baron]<br />
|peersemeritus=[mailto:bzbarsky@mit.edu Boris Zbarsky]<br />
|group=dev-tech-layout<br />
|source_dirs=layout/%, layout/base/, layout/build/, layout/doc/, layout/forms/, layout/generic/, layout/html/, layout/printing/, layout/tables/, layout/tools/<br />
|url=https://wiki.mozilla.org/Gecko:Overview#Layout<br />
|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<br />
}}<br />
<br />
{{Module<br />
|name=libjar<br />
|description=The JAR handling code (protocol handler, stream implementation, and zipreader/zipwriter).<br />
|owner=[mailto:aklotz@mozilla.com Aaron Klotz]<br />
|ownersemeritus=Taras Glek, Michael Wu<br />
|peers=[mailto:mnovotny@mozilla.com Michal Novotny], [mailto:vgosu@mozilla.com Valentin Gosu]<br />
|group=dev-platform<br />
|source_dirs=modules/libjar<br />
|url=<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=MathML<br />
|description=MathML is a low-level specification for describing mathematics which provides a foundation for the inclusion of mathematical expressions in Web pages.<br />
|owner=[mailto:karlt+@karlt.net Karl Tomlinson]<br />
|peers=[mailto:robert@ocallahan.org Robert O'Callahan]<br />
|group=dev-tech-mathml<br />
|source_dirs=layout/mathml/<br />
|url=http://www.mozilla.org/projects/mathml/<br />
|components=Core::MathML<br />
}}<br />
<br />
{{Module<br />
|name=Media Playback<br />
|description=HTML Media APIs, including Media Source Extensions and non-MSE video/audio element playback, and Encrypted Media Extensions. (WebRTC and WebAudio not included).<br />
|owner=[mailto:jyavenard@mozilla.com Jean-Yves Avenard]<br />
|ownersemeritus=[mailto:robert@ocallahan.org Robert O'Callahan], [mailto:cpearce@mozilla.com Chris Pearce]<br />
|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]<br />
|group=dev-media<br />
|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/<br />
|url=<br />
|components=Core::Audio/Video<br />
}}<br />
<br />
{{Module<br />
|name=Media Transport<br />
|description=Pluggable transport for real-time media<br />
|owner=[mailto:ekr@rtfm.com Eric Rescorla]<br />
|peers=[mailto:bcampen@mozilla.com Byron Campen], [mailto:abr@mozilla.com Adam Roach], [mailto:nohlmeier@mozilla.com Nils Ohlmeier]<br />
|group=dev-media<br />
|source_dirs=media/mtransport<br />
|url=<br />
|components=Core::WebRTC::Networking<br />
}}<br />
<br />
{{Module<br />
|name=Memory Allocator<br />
|description=Most things related to memory allocation in Gecko, including jemalloc, replace-malloc, DMD (dark matter detector), logalloc, etc.<br />
|owner=[mailto:mh+mozilla@glandium.org Mike Hommey]<br />
|peers=<br />
|peersemeritus=Eric Rahm, Nicholas Nethercote<br />
|group=dev-platform<br />
|source_dirs=memory/<br />
|components=Core::DMD, Core::jemalloc<br />
}}<br />
<br />
{{Module<br />
|name=mfbt<br />
|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).<br />
|owner=[mailto:jwalden@mit.edu Jeff Walden]<br />
|peers=[mailto:Ms2ger@gmail.com Ms2ger], [mailto:mh+mozilla@glandium.org Mike Hommey]<br />
|group=dev-platform<br />
|source_dirs=mfbt/<br />
|url=<br />
|components=Core::MFBT<br />
}}<br />
<br />
{{Module<br />
|name=Mozglue<br />
|description=Glue library containing various low-level functionality, including a dynamic linker for Android, a DLL block list for Windows, etc.<br />
|owner=[mailto:mh+mozilla@glandium.org Mike Hommey]<br />
|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)<br />
|group=dev-platform<br />
|source_dirs=mozglue/<br />
|components=Core::mozglue<br />
}}<br />
<br />
{{Module<br />
|name=mozilla-toplevel<br />
|description=The top level directory for the mozilla tree.<br />
|owner=[[Modules/Firefox_Technical_Leadership|Firefox Technical Leadership module]]<br />
|ownersemeritus=[mailto:brendan@mozilla.org Brendan Eich]<br />
|peers=<br />
|group=<br />
|source_dirs=tools/README<br />
|url=<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=MSCOM<br />
|description=Integration with Microsoft Distributed COM<br />
|owner=[mailto:aklotz@mozilla.com Aaron Klotz]<br />
|peers=[mailto:jteh@mozilla.com James Teh], [mailto:jmathies@mozilla.com Jim Mathies]<br />
|group=dev-platform<br />
|source_dirs=ipc/mscom/%<br />
|url=<br />
|components=Core::IPC: MSCOM}}<br />
<br />
{{Module<br />
|name=Necko<br />
|description=The Mozilla Networking Library<br />
|owner=[mailto:dd.mozilla@gmail.com Dragana Damjanovic]<br />
|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]<br />
|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]<br />
|group=dev-tech-network<br />
|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/<br />
|url=http://www.mozilla.org/projects/netlib/, https://developer.mozilla.org/en/Necko<br />
|components=Core::Networking, Core::Networking: Cache, Core::Networking: Cookies, Core::Networking: FTP, Core::Networking: File, Core::Networking: HTTP, Core::Networking: JAR, Core::Networking: Websockets<br />
}}<br />
<br />
{{Module<br />
|name=NodeJS usage, tools, and style<br />
|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.<br />
|owner=[mailto:dmosedale@mozilla.com Dan Mosedale]<br />
|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]<br />
|source_dirs=package.json, package-lock.json, node_modules and others as appropriate<br />
|components=Various components<br />
|forum=[https://wiki.mozilla.org/Firefox/firefox-dev firefox-dev], #nodejs on slack<br />
}}<br />
<br />
{{Module<br />
|name=NSPR<br />
|description=Netscape Portable Runtime<br />
|owner=[mailto:kaie@kuix.de Kai Engert]<br />
|peers=[mailto:mh@glandium.org Mike Hommey]<br />
|ownersemeritus=[mailto:wtc@google.com Wan-Teh Chang]<br />
|group=dev-tech-nspr<br />
|source_dirs=nsprpub/<br />
|url=http://www.mozilla.org/projects/nspr/<br />
http://www.mozilla.org/projects/nspr/reference/html/<br />
http://www.mozilla.org/projects/nspr/release-notes/<br />
|components=NSPR<br />
}}<br />
<br />
{{Module<br />
|name=PDF<br />
|description=Rendering code to display documents encoded in the ISO 32000-1 `PDF' format.<br />
|owner=[mailto:bdahl@mozilla.com Brendan Dahl]<br />
|peers=[mailto:aadib@mozilla.com Artur Adib], [mailto:vnicolas@mozilla.com Vivien Nicolas]<br />
|group=dev-platform<br />
|source_dirs=media/pdf/<br />
|url=https://github.com/mozilla/pdf.js<br />
|components=Core::PDF<br />
}}<br />
<br />
{{Module<br />
|name=Plugins<br />
|description= NPAPI Plugin support.<br />
|owner=[mailto:jmathies@mozilla.com Jim Mathies]<br />
|peers=[mailto:davidp99@gmail.com David Parks]<br />
|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<br />
|group=<br />
|source_dirs=dom/plugins/, modules/plugin/<br />
|url=https://wiki.mozilla.org/Plugins<br />
|components=Core::Plug-ins<br />
}}<br />
<br />
{{Module<br />
|name=Preferences<br />
|description=Preference library<br />
|owner=[mailto:kwright@mozilla.com Kris Wright]<br />
|peers=[mailto:glandium@mozilla.com Mike Hommey], [mailto:kwright@mozilla.com Kris Wright]<br />
|ownersemeritus=Nicholas Nethercote<br />
|peersemeritus=Felipe Gomes, Eric Rahm<br />
|group=dev-platform<br />
|source_dirs=modules/libpref/<br />
|url=<br />
|components=Core::Preferences: Backend<br />
}}<br />
<br />
{{Module<br />
|name=Private Browsing<br />
|description=Implementation of the Private Browsing mode, and the integration of other modules with Private Browsing APIs.<br />
|owner=[mailto:eakhgari@mozilla.com Ehsan Akhgari]<br />
|peers=[mailto:josh@joshmatthews.net Josh Matthews]<br />
|group=dev-platform<br />
|source_dirs=Implementation and consumers of Private Browsing APIs in nsILoadContext, nsIPrivateBrowsingChannel, PrivateBrowsingUtils.jsm and the related glue code. <br />
|url=https://wiki.mozilla.org/Private_Browsing<br />
|components=Firefox::Private Browsing<br />
}}<br />
<br />
{{Module<br />
|name=Privilege Manager<br />
|description="caps"<br />
|owner=[mailto:bobbyholley@gmail.com Bobby Holley]<br />
|peers=[mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:ckerschbaumer@mozilla.com Christoph Kerschbaumer]<br />
|peersemeritus=[mailto:brendan@mozilla.org Brendan Eich], [mailto:jstenback@gmail.com Johnny Stenback], [mailto:dveditz@mozilla.com Dan Veditz]<br />
|group=dev-tech-dom<br />
|source_dirs=caps/<br />
|url=http://www.mozilla.org/projects/security/components/index.html<br />
|components=Core::Security: CAPS<br />
}}<br />
<br />
{{Module<br />
|name=Push Notifications<br />
|description=Push is a way for application developers to send messages to their web applications.<br />
|owners=[mailto:lina@mozilla.com Lina Cambridge]<br />
|ownersemeritus=[mailto:doug.turner@gmail.com Doug Turner]<br />
|peers=[mailto:mt@lowentropy.net Martin Thomson], [mailto:ddamjanovic@mozilla.com Dragana Damjanovic]<br />
|peersemeritus=[mailto:nsm.nikhil@gmail.com Nikhil Marathe]<br />
|group=<br />
|source_dirs=dom/push<br />
|url=<br />
|components=Core::DOM: Push Notifications<br />
}}<br />
<br />
{{Module<br />
|name=security<br />
|description=Crypto/PKI code, including NSS (Network Security Services) and JSS (NSS for Java)<br />
|owner=[mailto:rrelyea@redhat.com Bob Relyea], [mailto:mt@lowentropy.net Martin Thomson]<br />
|ownersemeritus=[mailto:wtc@google.com Wan-Teh Chang], [mailto:ttaubert@mozilla.com Tim Taubert]<br />
|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]<br />
|peersemeritus=[mailto:emaldona@redhat.com Elio Maldonado]<br />
|group=dev-tech-crypto<br />
|source_dirs=dbm/, security/coreconf/, security/dbm/, security/jss/, security/nss/, security/tinderbox/, security/tinderlight/<br />
|url=http://mozilla.org/projects/security/pki/<br />
|components=NSS, JSS, Core::Security, Core::Security: S/MIME<br />
}}<br />
<br />
{{Module<br />
|name=Security - Mozilla PSM Glue<br />
|description=Personal Security Manager<br />
|owner=[mailto:dkeeler@mozilla.com Dana Keeler]<br />
|ownersemeritus=[mailto:kaie@kuix.de Kai Engert (2001-2012)]<br />
|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]<br />
|group=dev-tech-crypto<br />
|source_dirs=security/manager/<br />
|url=<br />
|components=Core::Security: PSM<br />
}}<br />
<br />
{{Module<br />
|name=Static analysis & rewriting for C++<br />
|description=Tools for checking C++ code looking for problems at compile time, plus tools for automated rewriting of C++ code.<br />
|owner=[mailto:andi@mozilla.com Andi-Bogdan Postelnicu]<br />
|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]<br />
|peersemeritus=[mailto:birunthan@mohanathas.com Birunthan Mohanathas]<br />
|group=dev-platform<br />
|source_dirs=build/clang-plugin, tools/rewriting among other out of tree tools<br />
|url=<br />
|components=Core::Rewriting & Analysis<br />
}}<br />
{{Module<br />
|name=storage<br />
|description=Storage APIs with a SQLite backend<br />
|owner=[mailto:mak77@bonardo.net Marco Bonardo]<br />
|peers=[mailto:bugmail@asutherland.org Andrew Sutherland], [mailto:jvarga@mozilla.com Jan Varga]<br />
|group=dev-platform<br />
|source_dirs=db/sqlite3/, storage/<br />
|url=http://developer.mozilla.org/en/docs/Storage<br />
|components=Toolkit::Storage, Core::SQL<br />
}}<br />
<br />
{{Module<br />
|name=String<br />
|description=<br />
|owner=[mailto:dbaron@dbaron.org David Baron]<br />
|peers=[mailto:erahm@mozilla.com Eric Rahm]<br />
|group=dev-tech-xpcom<br />
|source_dirs=string/, xpcom/string/<br />
|url=https://developer.mozilla.org/En/Mozilla_internal_string_guide<br />
|components=Core::String<br />
}}<br />
<br />
{{Module<br />
|name=Style System<br />
|description=CSS style sheet handling; style data computation<br />
|owner=[mailto:emilio@crisal.io Emilio Cobos Álvarez]<br />
|ownersemeritus=[mailto:dbaron@dbaron.org David Baron], [mailto:cam@mcc.id.au Cameron McCormack]<br />
|peers=[mailto:bobbyholley@gmail.com Bobby Holley], [mailto:xidorn+moz@upsuper.org Xidorn Quan]<br />
|peersemeritus=[mailto:bzbarsky@mit.edu Boris Zbarsky]<br />
|group=dev-platform<br />
|source_dirs=layout/style/, servo/<br />
|url=https://wiki.mozilla.org/Gecko:Overview#Style_System<br />
|components=Core::CSS Parsing and Computation<br />
}}<br />
<br />
{{Module<br />
|name=SVG<br />
|description=Scalable Vector Graphics<br />
|owner=[mailto:jwatt@jwatt.org Jonathan Watt]<br />
|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]<br />
|group=dev-tech-svg<br />
|source_dirs=dom/svg/, layout/svg/, dom/smil/<br />
|url=https://developer.mozilla.org/en-US/docs/Web/SVG<br />
|components=Core::SVG<br />
}}<br />
<br />
{{Module<br />
|name=UA String<br />
|description=User Agent String<br />
|owner=[mailto:tantek@mozilla.com Tantek Çelik]<br />
|peers=[mailto:kdubost@mozilla.com Karl Dubost], [mailto:cpeterson@mozilla.com Chris Peterson], [mailto:hsivonen@mozilla.com Henri Sivonen] <br />
|group=dev-platform<br />
|source_dirs=netwerk/protocol/http/<br />
|url=https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/User-Agent/Firefox<br />
|components=Core::Networking: HTTP<br />
}}<br />
<br />
<br />
{{Module<br />
|name=View System<br />
|description=The View Manager is responsible for handling "heavyweight" rendering (some clipping, compositing) and event handling tasks.<br />
|owner=[mailto:mstange@themasta.com Markus Stange]<br />
|ownersemeritus=[mailto:robert@ocallahan.org Robert O'Callahan]<br />
|peers=[mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:dbaron@dbaron.org David Baron]<br />
|group=dev-tech-layout<br />
|source_dirs=view/<br />
|url=<br />
|components=Core::Layout: View Rendering<br />
}}<br />
<br />
{{Module<br />
|name=Web Audio<br />
|description=Support for the W3C Web Audio API specification.<br />
|owner=[mailto:padenot@mozilla.com Paul Adenot]<br />
|ownersemeritus=[mailto:ehsan@mozilla.com Ehsan Akhgari]<br />
|peers=[mailto:robert@ocallahan.org Robert O'Callahan], [mailto:karlt+@karlt.net Karl Tomlinson]<br />
|group=dev-platform<br />
|source_dirs=dom/media/webaudio<br />
|url=https://wiki.mozilla.org/Web_Audio_API<br />
|components=Core::Web Audio<br />
}}<br />
<br />
{{Module<br />
|name=Web Painting<br />
|description=painting, display lists, and layer construction<br />
|owner=[mailto:matt.woodrow@gmail.com Matt Woodrow]<br />
|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]<br />
|group=dev-tech-layout<br />
|source_dirs= layout/painting, the display list and layer related methods on nsIFrame and its subclasses<br />
|url=http://mozilla.org/newlayout/doc/ ,<br />
http://lxr.mozilla.org/mozilla/source/layout/doc/<br />
|components=Core::Layout: Web Painting<br />
}}<br />
<br />
{{Module<br />
|name=WebRTC<br />
|description=WebRTC is responsible for realtime audio and video communication, as well as related issues like low-level camera and microphone access<br />
|owner=[mailto:rjesup@mozilla.com Randell Jesup]<br />
|peers=[mailto:ekr@mozilla.com Eric Rescorla], [mailto:bcampen@mozilla.com Byron Campen] [mailto:abr@mozilla.com Adam Roach]<br />
|peersemeritus=[mailto:ehugg@cisco.com Ethan Hugg]<br />
|group=dev-media<br />
|source_dirs=netwerk/sctp (also see submodules "WebRTC Media" and "WebRTC Signaling")<br />
|url=https://wiki.mozilla.org/Media/webrtc<br />
|components=Core::WebRTC, Core::WebRTC Networking<br />
}}<br />
<br />
{{Module<br />
|name=WebVR<br />
|description=Gecko's implementation of WebVR (Virtual Reality) functionality, including API, devices, graphics and integration<br />
|owner=[mailto:kgilbert@mozilla.com Kearwood (Kip) Gilbert]<br />
|peers=[mailto:dmu@mozilla.com Daosheng Mu], [mailto:igorostizaga@mozilla.com Imanol Fernández]<br />
|peersemeritus=[mailto:vladimir@pobox.com Vladimir Vukicevic]<br />
|group=dev-platform<br />
|source_dirs=dom/vr, gfx/vr<br />
|url=https://mozvr.com/<br />
|components=Core::WebVR<br />
}}<br />
<br />
{{Module<br />
|name=Widget<br />
|description=Top level Widget<br />
|owner=[mailto:jmathies@mozilla.com Jim Mathies]<br />
|ownersemeritus=[mailto:vladimir@pobox.com Vladimir Vukicevic], [mailto:robert@ocallahan.org Robert O'Callahan]<br />
|peersemeritus=[mailto:pavlov@pavlov.net Stuart Parmenter], <br />
|group=dev-platform<br />
|source_dirs=widget/, widget/xpwidgets/<br />
|url=<br />
|components=Core::Drag and Drop, Core::Widget, Core::Printing: Setup<br />
}}<br />
<br />
{{Module<br />
|name=Widget - Android<br />
|description=Android widget support<br />
|owner=[mailto:jwillcox@mozilla.com James Willcox]<br />
|peers=<br />
|ownersemeritus=[mailto:blassey.bugs@lassey.us Brad Lassey]<br />
|group=dev-platforms-mobile<br />
|source_dirs=widget/android/, embedding/android<br />
|url=<br />
|components=Core::Widget: Android<br />
}}<br />
<br />
{{Module<br />
|name=Widget - GTK<br />
|description=GTK widget support<br />
|owner=[mailto:karlt+@karlt.net Karl Tomlinson]<br />
|peers=[mailto:stransky@redhat.com Martin Stránský]<br />
|ownersemeritus=[mailto:robert@ocallahan.org Robert O'Callahan]<br />
|group=dev-platform<br />
|source_dirs=widget/gtk/, widget/gtk2/, widget/gtksuperwin/, widget/gtkxtbin/<br />
|url=http://www.mozilla.org/unix/, http://www.gtk.org, http://www.mozilla.org/ports/gtk/<br />
|components=Core::Widget: Gtk<br />
}}<br />
<br />
{{Module<br />
|name=Widget - Headless<br />
|description=Headless widget support<br />
|owner=[mailto:bdahl@mozilla.com Brendan Dahl]<br />
|peers=<br />
|ownersemeritus=<br />
|group=dev-platform<br />
|source_dirs=widget/headless/<br />
|url=<br />
|components=Firefox::Headless<br />
}}<br />
<br />
{{Module<br />
|name=Widget - macOS<br />
|description= macOS widget support<br />
|owner=[mailto:spohl@mozilla.com Stephen A Pohl]<br />
|peers=[mailto:mstange@themasta.com Markus Stange], [mailto:haftandilian@mozilla.com Haik Aftandilian]<br />
|ownersemeritus=[mailto:robert@ocallahan.org Robert O'Callahan], [mailto:mstange@themasta.com Markus Stange]<br />
|peersemeritus=[mailto:joshmoz@gmail.com Josh Aas], [mailto:b56girard@gmail.com Benoit Girard], [mailto:smichaud@pobox.com Steven Michaud]<br />
|group=dev-platform<br />
|source_dirs=widget/cocoa/<br />
|url=<br />
|components=Core::Widget: Cocoa<br />
}}<br />
<br />
{{Module<br />
|name=Widget - Windows<br />
|description=Windows widget support<br />
|owner=[mailto:jmathies@mozilla.com Jim Mathies]<br />
|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]<br />
|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]<br />
|group=dev-platform<br />
|source_dirs=widget/windows/<br />
|url=<br />
|components=Core::Widget: Win32<br />
}}<br />
<br />
{{Module<br />
|name=XML<br />
|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.<br />
|owner=[mailto:peterv@propagandism.org Peter Van der Beken]<br />
|peers=<br />
|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]<br />
|group=dev-tech-xml<br />
|source_dirs=dom/xml/, extensions/xmlextras/, parser/expat/<br />
|url=http://www.mozilla.org/newlayout/xml/<br />
|components=Core::XML<br />
}}<br />
<br />
{{Module<br />
|name=XPApps<br />
|description=Cross-Platform Applications, mostly Navigator front end and application shell.<br />
|owner=[mailto:neil@parkwaycc.co.uk Neil Rashbrook]<br />
|peers=[mailto:dean_tessman@hotmail.com Dean Tessman], [mailto:timeless@mozdev.org Josh 'timeless' Soref]<br />
|group=dev-apps-seamonkey<br />
|source_dirs=xpfe/<br />
|url=http://www.mozilla.org/xpapps/<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=XPCOM<br />
|description=The cross-platform object model and core data structures.<br />
|owner=[mailto:nika@thelayzells.com Nika Layzell]<br />
|peers=[mailto:kmaglione@mozilla.com Kris Maglione], [mailto:sgiesecke@mozilla.com Simon Giesecke]<br />
|ownersemeritus=Benjamin Smedberg<br />
|peersemeritus=[https://mozillians.org/en-US/u/dougt/ Doug Turner], [mailto:erahm@mozilla.com Eric Rahm], <br />
|group=dev-platform<br />
|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/<br />
|url=http://developer.mozilla.org/en/XPCOM<br />
|components=Core::XPCOM<br />
}}<br />
<br />
{{Module<br />
|name=XPConnect<br />
|description=Deep Magic<br />
|owner=[mailto:bobbyholley@gmail.com Bobby Holley]<br />
|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]<br />
|peersemeritus=[mailto:gal@uci.edu Andreas Gal], [mailto:jstenback@gmail.com Johnny Stenback], [mailto:gkrizsanits@mozilla.com Gabor Krizsanits]<br />
|group=<br />
|source_dirs=js/xpconnect/<br />
|url=<br />
|components=Core::XPConnect<br />
}}<br />
<br />
{{Module<br />
|name=XPIDL<br />
|description=Cross-platform IDL compiler; produces .h C++ header files and .xpt runtime type description files from .idl interface description files.<br />
|owner=[mailto:nika@thelayzells.com Nika Layzell]<br />
|peers=[mailto:amccreight@mozilla.com Andrew McCreight]<br />
|ownersemeritus=[mailto:me@kylehuey.com Kyle Huey]<br />
|peersemeritus=[mailto:shaver@mozilla.org Mike Shaver], [mailto:timeless@mozdev.org Josh 'timeless' Soref]<br />
|group=dev-tech-xpcom<br />
|source_dirs=xpcom/typelib/<br />
|url=http://www.mozilla.org/scriptable/xpidl<br />
http://www.mozilla.org/scriptable<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=XSLT Processor<br />
|description=XSLT transformations processor<br />
|owner=[mailto:peterv@propagandism.org Peter Van der Beken]<br />
|peers=<br />
|peersemeritus=[mailto:jonas@sicking.cc Jonas Sicking], [mailto:axel@pike.org Axel Hecht], [mailto:erahm@mozilla.com Eric Rahm]<br />
|group=dev-tech-xslt<br />
|source_dirs=dom/xslt/<br />
|url=http://www.mozilla.org/projects/xslt/, http://www.w3.org/TR/xslt.html<br />
|components=Core::XSLT<br />
}}<br />
<br />
{{Module<br />
|name=Sandboxing - Windows <br />
|description=Sandboxing for the Windows platform <br />
|owner=[mailto:bobowencode@gmail.com Bob Owen] (:bobowen)<br />
|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)<br />
|ownersemeritus=[https://mozillians.org/en-US/u/TimAbraldes Tim Abraldes]<br />
|peersemeritus=[mailto:netzen@gmail.com Brian Bondy]<br />
|group=dev-platform<br />
|source_dirs=security/sandbox/win <br />
|url=https://wiki.mozilla.org/Security/Sandbox <br />
|components=Core::Security: Process Sandboxing<br />
}}<br />
<br />
{{Module<br />
|name=Sandboxing - OSX <br />
|description=Sandboxing for the OSX platform <br />
|owner=[mailto:haftandilian@mozilla.com Haik Aftandilian]<br />
|peers=<br />
|group=dev-platform <br />
|source_dirs=security/sandbox/mac <br />
|url=https://wiki.mozilla.org/Security/Sandbox <br />
|components=Core::Security: Process Sandboxing<br />
}}<br />
<br />
{{Module<br />
|name=Sandboxing - Linux<br />
|description=Sandboxing for the Linux platform<br />
|owner=[mailto:jld@mozilla.com Jed Davis]<br />
|peers=[mailto:gcp@mozilla.com Gian-Carlo Pascutto]<br />
|group=dev-platform<br />
|source_dirs=security/sandbox/linux<br />
|url=https://wiki.mozilla.org/Security/Sandbox <br />
|components=Core::Security: Process Sandboxing<br />
}}<br />
<br />
{{Module<br />
|name=Crash reporting<br />
|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.<br />
|owner=[mailto:gsvelto@mozilla.com Gabriele Svelto] (:gsvelto)<br />
|peers=<br />
|group=dev-platform<br />
|source_dirs=toolkit/crashreporter, toolkit/components/crashes, tools/crashreporter, ipc/glue/CrashReporter*, mobile/android/geckoview/src/main/java/org/mozilla/geckoview/CrashReporter.java<br />
|url=https://firefox-source-docs.mozilla.org/toolkit/crashreporter/crashreporter/index.html<br />
|components=Toolkit::Crash Reporting<br />
}}<br />
<br />
===Submodules===<br />
{{Module<br />
|name=Build Config - Fennec<br />
|description=Submodule of the build config covering Fennec's build system in mobile/android.<br />
|owner=[mailto:nalexander@mozilla.com Nicholas Alexander]<br />
|peers=Same as Build Config<br />
|group=dev-builds<br />
|components=Core::Build Config<br />
}}<br />
<br />
{{Module<br />
|name=Build Config - Taskgraph<br />
|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.<br />
|owner=[mailto:mozilla@hocat.ca Tom Prince]<br />
|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]<br />
|components=Firefox Build System::Task Configuration<br />
}}<br />
<br />
{{Module<br />
|name=WebRTC Media<br />
|description=Submodule of WebRTC responsible for access to media input devices (microphones, cameras, screen capture), as well as realtime audiovisual codecs and packetization.<br />
|owner=[mailto:rjesup@mozilla.com Randell Jesup]<br />
|peers=[mailto:jib@mozilla.com Jan-Ivar Bruaroey], [mailto:dminor@mozilla.com Dan Minor], [mailto:apehrson@mozilla.com Andreas Pehrson], <br />
|peersemeritus=[mailto:pkerr@mozilla.com Paul Kerr], [mailto:ehugg@cisco.com Ethan Hugg]<br />
|group=dev-media<br />
|source_dirs=/media/webrtc, /dom/media/webrtc, /dom/media/systemservices<br />
|url=https://wiki.mozilla.org/Media/webrtc<br />
|components=Core::WebRTC (Audio/Video)<br />
}}<br />
<br />
{{Module<br />
|name=WebRTC Signaling<br />
|description=Submodule of WebRTC responsible for implementation of PeerConnection API, WebRTC identity, and SDP/JSEP handling<br />
|owner=[mailto:bcampen@mozilla.com Byron Campen]<br />
|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]<br />
|peersemeritus=[mailto:ehugg@cisco.com Ethan Hugg]<br />
|group=dev-media<br />
|source_dirs=/media/webrtc/signaling/<br />
|url=https://wiki.mozilla.org/Media/webrtc<br />
|components=Core::WebRTC (Signaling)<br />
}}<br />
<br />
<noinclude><br />
<br />
===Unassigned Bugzilla Components===<br />
<br />
The following Bugzilla components in the Core project have not been assigned to a module (this list is not exhaustive):<br />
<br />
<pre><br />
Core::Find Backend<br />
Core::General<br />
Core::History: Global<br />
Core::Image Blocking<br />
Core::Localization<br />
Core::Networking: Domain Lists<br />
Core::Selection<br />
Core::Serializers<br />
Core::Spelling checker<br />
Core::X-remote<br />
Core::XUL<br />
</pre><br />
</noinclude></div>Dbaronhttps://wiki.mozilla.org/index.php?title=Modules/Core&diff=1225690Modules/Core2020-04-02T00:35:52Z<p>Dbaron: use peersemeritus rather than removing (layout)</p>
<hr />
<div><noinclude><br />
'''Only module owners may edit this page.''' <br />
<br />
They may:<br />
<br />
* update any information about their module except the name of the owner<br />
* add or remove sub-modules<br />
* change the owner of a sub-module <br />
* add emeritus owners or peers<br />
<br />
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].<br />
</noinclude><br />
{{Module<br />
|name=Accessibility<br />
|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.<br />
|owner=[mailto:jteh@mozilla.com Jamie Teh]<br />
|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]<br />
|ownersemeritus=[mailto:aaron@moonset.net. Aaron Leventhal], [mailto:surkov.alexander@gmail.com Alexander Surkov]<br />
|peersemeritus=[mailto:dbolter@mozilla.com David Bolter], [mailto:tbsaunde+mozbugs@tbsaunde.org Trevor Saunders], [mailto:ginn.chen@oracle.com Ginn Chen], Evan Yan<br />
|group=dev-accessibility<br />
|source_dirs=accessible/<br />
|url=http://www.mozilla.org/access/<br />
|components=Core::Disability Access APIs<br />
}}<br />
<br />
{{Module<br />
|name=Animation<br />
|description=Declarative animations: CSS animations, CSS transitions, Web Animations API, and off-main thread animations.<br />
|owner=[mailto:bbirtles@mozilla.com Brian Birtles] (:birtles)<br />
|peers=[mailto:hiro@mozilla.com Hiroyuki Ikezoe] (:hiro), [mailto:mwoodrow@mozilla.com Matt Woodrow] (:mattwoodrow)<br />
|group=dev-tech-layout<br />
|source_dirs=dom/animation; and animation-related and interpolation-related code in layout/style, gfx/layers, servo/components/style and servo/ports/gecko<br />
|components=Core::DOM::Animation, Core::CSS Transitions and Animations<br />
}}<br />
<br />
{{Module<br />
|name=Anti-Tracking<br />
|description=Tracking detection and content-blocking.<br />
|owner=[mailto:amarchesini@Mozilla.com Andrea Marchesini]<br />
|peers=[mailto:dlee@mozilla.com Dimi Lee], [mailto:ehsan@mozilla.com Ehsan Akhgari], [mailto:ewright@mozilla.com Erica Wright], [mailto:jhofmann@mozilla.com Johann Hofmann]<br />
|group=dev-platform<br />
|source_dirs=toolkit/components/antitracking/, several files under browser/ and netwerk/url-classifier/<br />
|components=Core::Privacy: Anti-Tracking<br />
}}<br />
<br />
{{Module<br />
|name=Browser WebAPI<br />
|description=Web API for rendering apps, browser windows and widgets.<br />
|owner=[mailto:Olli.Pettay@helsinki.fi Olli Pettay]<br />
|peers=[mailto:fabrice@mozilla.com Fabrice Desré]<br />
|ownersemeritus=[mailto:kchen@mozilla.com Kan-Ru Chen]<br />
|group=dev-webapi<br />
|source_dirs=dom/browser-element/<br />
|url=<br />
|components=Core::DOM<br />
}}<br />
<br />
{{Module<br />
|name=Build and Release Tools<br />
|description=Tools related to build and release automation and configuration of release builds.<br />
|owner=[mailto:nthomas@mozilla.com Nick Thomas]<br />
|peers=[mailto:bhearsum@mozilla.com Ben Hearsum], [mailto:coop@mozilla.com Chris Cooper]<br />
|group=release-engineering<br />
|source_dirs=browser/config/mozconfigs/, mobile/android/config/mozconfigs/, xulrunner/config/mozconfigs/, b2g/config/, tools/update-packaging/<br />
|url=https://wiki.mozilla.org/ReleaseEngineering<br />
|components=Release Engineering::*<br />
}}<br />
<br />
{{Module<br />
|name=Build Config<br />
|description=The build system for Gecko and several mozilla.org hosted Gecko-based applications.<br />
|owner=[mailto:mh@glandium.org Mike Hommey] (:glandium)<br />
|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)<br />
|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]), <br />
|peersemeritus=Ted Mielczarek, Ralph Giles, Gregory Szorc, Chris Manchester<br />
|group=dev-builds<br />
|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/<br />
|url=http://www.mozilla.org/build/<br />
|components=Core::Build Config<br />
}}<br />
<br />
{{Module<br />
|name=Code Analysis and Debugging Tools<br />
|description=Tools for debugging Mozilla code or for analyzing speed, memory use, and other characteristics of it.<br />
|owner=[mailto:dbaron@dbaron.org David Baron]<br />
|peers=<br />
|group=dev-performance<br />
|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/, <br />
|url=<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=Content Security<br />
|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.<br />
|owner=[mailto:ckerschbaumer@mozilla.com Christoph Kerschbaumer]<br />
|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]<br />
|peersemeritus=[mailto:mozilla@sidstamm.com Sid Stamm], [mailto:jonas@sicking.cc Jonas Sicking], François Marier<br />
|group=dev-security<br />
|source_dirs=dom/security<br />
|components=Core::DOM: Security<br />
}}<br />
<br />
{{Module<br />
|name=Cookies<br />
|description=<br />
|owner=[mailto:amarchesini@mozilla.com Andrea Marchesini]<br />
|peers=[mailto:ehsan@mozilla.com Ehsan Akhgari], [mailto:honzab.moz@firemni.cz Honza Bambas] <br />
|ownersemeritus=Monica Chew<br />
|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)]<br />
|group=dev-platform<br />
|source_dirs=netwerk/cookie/<br />
|url=<br />
|components=Core::Networking: Cookies<br />
}}<br />
<br />
{{Module<br />
|name=Permissions<br />
|description=<br />
|owner=[mailto:ehsan@mozilla.com Ehsan Akhgari]<br />
|peers=[mailto:amarchesini@mozilla.com Andrea Marchesini], [mailto:honzab.moz@firemni.cz Honza Bambas]<br />
|ownersemeritus=Monica Chew<br />
|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)]<br />
|group=dev-platform<br />
|source_dirs=extensions/permissions/<br />
|url=<br />
|components=Core :: Permission Manager<br />
}}<br />
<br />
{{Module<br />
|name=Cycle Collector<br />
|description=Code to break and collect objects within reference cycles<br />
|owner=[https://mozillians.org/en-US/u/mccr8/ Andrew McCreight]<br />
|peers=Peter Van der Beken, Olli Pettay, David Baron<br />
|source_dirs=xpcom/base/nsCycleCollector.* and some support headers<br />
|components=Core::XPCOM<br />
|group=dev-platform<br />
}}<br />
{{Module<br />
|name=C++/Rust usage, tools, and style<br />
|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<br />
|owner=[mailto:eakhgari@mozilla.com Ehsan Akhgari]<br />
|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]<br />
|source_dirs=non-third-party C++ and Rust code in the tree<br />
|components=Various components<br />
|group=dev-platform<br />
}}<br />
{{Module<br />
|name=docshell<br />
|description=<br />
|owner=[mailto:Olli.Pettay@helsinki.fi Olli Pettay], [mailto:nika@thelayzells.com Nika Layzell]<br />
|peers=[mailto:peterv@propagandism.org Peter Van der Beken], [mailto:afarre@mozilla.com Andreas Farre]<br />
|ownersemeritus=[mailto:bzbarsky@mit.edu Boris Zbarsky]<br />
|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]<br />
|group=dev-platform<br />
|source_dirs=docshell/, uriloader/<br />
|url=<br />
|components=Core::Document Navigation<br />
}}<br />
<br />
{{Module<br />
|name=Document Object Model<br />
|description=<br />
|owner=[mailto:peterv@propagandism.org Peter Van der Beken]<br />
|peers=[mailto:bzbarsky@mit.edu Boris Zbarsky], [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],<br />
[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]<br />
|ownersemeritus=[mailto:jstenback@gmail.com Johnny Stenback]<br />
|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]<br />
|group=dev-tech-dom<br />
|source_dirs=dom/*, except directories covered by other modules<br />
|url=http://developer.mozilla.org/en/docs/DOM<br />
|components=Core::DOM, Core::DOM: CSS Object Model, Core::DOM: Core & HTML<br />
}}<br />
<br />
{{Module<br />
|name=DOM File<br />
|description=DOM Blob, File and FileSystem APIs <br />
|owner=[mailto:amarchesini@Mozilla.com Andrea Marchesini]<br />
|peers=[mailto:olli@pettay.fi Olli Pettay]<br />
|group=dev-platform<br />
|source_dirs=dom/file, dom/filesystem<br />
|url=http://developer.mozilla.org/en/docs/DOM<br />
|components=Core::DOM: File<br />
}}<br />
<br />
{{Module<br />
|name=Event Handling<br />
|description=DOM Events and Event Handling <br />
|owner=[mailto:olli@pettay.fi Olli Pettay], [mailto:masayuki@d-toybox.com Masayuki Nakano]<br />
|peers=[mailto:echen@mozilla.com Edgar Chen]<br />
|peersemeritus=[mailto:sshih@mozilla.com Stone Shih]<br />
|group=dev-platform<br />
|source_dirs=dom/events and event handling related code elsewhere <br />
|url=http://developer.mozilla.org/en/docs/DOM<br />
|components=Core::DOM: Events, Core::DOM: UI Events & Focus Handling<br />
}}<br />
<br />
{{Module<br />
|name=Web Workers<br />
|description=<br />
|owner=[mailto:baku@mozilla.com Andrea Marchesini]<br />
|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]<br />
|ownersemeritus=[mailto:bent.mozilla@gmail.com Ben Turner]<br />
|group=dev-platform<br />
|source_dirs=dom/workers/<br />
|url=https://developer.mozilla.org/En/Using_web_workers<br />
|components=Core::DOM: Workers<br />
}}<br />
<br />
{{Module<br />
|name=IndexedDB<br />
|description=<br />
|owner=[mailto:jvarga@mozilla.com Jan Varga]<br />
|peers=[mailto:btseng@mozilla.com Bevis Tseng], [mailto:bugmail@asutherland.org Andrew Sutherland], [mailto:baku@mozilla.com Andrea Marchesini]<br />
|ownersemeritus=[mailto:bent.mozilla@gmail.com Ben Turner]<br />
|peersemeritus=[mailto:jonas@sicking.cc Jonas Sicking], [mailto:me@kylehuey.com Kyle Huey]<br />
|group=dev-platform<br />
|source_dirs=dom/indexedDB/<br />
|url=https://developer.mozilla.org/en/IndexedDB<br />
|components=Core::DOM: IndexedDB<br />
}}<br />
<br />
{{Module<br />
|name=Editor<br />
|description=<br />
|owner=[mailto:masayuki@d-toybox.com Masayuki Nakano]<br />
|peers=[mailto:m_kato@ga2.so-net.ne.jp Makoto Kato]<br />
|ownersemeritus=[mailto:ehsan@mozilla.com Ehsan Akhgari]<br />
|group=dev-platform<br />
|source_dirs=editor/<br />
|url=http://www.mozilla.org/editor/<br />
|components=Core::Editor<br />
}}<br />
<br />
{{Module<br />
|name=Gecko Profiler<br />
|description=Gecko's built-in profiler<br />
|owner=[mailto:mstange@themasta.com Markus Stange]<br />
|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).<br />
|ownersemeritus=[mailto:b56girard@gmail.com Benoit Girard]<br />
|peersemeritus=[mailto:shu@mozilla.com Shu-yu Guo] (JS integration), [mailto:tlee@mozilla.com Thinker Lee] (TaskTracer), [mailto:cyu@mozilla.com Cervantes Yu] (TaskTracer)<br />
|group=dev-platform<br />
|source_dirs=tools/profiler/<br />
|url=https://developer.mozilla.org/en-US/docs/Mozilla/Performance/Profiling_with_the_Built-in_Profiler<br />
|components=Core::Gecko Profiler<br />
}}<br />
<br />
{{Module<br />
|name=Global Key Bindings<br />
|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.<br />
|owner=[mailto:masayuki@d-toybox.com Masayuki Nakano]<br />
|peers=[mailto:neil@parkwaycc.co.uk Neil Rashbrook]<br />
|group=dev-accessibility<br />
|source_dirs=dom/events (and platform specific directories under it)<br />
|url=http://www.mozilla.org/projects/ui/accessibility/mozkeyintro.html<br />
|components=Core::Keyboard: Navigation<br />
}}<br />
<br />
{{Module<br />
|name=Graphics<br />
|description=Mozilla graphics API<br />
|owner=[mailto:jrmuizel@mozilla.com Jeff Muizelaar](Thebes, QCMS, YCbCr, Cairo/Pixman, Regions, OS X, Other)<br />
|ownersemeritus=[mailto:robert@ocallahan.org Robert O'Callahan]<br />
|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)<br />
|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]<br />
|group=dev-platform<br />
|source_dirs=gfx/, dom/canvas/<br />
|url=https://wiki.mozilla.org/Platform/GFX https://wiki.mozilla.org/Gecko:Layers https://wiki.mozilla.org/Gecko:2DGraphicsSketch<br />
|components=Core::Graphics, Core::Graphics: Layers, Core::Graphics: Text, Core::Graphics: WebRender, Core::GFX: Color Management, Core::Canvas: 2D, Core::Canvas: WebGL<br />
}}<br />
<br />
{{Module<br />
|name=WebGPU (Graphics submodule)<br />
|description=WebGPU implementation<br />
|owner=[mailto:dmalyshau@mozilla.com Dzmitry Malyshau]<br />
|peers=[mailto:josh@joshgroves.com Joshua Groves], [mailto:jgilbert@mozilla.com Jeff Gilbert],<br />
|group=dev-platform<br />
|source_dirs=dom/webgpu<br />
|url=https://wiki.mozilla.org/Platform/GFX/WebGPU<br />
|components=Core::Graphics::WebGPU<br />
}}<br />
<br />
{{Module<br />
|name=APZ (Graphics submodule)<br />
|description=Asynchronous panning and zooming<br />
|owner=[mailto:kgupta@mozilla.com Kartikaya Gupta]<br />
|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]<br />
|group=dev-platform<br />
|source_dirs=gfx/layers/apz<br />
|url=https://wiki.mozilla.org/Platform/GFX/APZ<br />
|components=Core::Panning and Zooming<br />
}}<br />
<br />
{{Module<br />
|name=Moz2D (Graphics submodule)<br />
|description=Platform independent 2D graphics API<br />
|owner=[mailto:bschouten@mozilla.com Bas Schouten]<br />
|peers=[mailto:jmuizelaar@mozilla.com Jeff Muizelaar], [mailto:gwright@mozilla.com George Wright], [mailto:jwatt@jwatt.org Jonathan Watt]<br />
|group=dev-platform<br />
|source=gfx/2d<br />
|url=https://wiki.mozilla.org/Platform/GFX/Moz2D<br />
|components=Core::Graphics<br />
}}<br />
<br />
{{Module<br />
|name=Legacy HTML Parser<br />
|description=<br />
|owner=[mailto:mrbkap@gmail.com Blake Kaplan]<br />
|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]<br />
|peersemeritus=[mailto:jstenback@gmail.com Johnny Stenback]<br />
|source_dirs=parser/htmlparser<br />
|url=http://www.mozilla.org/newlayout/doc/parser.html<br />
|components=Core::HTML: Parser<br />
}}<br />
<br />
{{Module<br />
|name=HAL<br />
|description=Hardware Abstraction Layer<br />
|owner=[mailto:gsvelto@mozilla.com Gabriele Svelto]<br />
|peers=<br />
|group=dev-platform<br />
|source_dirs=hal/<br />
|components=Core::Hardware Abstraction Layer (HAL)<br />
}}<br />
<br />
{{Module<br />
|name=HTML Parser<br />
|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++.<br />
|owner=[mailto:hsivonen@iki.fi Henri Sivonen]<br />
|peers=[mailto:wchen@mozilla.com William Chen]<br />
|group=dev-platform<br />
|source_dirs=parser/html<br />
|url=http://about.validator.nu/<br />
|components=Core::HTML: Parser<br />
}}<br />
<br />
{{Module<br />
|name=I18N Library<br />
|description=<br />
|owner=[mailto:hsivonen@hsivonen.fi Henri Sivonen (encoding)], [mailto:jfkthame@gmail.com Jonathan Kew (except to encoding)]<br />
|peers=[mailto:VYV03354@nifty.ne.jp Masatoshi Kimura], [mailto:gandalf@aviary.pl Zibi Braniecki], [mailto:m_kato@ga2.so-net.ne.jp Makoto Kato]<br />
|ownersemeritus=[mailto:jshin1987@gmail.com Jungshik Shin], [mailto:smontagu@smontagu.org Simon Montagu]<br />
|group=dev-i18n<br />
|source_dirs=intl/<br />
|url=http://mozilla.org/projects/intl/index.html<br />
|components=Core::Internationalization<br />
}}<br />
<br />
{{Module<br />
|name=ImageLib<br />
|description=<br />
|owner=[mailto:tnikkel@gmail.com Timothy Nikkel]<br />
|peers=[mailto:aosmond@mozilla.com Andrew Osmond], [mailto:jmuizelaar@mozilla.com Jeff Muizelaar]<br />
|peersemeritus=[mailto:seth.bugzilla@blackhail.net Seth Fowler], [mailto:netzen@gmail.com Brian Bondy], [mailto:justin.lebar@gmail.com Justin Lebar]<br />
|group=dev-platform<br />
|source_dirs=media/libjpeg/, media/libpng/, image/, modules/zlib/<br />
|url=<br />
|components=Core::ImageLib<br />
}}<br />
<br />
{{Module<br />
|name=IPC<br />
|description=Native message-passing between threads and processes<br />
|owner=[mailto:jld@mozilla.com Jed Davis]<br />
|ownersemeritus=Chris Jones, Bill McCloskey<br />
|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]<br />
|peersemeritus=[mailto:benjamin@smedbergs.us Benjamin Smedberg], [mailto:bent.mozilla@gmail.com Ben Turner], David Anderson, Kan-Ru Chen, Bevis Tseng, Ben Kelly<br />
|group=dev-platform<br />
|source_dirs=ipc/glue/, ipc/ipdl/, ipc/chromium/<br />
|url=<br />
|components=Core::IPC}}<br />
<br />
{{Module<br />
|name=JavaScript<br />
|description=JavaScript engine (SpiderMonkey)<br />
|owner=[mailto:jorendorff@mozilla.com Jason Orendorff]<br />
|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]<br />
|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<br />
|group=dev-tech-js-engine<br />
|source_dirs=js/src<br />
|url=http://www.mozilla.org/js/spidermonkey,<br />
http://developer.mozilla.org/en/docs/About_JavaScript<br />
|components=Core::JavaScript Engine<br />
}}<br />
<br />
{{Module<br />
|name=JavaScript JIT<br />
|description=JavaScript engine's JIT compilers (IonMonkey, Baseline)<br />
|owner=[mailto:jdemooij@mozilla.com Jan de Mooij]<br />
|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]<br />
|peersemeritus=[mailto:danderson@mozilla.com David Anderson], [mailto:hv1989@gmail.com Hannes Verschore]<br />
|group=dev-tech-js-engine-internals<br />
|source_dirs=js/src/jit<br />
|url=http://www.mozilla.org/js/spidermonkey<br />
|components=Core::JavaScript Engine: JIT<br />
}}<br />
<br />
{{Module<br />
|name=jsat<br />
|description=Javascript screen reader that is used in Android and B2G<br />
|owner=[mailto:eitan@monotonous.org Eitan Isaacson]<br />
|peers=[mailto:yzenevich@mozilla.com Yura Zenevich]<br />
|group=dev-accessibility<br />
|source_dirs=accessible/jsat/<br />
|url=http://www.mozilla.org/access/<br />
|components=Core::Disability Access APIs<br />
}}<br />
<br />
{{Module<br />
|name=js-ctypes<br />
|description=A foreign function interface which allows privileged JS code to interact with binary code without using XPCOM/XPConnect.<br />
|owner=[mailto:jorendorff@mozilla.com Jason Orendorff]<br />
|peers=[mailto:bobbyholley@gmail.com Bobby Holley]<br />
|group=dev-tech-js-engine<br />
|source_dirs=js/src/ctypes/<br />
|url=https://wiki.mozilla.org/JSctypes<br />
|components=Core::js-ctypes<br />
}}<br />
<br />
{{Module<br />
|name=js-tests<br />
|description=JavaScript test suite<br />
|owner=[mailto:bclary@bclary.com Bob Clary]<br />
|peers=<br />
|group=dev-tech-js-engine<br />
|source_dirs=js/tests/<br />
|url=http://www.mozilla.org/js/tests/library.html<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=Layout Engine<br />
|description=rendering tree construction, layout (reflow), etc.<br />
|owner=[mailto:dbaron@dbaron.org David Baron]<br />
|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]<br />
|peersemeritus=[mailto:bzbarsky@mit.edu Boris Zbarsky]<br />
|group=dev-tech-layout<br />
|source_dirs=layout/%, layout/base/, layout/build/, layout/doc/, layout/forms/, layout/generic/, layout/html/, layout/printing/, layout/tables/, layout/tools/<br />
|url=https://wiki.mozilla.org/Gecko:Overview#Layout<br />
|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<br />
}}<br />
<br />
{{Module<br />
|name=libjar<br />
|description=The JAR handling code (protocol handler, stream implementation, and zipreader/zipwriter).<br />
|owner=[mailto:aklotz@mozilla.com Aaron Klotz]<br />
|ownersemeritus=Taras Glek, Michael Wu<br />
|peers=[mailto:mnovotny@mozilla.com Michal Novotny], [mailto:vgosu@mozilla.com Valentin Gosu]<br />
|group=dev-platform<br />
|source_dirs=modules/libjar<br />
|url=<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=MathML<br />
|description=MathML is a low-level specification for describing mathematics which provides a foundation for the inclusion of mathematical expressions in Web pages.<br />
|owner=[mailto:karlt+@karlt.net Karl Tomlinson]<br />
|peers=[mailto:robert@ocallahan.org Robert O'Callahan]<br />
|group=dev-tech-mathml<br />
|source_dirs=layout/mathml/<br />
|url=http://www.mozilla.org/projects/mathml/<br />
|components=Core::MathML<br />
}}<br />
<br />
{{Module<br />
|name=Media Playback<br />
|description=HTML Media APIs, including Media Source Extensions and non-MSE video/audio element playback, and Encrypted Media Extensions. (WebRTC and WebAudio not included).<br />
|owner=[mailto:jyavenard@mozilla.com Jean-Yves Avenard]<br />
|ownersemeritus=[mailto:robert@ocallahan.org Robert O'Callahan], [mailto:cpearce@mozilla.com Chris Pearce]<br />
|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]<br />
|group=dev-media<br />
|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/<br />
|url=<br />
|components=Core::Audio/Video<br />
}}<br />
<br />
{{Module<br />
|name=Media Transport<br />
|description=Pluggable transport for real-time media<br />
|owner=[mailto:ekr@rtfm.com Eric Rescorla]<br />
|peers=[mailto:bcampen@mozilla.com Byron Campen], [mailto:abr@mozilla.com Adam Roach], [mailto:nohlmeier@mozilla.com Nils Ohlmeier]<br />
|group=dev-media<br />
|source_dirs=media/mtransport<br />
|url=<br />
|components=Core::WebRTC::Networking<br />
}}<br />
<br />
{{Module<br />
|name=Memory Allocator<br />
|description=Most things related to memory allocation in Gecko, including jemalloc, replace-malloc, DMD (dark matter detector), logalloc, etc.<br />
|owner=[mailto:mh+mozilla@glandium.org Mike Hommey]<br />
|peers=[mailto:n.nethercote@gmail.com Nicholas Nethercote], [mailto:erahm@mozilla.com Eric Rahm]<br />
|group=dev-platform<br />
|source_dirs=memory/<br />
|components=Core::DMD, Core::jemalloc<br />
}}<br />
<br />
{{Module<br />
|name=mfbt<br />
|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).<br />
|owner=[mailto:jwalden@mit.edu Jeff Walden]<br />
|peers=[mailto:froydnj@mozilla.com Nathan Froyd], [mailto:Ms2ger@gmail.com Ms2ger], [mailto:mh+mozilla@glandium.org Mike Hommey]<br />
|group=dev-platform<br />
|source_dirs=mfbt/<br />
|url=<br />
|components=Core::MFBT<br />
}}<br />
<br />
{{Module<br />
|name=Mozglue<br />
|description=Glue library containing various low-level functionality, including a dynamic linker for Android, a DLL block list for Windows, etc.<br />
|owner=[mailto:mh+mozilla@glandium.org Mike Hommey]<br />
|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)<br />
|group=dev-platform<br />
|source_dirs=mozglue/<br />
|components=Core::mozglue<br />
}}<br />
<br />
{{Module<br />
|name=mozilla-toplevel<br />
|description=The top level directory for the mozilla tree.<br />
|owner=[[Modules/Firefox_Technical_Leadership|Firefox Technical Leadership module]]<br />
|ownersemeritus=[mailto:brendan@mozilla.org Brendan Eich]<br />
|peers=<br />
|group=<br />
|source_dirs=tools/README<br />
|url=<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=MSCOM<br />
|description=Integration with Microsoft Distributed COM<br />
|owner=[mailto:aklotz@mozilla.com Aaron Klotz]<br />
|peers=[mailto:jteh@mozilla.com James Teh], [mailto:jmathies@mozilla.com Jim Mathies]<br />
|group=dev-platform<br />
|source_dirs=ipc/mscom/%<br />
|url=<br />
|components=Core::IPC: MSCOM}}<br />
<br />
{{Module<br />
|name=Necko<br />
|description=The Mozilla Networking Library<br />
|owner=[mailto:dd.mozilla@gmail.com Dragana Damjanovic]<br />
|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]<br />
|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]<br />
|group=dev-tech-network<br />
|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/<br />
|url=http://www.mozilla.org/projects/netlib/, https://developer.mozilla.org/en/Necko<br />
|components=Core::Networking, Core::Networking: Cache, Core::Networking: Cookies, Core::Networking: FTP, Core::Networking: File, Core::Networking: HTTP, Core::Networking: JAR, Core::Networking: Websockets<br />
}}<br />
<br />
{{Module<br />
|name=NodeJS usage, tools, and style<br />
|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.<br />
|owner=[mailto:dmosedale@mozilla.com Dan Mosedale]<br />
|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]<br />
|source_dirs=package.json, package-lock.json, node_modules and others as appropriate<br />
|components=Various components<br />
|forum=[https://wiki.mozilla.org/Firefox/firefox-dev firefox-dev], #nodejs on slack<br />
}}<br />
<br />
{{Module<br />
|name=NSPR<br />
|description=Netscape Portable Runtime<br />
|owner=[mailto:kaie@kuix.de Kai Engert]<br />
|peers=[mailto:mh@glandium.org Mike Hommey]<br />
|ownersemeritus=[mailto:wtc@google.com Wan-Teh Chang]<br />
|group=dev-tech-nspr<br />
|source_dirs=nsprpub/<br />
|url=http://www.mozilla.org/projects/nspr/<br />
http://www.mozilla.org/projects/nspr/reference/html/<br />
http://www.mozilla.org/projects/nspr/release-notes/<br />
|components=NSPR<br />
}}<br />
<br />
{{Module<br />
|name=PDF<br />
|description=Rendering code to display documents encoded in the ISO 32000-1 `PDF' format.<br />
|owner=[mailto:bdahl@mozilla.com Brendan Dahl]<br />
|peers=[mailto:aadib@mozilla.com Artur Adib], [mailto:vnicolas@mozilla.com Vivien Nicolas]<br />
|group=dev-platform<br />
|source_dirs=media/pdf/<br />
|url=https://github.com/mozilla/pdf.js<br />
|components=Core::PDF<br />
}}<br />
<br />
{{Module<br />
|name=Plugins<br />
|description= NPAPI Plugin support.<br />
|owner=[mailto:jmathies@mozilla.com Jim Mathies]<br />
|peers=[mailto:davidp99@gmail.com David Parks]<br />
|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<br />
|group=<br />
|source_dirs=dom/plugins/, modules/plugin/<br />
|url=https://wiki.mozilla.org/Plugins<br />
|components=Core::Plug-ins<br />
}}<br />
<br />
{{Module<br />
|name=Preferences<br />
|description=Preference library<br />
|owner=[mailto:nnethercote@mozilla.com Nicholas Nethercote]<br />
|peers=[mailto:froydnj@mozilla.com Nathan Froyd], [mailto:glandium@mozilla.com Mike Hommey], [mailto:erahm@mozilla.com Eric Rahm]<br />
|peersemeritus=Felipe Gomes<br />
|group=dev-platform<br />
|source_dirs=modules/libpref/<br />
|url=<br />
|components=Core::Preferences: Backend<br />
}}<br />
<br />
{{Module<br />
|name=Private Browsing<br />
|description=Implementation of the Private Browsing mode, and the integration of other modules with Private Browsing APIs.<br />
|owner=[mailto:eakhgari@mozilla.com Ehsan Akhgari]<br />
|peers=[mailto:josh@joshmatthews.net Josh Matthews]<br />
|group=dev-platform<br />
|source_dirs=Implementation and consumers of Private Browsing APIs in nsILoadContext, nsIPrivateBrowsingChannel, PrivateBrowsingUtils.jsm and the related glue code. <br />
|url=https://wiki.mozilla.org/Private_Browsing<br />
|components=Firefox::Private Browsing<br />
}}<br />
<br />
{{Module<br />
|name=Privilege Manager<br />
|description="caps"<br />
|owner=[mailto:bobbyholley@gmail.com Bobby Holley]<br />
|peers=[mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:ckerschbaumer@mozilla.com Christoph Kerschbaumer]<br />
|peersemeritus=[mailto:brendan@mozilla.org Brendan Eich], [mailto:jstenback@gmail.com Johnny Stenback], [mailto:dveditz@mozilla.com Dan Veditz]<br />
|group=dev-tech-dom<br />
|source_dirs=caps/<br />
|url=http://www.mozilla.org/projects/security/components/index.html<br />
|components=Core::Security: CAPS<br />
}}<br />
<br />
{{Module<br />
|name=Push Notifications<br />
|description=Push is a way for application developers to send messages to their web applications.<br />
|owners=[mailto:lina@mozilla.com Lina Cambridge]<br />
|ownersemeritus=[mailto:doug.turner@gmail.com Doug Turner]<br />
|peers=[mailto:mt@lowentropy.net Martin Thomson], [mailto:ddamjanovic@mozilla.com Dragana Damjanovic]<br />
|peersemeritus=[mailto:nsm.nikhil@gmail.com Nikhil Marathe]<br />
|group=<br />
|source_dirs=dom/push<br />
|url=<br />
|components=Core::DOM: Push Notifications<br />
}}<br />
<br />
{{Module<br />
|name=security<br />
|description=Crypto/PKI code, including NSS (Network Security Services) and JSS (NSS for Java)<br />
|owner=[mailto:rrelyea@redhat.com Bob Relyea], [mailto:mt@lowentropy.net Martin Thomson]<br />
|ownersemeritus=[mailto:wtc@google.com Wan-Teh Chang], [mailto:ttaubert@mozilla.com Tim Taubert]<br />
|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]<br />
|peersemeritus=[mailto:emaldona@redhat.com Elio Maldonado]<br />
|group=dev-tech-crypto<br />
|source_dirs=dbm/, security/coreconf/, security/dbm/, security/jss/, security/nss/, security/tinderbox/, security/tinderlight/<br />
|url=http://mozilla.org/projects/security/pki/<br />
|components=NSS, JSS, Core::Security, Core::Security: S/MIME<br />
}}<br />
<br />
{{Module<br />
|name=Security - Mozilla PSM Glue<br />
|description=Personal Security Manager<br />
|owner=[mailto:dkeeler@mozilla.com Dana Keeler]<br />
|ownersemeritus=[mailto:kaie@kuix.de Kai Engert (2001-2012)]<br />
|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]<br />
|group=dev-tech-crypto<br />
|source_dirs=security/manager/<br />
|url=<br />
|components=Core::Security: PSM<br />
}}<br />
<br />
{{Module<br />
|name=Static analysis & rewriting for C++<br />
|description=Tools for checking C++ code looking for problems at compile time, plus tools for automated rewriting of C++ code.<br />
|owner=[mailto:andi@mozilla.com Andi-Bogdan Postelnicu]<br />
|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]<br />
|peersemeritus=[mailto:birunthan@mohanathas.com Birunthan Mohanathas]<br />
|group=dev-platform<br />
|source_dirs=build/clang-plugin, tools/rewriting among other out of tree tools<br />
|url=<br />
|components=Core::Rewriting & Analysis<br />
}}<br />
{{Module<br />
|name=storage<br />
|description=Storage APIs with a SQLite backend<br />
|owner=[mailto:mak77@bonardo.net Marco Bonardo]<br />
|peers=[mailto:bugmail@asutherland.org Andrew Sutherland], [mailto:jvarga@mozilla.com Jan Varga]<br />
|group=dev-platform<br />
|source_dirs=db/sqlite3/, storage/<br />
|url=http://developer.mozilla.org/en/docs/Storage<br />
|components=Toolkit::Storage, Core::SQL<br />
}}<br />
<br />
{{Module<br />
|name=String<br />
|description=<br />
|owner=[mailto:dbaron@dbaron.org David Baron]<br />
|peers=[https://mozillians.org/en-US/u/froydnj/ Nathan Froyd], [mailto:erahm@mozilla.com Eric Rahm]<br />
|group=dev-tech-xpcom<br />
|source_dirs=string/, xpcom/string/<br />
|url=https://developer.mozilla.org/En/Mozilla_internal_string_guide<br />
|components=Core::String<br />
}}<br />
<br />
{{Module<br />
|name=Style System<br />
|description=CSS style sheet handling; style data computation<br />
|owner=[mailto:cam@mcc.id.au Cameron McCormack]<br />
|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]<br />
|group=dev-tech-layout<br />
|source_dirs=layout/style/, servo/<br />
|url=https://wiki.mozilla.org/Gecko:Overview#Style_System<br />
|components=Core::CSS Parsing and Computation<br />
}}<br />
<br />
{{Module<br />
|name=SVG<br />
|description=Scalable Vector Graphics<br />
|owner=[mailto:jwatt@jwatt.org Jonathan Watt]<br />
|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]<br />
|group=dev-tech-svg<br />
|source_dirs=dom/svg/, layout/svg/, dom/smil/<br />
|url=https://developer.mozilla.org/en-US/docs/Web/SVG<br />
|components=Core::SVG<br />
}}<br />
<br />
{{Module<br />
|name=View System<br />
|description=The View Manager is responsible for handling "heavyweight" rendering (some clipping, compositing) and event handling tasks.<br />
|owner=[mailto:mstange@themasta.com Markus Stange]<br />
|ownersemeritus=[mailto:robert@ocallahan.org Robert O'Callahan]<br />
|peers=[mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:dbaron@dbaron.org David Baron]<br />
|group=dev-tech-layout<br />
|source_dirs=view/<br />
|url=<br />
|components=Core::Layout: View Rendering<br />
}}<br />
<br />
{{Module<br />
|name=Web Audio<br />
|description=Support for the W3C Web Audio API specification.<br />
|owner=[mailto:padenot@mozilla.com Paul Adenot]<br />
|ownersemeritus=[mailto:ehsan@mozilla.com Ehsan Akhgari]<br />
|peers=[mailto:robert@ocallahan.org Robert O'Callahan], [mailto:karlt+@karlt.net Karl Tomlinson]<br />
|group=dev-platform<br />
|source_dirs=dom/media/webaudio<br />
|url=https://wiki.mozilla.org/Web_Audio_API<br />
|components=Core::Web Audio<br />
}}<br />
<br />
{{Module<br />
|name=Web Painting<br />
|description=painting, display lists, and layer construction<br />
|owner=[mailto:matt.woodrow@gmail.com Matt Woodrow]<br />
|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]<br />
|group=dev-tech-layout<br />
|source_dirs= layout/painting, the display list and layer related methods on nsIFrame and its subclasses<br />
|url=http://mozilla.org/newlayout/doc/ ,<br />
http://lxr.mozilla.org/mozilla/source/layout/doc/<br />
|components=Core::Layout: Web Painting<br />
}}<br />
<br />
{{Module<br />
|name=WebRTC<br />
|description=WebRTC is responsible for realtime audio and video communication, as well as related issues like low-level camera and microphone access<br />
|owner=[mailto:rjesup@mozilla.com Randell Jesup]<br />
|peers=[mailto:ekr@mozilla.com Eric Rescorla], [mailto:bcampen@mozilla.com Byron Campen] [mailto:abr@mozilla.com Adam Roach]<br />
|peersemeritus=[mailto:ehugg@cisco.com Ethan Hugg]<br />
|group=dev-media<br />
|source_dirs=netwerk/sctp (also see submodules "WebRTC Media" and "WebRTC Signaling")<br />
|url=https://wiki.mozilla.org/Media/webrtc<br />
|components=Core::WebRTC, Core::WebRTC Networking<br />
}}<br />
<br />
{{Module<br />
|name=WebVR<br />
|description=Gecko's implementation of WebVR (Virtual Reality) functionality, including API, devices, graphics and integration<br />
|owner=[mailto:kgilbert@mozilla.com Kearwood (Kip) Gilbert]<br />
|peers=[mailto:dmu@mozilla.com Daosheng Mu], [mailto:igorostizaga@mozilla.com Imanol Fernández]<br />
|peersemeritus=[mailto:vladimir@pobox.com Vladimir Vukicevic]<br />
|group=dev-platform<br />
|source_dirs=dom/vr, gfx/vr<br />
|url=https://mozvr.com/<br />
|components=Core::WebVR<br />
}}<br />
<br />
{{Module<br />
|name=Widget<br />
|description=Top level Widget<br />
|owner=[mailto:jmathies@mozilla.com Jim Mathies]<br />
|ownersemeritus=[mailto:vladimir@pobox.com Vladimir Vukicevic], [mailto:robert@ocallahan.org Robert O'Callahan]<br />
|peersemeritus=[mailto:pavlov@pavlov.net Stuart Parmenter], <br />
|group=dev-platform<br />
|source_dirs=widget/, widget/xpwidgets/<br />
|url=<br />
|components=Core::Drag and Drop, Core::Widget, Core::Printing: Setup<br />
}}<br />
<br />
{{Module<br />
|name=Widget - Android<br />
|description=Android widget support<br />
|owner=[mailto:jwillcox@mozilla.com James Willcox]<br />
|peers=<br />
|ownersemeritus=[mailto:blassey.bugs@lassey.us Brad Lassey]<br />
|group=dev-platforms-mobile<br />
|source_dirs=widget/android/, embedding/android<br />
|url=<br />
|components=Core::Widget: Android<br />
}}<br />
<br />
{{Module<br />
|name=Widget - GTK<br />
|description=GTK widget support<br />
|owner=[mailto:karlt+@karlt.net Karl Tomlinson]<br />
|peers=[mailto:stransky@redhat.com Martin Stránský]<br />
|ownersemeritus=[mailto:robert@ocallahan.org Robert O'Callahan]<br />
|group=dev-platform<br />
|source_dirs=widget/gtk/, widget/gtk2/, widget/gtksuperwin/, widget/gtkxtbin/<br />
|url=http://www.mozilla.org/unix/, http://www.gtk.org, http://www.mozilla.org/ports/gtk/<br />
|components=Core::Widget: Gtk<br />
}}<br />
<br />
{{Module<br />
|name=Widget - Headless<br />
|description=Headless widget support<br />
|owner=[mailto:bdahl@mozilla.com Brendan Dahl]<br />
|peers=<br />
|ownersemeritus=<br />
|group=dev-platform<br />
|source_dirs=widget/headless/<br />
|url=<br />
|components=Firefox::Headless<br />
}}<br />
<br />
{{Module<br />
|name=Widget - OS X<br />
|description= OSX widget support<br />
|owner=[mailto:spohl@mozilla.com Stephen Pohl]<br />
|peers=[mailto:mstange@themasta.com Markus Stange]<br />
|ownersemeritus=[mailto:robert@ocallahan.org Robert O'Callahan], [mailto:mstange@themasta.com Markus Stange]<br />
|peersemeritus=[mailto:joshmoz@gmail.com Josh Aas], [mailto:b56girard@gmail.com Benoit Girard], [mailto:smichaud@pobox.com Steven Michaud]<br />
|group=dev-platform<br />
|source_dirs=widget/cocoa/<br />
|url=<br />
|components=Core::Widget: Cocoa<br />
}}<br />
<br />
{{Module<br />
|name=Widget - Windows<br />
|description=Windows widget support<br />
|owner=[mailto:jmathies@mozilla.com Jim Mathies]<br />
|peers=[mailto:neil@parkwaycc.co.uk Neil Rashbrook], [mailto:robert.strong.bugs@gmail.com Rob Strong], [mailto:aklotz@mozilla.com Aaron Klotz]<br />
|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]<br />
|group=dev-platform<br />
|source_dirs=widget/windows/<br />
|url=<br />
|components=Core::Widget: Win32<br />
}}<br />
<br />
{{Module<br />
|name=XML<br />
|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.<br />
|owner=[mailto:peterv@propagandism.org Peter Van der Beken]<br />
|peers=[mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:erahm@mozilla.com Eric Rahm]<br />
|peersemeritus=[mailto:jonas@sicking.cc Jonas Sicking], [mailto:jstenback@gmail.com Johnny Stenback]<br />
|group=dev-tech-xml<br />
|source_dirs=dom/xml/, extensions/xmlextras/, parser/expat/<br />
|url=http://www.mozilla.org/newlayout/xml/<br />
|components=Core::XML<br />
}}<br />
<br />
{{Module<br />
|name=XPApps<br />
|description=Cross-Platform Applications, mostly Navigator front end and application shell.<br />
|owner=[mailto:neil@parkwaycc.co.uk Neil Rashbrook]<br />
|peers=[mailto:dean_tessman@hotmail.com Dean Tessman], [mailto:timeless@mozdev.org Josh 'timeless' Soref]<br />
|group=dev-apps-seamonkey<br />
|source_dirs=xpfe/<br />
|url=http://www.mozilla.org/xpapps/<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=XPCOM<br />
|description=The cross-platform object model and core data structures.<br />
|owner=[https://mozillians.org/en-US/u/froydnj/ Nathan Froyd]<br />
|peers=[mailto:erahm@mozilla.com Eric Rahm], [mailto:nika@thelayzells.com Nika Layzell], [mailto:kmaglione@mozilla.com Kris Maglione]<br />
|ownersemeritus=Benjamin Smedberg<br />
|peersemeritus=[https://mozillians.org/en-US/u/dougt/ Doug Turner]<br />
|group=dev-platform<br />
|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/<br />
|url=http://developer.mozilla.org/en/XPCOM<br />
|components=Core::XPCOM<br />
}}<br />
<br />
{{Module<br />
|name=XPConnect<br />
|description=Deep Magic<br />
|owner=[mailto:bobbyholley@gmail.com Bobby Holley]<br />
|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]<br />
|peersemeritus=[mailto:gal@uci.edu Andreas Gal], [mailto:jstenback@gmail.com Johnny Stenback], [mailto:gkrizsanits@mozilla.com Gabor Krizsanits]<br />
|group=<br />
|source_dirs=js/xpconnect/<br />
|url=<br />
|components=Core::XPConnect<br />
}}<br />
<br />
{{Module<br />
|name=XPIDL<br />
|description=Cross-platform IDL compiler; produces .h C++ header files and .xpt runtime type description files from .idl interface description files.<br />
|owner=[mailto:nika@thelayzells.com Nika Layzell]<br />
|peers=[mailto:nfroyd@mozilla.com Nathan Froyd], [mailto:amccreight@mozilla.com Andrew McCreight]<br />
|ownersemeritus=[mailto:me@kylehuey.com Kyle Huey]<br />
|peersemeritus=[mailto:shaver@mozilla.org Mike Shaver], [mailto:timeless@mozdev.org Josh 'timeless' Soref]<br />
|group=dev-tech-xpcom<br />
|source_dirs=xpcom/typelib/<br />
|url=http://www.mozilla.org/scriptable/xpidl<br />
http://www.mozilla.org/scriptable<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=XSLT Processor<br />
|description=XSLT transformations processor<br />
|owner=[mailto:peterv@propagandism.org Peter Van der Beken]<br />
|peers=[mailto:axel@pike.org Axel Hecht], [mailto:erahm@mozilla.com Eric Rahm]<br />
|peersemeritus=[mailto:jonas@sicking.cc Jonas Sicking]<br />
|group=dev-tech-xslt<br />
|source_dirs=dom/xslt/<br />
|url=http://www.mozilla.org/projects/xslt/, http://www.w3.org/TR/xslt.html<br />
|components=Core::XSLT<br />
}}<br />
<br />
{{Module<br />
|name=Sandboxing - Windows <br />
|description=Sandboxing for the Windows platform <br />
|owner=[mailto:bobowencode@gmail.com Bob Owen] (:bobowen)<br />
|peers=[mailto:aklotz@mozilla.com Aaron Klotz] (:aklotz), [mailto:jimm@mozilla.com Jim Mathies] (:jimm), [mailto:davidp99@gmail.com David Parks] (:handyman)<br />
|ownersemeritus=[https://mozillians.org/en-US/u/TimAbraldes Tim Abraldes]<br />
|peersemeritus=[mailto:netzen@gmail.com Brian Bondy]<br />
|group=dev-platform<br />
|source_dirs=security/sandbox/win <br />
|url=https://wiki.mozilla.org/Security/Sandbox <br />
|components=Core::Security: Process Sandboxing<br />
}}<br />
<br />
{{Module<br />
|name=Sandboxing - OSX <br />
|description=Sandboxing for the OSX platform <br />
|owner=[mailto:haftandilian@mozilla.com Haik Aftandilian]<br />
|peers=<br />
|group=dev-platform <br />
|source_dirs=security/sandbox/mac <br />
|url=https://wiki.mozilla.org/Security/Sandbox <br />
|components=Core::Security: Process Sandboxing<br />
}}<br />
<br />
{{Module<br />
|name=Sandboxing - Linux<br />
|description=Sandboxing for the Linux platform<br />
|owner=[mailto:jld@mozilla.com Jed Davis]<br />
|peers=[mailto:gcp@mozilla.com Gian-Carlo Pascutto]<br />
|group=dev-platform<br />
|source_dirs=security/sandbox/linux<br />
|url=https://wiki.mozilla.org/Security/Sandbox <br />
|components=Core::Security: Process Sandboxing<br />
}}<br />
<br />
{{Module<br />
|name=Crash reporting<br />
|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.<br />
|owner=[mailto:gsvelto@mozilla.com Gabriele Svelto] (:gsvelto)<br />
|peers=[mailto:nfroyd@mozilla.com Nathan Froyd] (:froydnj)<br />
|group=dev-platform<br />
|source_dirs=toolkit/crashreporter, toolkit/components/crashes, tools/crashreporter, ipc/glue/CrashReporter*, mobile/android/geckoview/src/main/java/org/mozilla/geckoview/CrashReporter.java<br />
|url=https://firefox-source-docs.mozilla.org/toolkit/crashreporter/crashreporter/index.html<br />
|components=Toolkit::Crash Reporting<br />
}}<br />
<br />
===Submodules===<br />
{{Module<br />
|name=Build Config - Fennec<br />
|description=Submodule of the build config covering Fennec's build system in mobile/android.<br />
|owner=[mailto:nalexander@mozilla.com Nicholas Alexander]<br />
|peers=Same as Build Config<br />
|group=dev-builds<br />
|components=Core::Build Config<br />
}}<br />
<br />
{{Module<br />
|name=Build Config - Taskgraph<br />
|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.<br />
|owner=[mailto:mozilla@hocat.ca Tom Prince]<br />
|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]<br />
|components=Firefox Build System::Task Configuration<br />
}}<br />
<br />
{{Module<br />
|name=WebRTC Media<br />
|description=Submodule of WebRTC responsible for access to media input devices (microphones, cameras, screen capture), as well as realtime audiovisual codecs and packetization.<br />
|owner=[mailto:rjesup@mozilla.com Randell Jesup]<br />
|peers=[mailto:jib@mozilla.com Jan-Ivar Bruaroey], [mailto:dminor@mozilla.com Dan Minor], [mailto:apehrson@mozilla.com Andreas Pehrson], <br />
|peersemeritus=[mailto:pkerr@mozilla.com Paul Kerr], [mailto:ehugg@cisco.com Ethan Hugg]<br />
|group=dev-media<br />
|source_dirs=/media/webrtc, /dom/media/webrtc, /dom/media/systemservices<br />
|url=https://wiki.mozilla.org/Media/webrtc<br />
|components=Core::WebRTC (Audio/Video)<br />
}}<br />
<br />
{{Module<br />
|name=WebRTC Signaling<br />
|description=Submodule of WebRTC responsible for implementation of PeerConnection API, WebRTC identity, and SDP/JSEP handling<br />
|owner=[mailto:bcampen@mozilla.com Byron Campen]<br />
|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]<br />
|peersemeritus=[mailto:ehugg@cisco.com Ethan Hugg]<br />
|group=dev-media<br />
|source_dirs=/media/webrtc/signaling/<br />
|url=https://wiki.mozilla.org/Media/webrtc<br />
|components=Core::WebRTC (Signaling)<br />
}}<br />
<br />
<noinclude><br />
<br />
===Unassigned Bugzilla Components===<br />
<br />
The following Bugzilla components in the Core project have not been assigned to a module (this list is not exhaustive):<br />
<br />
<pre><br />
Core::Find Backend<br />
Core::General<br />
Core::History: Global<br />
Core::Image Blocking<br />
Core::Localization<br />
Core::Networking: Domain Lists<br />
Core::Selection<br />
Core::Serializers<br />
Core::Spelling checker<br />
Core::X-remote<br />
Core::XUL<br />
</pre><br />
</noinclude></div>Dbaronhttps://wiki.mozilla.org/index.php?title=Modules/Core&diff=1225689Modules/Core2020-04-02T00:28:56Z<p>Dbaron: update peers for layout</p>
<hr />
<div><noinclude><br />
'''Only module owners may edit this page.''' <br />
<br />
They may:<br />
<br />
* update any information about their module except the name of the owner<br />
* add or remove sub-modules<br />
* change the owner of a sub-module <br />
* add emeritus owners or peers<br />
<br />
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].<br />
</noinclude><br />
{{Module<br />
|name=Accessibility<br />
|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.<br />
|owner=[mailto:jteh@mozilla.com Jamie Teh]<br />
|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]<br />
|ownersemeritus=[mailto:aaron@moonset.net. Aaron Leventhal], [mailto:surkov.alexander@gmail.com Alexander Surkov]<br />
|peersemeritus=[mailto:dbolter@mozilla.com David Bolter], [mailto:tbsaunde+mozbugs@tbsaunde.org Trevor Saunders], [mailto:ginn.chen@oracle.com Ginn Chen], Evan Yan<br />
|group=dev-accessibility<br />
|source_dirs=accessible/<br />
|url=http://www.mozilla.org/access/<br />
|components=Core::Disability Access APIs<br />
}}<br />
<br />
{{Module<br />
|name=Animation<br />
|description=Declarative animations: CSS animations, CSS transitions, Web Animations API, and off-main thread animations.<br />
|owner=[mailto:bbirtles@mozilla.com Brian Birtles] (:birtles)<br />
|peers=[mailto:hiro@mozilla.com Hiroyuki Ikezoe] (:hiro), [mailto:mwoodrow@mozilla.com Matt Woodrow] (:mattwoodrow)<br />
|group=dev-tech-layout<br />
|source_dirs=dom/animation; and animation-related and interpolation-related code in layout/style, gfx/layers, servo/components/style and servo/ports/gecko<br />
|components=Core::DOM::Animation, Core::CSS Transitions and Animations<br />
}}<br />
<br />
{{Module<br />
|name=Anti-Tracking<br />
|description=Tracking detection and content-blocking.<br />
|owner=[mailto:amarchesini@Mozilla.com Andrea Marchesini]<br />
|peers=[mailto:dlee@mozilla.com Dimi Lee], [mailto:ehsan@mozilla.com Ehsan Akhgari], [mailto:ewright@mozilla.com Erica Wright], [mailto:jhofmann@mozilla.com Johann Hofmann]<br />
|group=dev-platform<br />
|source_dirs=toolkit/components/antitracking/, several files under browser/ and netwerk/url-classifier/<br />
|components=Core::Privacy: Anti-Tracking<br />
}}<br />
<br />
{{Module<br />
|name=Browser WebAPI<br />
|description=Web API for rendering apps, browser windows and widgets.<br />
|owner=[mailto:Olli.Pettay@helsinki.fi Olli Pettay]<br />
|peers=[mailto:fabrice@mozilla.com Fabrice Desré]<br />
|ownersemeritus=[mailto:kchen@mozilla.com Kan-Ru Chen]<br />
|group=dev-webapi<br />
|source_dirs=dom/browser-element/<br />
|url=<br />
|components=Core::DOM<br />
}}<br />
<br />
{{Module<br />
|name=Build and Release Tools<br />
|description=Tools related to build and release automation and configuration of release builds.<br />
|owner=[mailto:nthomas@mozilla.com Nick Thomas]<br />
|peers=[mailto:bhearsum@mozilla.com Ben Hearsum], [mailto:coop@mozilla.com Chris Cooper]<br />
|group=release-engineering<br />
|source_dirs=browser/config/mozconfigs/, mobile/android/config/mozconfigs/, xulrunner/config/mozconfigs/, b2g/config/, tools/update-packaging/<br />
|url=https://wiki.mozilla.org/ReleaseEngineering<br />
|components=Release Engineering::*<br />
}}<br />
<br />
{{Module<br />
|name=Build Config<br />
|description=The build system for Gecko and several mozilla.org hosted Gecko-based applications.<br />
|owner=[mailto:mh@glandium.org Mike Hommey] (:glandium)<br />
|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)<br />
|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]), <br />
|peersemeritus=Ted Mielczarek, Ralph Giles, Gregory Szorc, Chris Manchester<br />
|group=dev-builds<br />
|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/<br />
|url=http://www.mozilla.org/build/<br />
|components=Core::Build Config<br />
}}<br />
<br />
{{Module<br />
|name=Code Analysis and Debugging Tools<br />
|description=Tools for debugging Mozilla code or for analyzing speed, memory use, and other characteristics of it.<br />
|owner=[mailto:dbaron@dbaron.org David Baron]<br />
|peers=<br />
|group=dev-performance<br />
|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/, <br />
|url=<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=Content Security<br />
|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.<br />
|owner=[mailto:ckerschbaumer@mozilla.com Christoph Kerschbaumer]<br />
|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]<br />
|peersemeritus=[mailto:mozilla@sidstamm.com Sid Stamm], [mailto:jonas@sicking.cc Jonas Sicking], François Marier<br />
|group=dev-security<br />
|source_dirs=dom/security<br />
|components=Core::DOM: Security<br />
}}<br />
<br />
{{Module<br />
|name=Cookies<br />
|description=<br />
|owner=[mailto:amarchesini@mozilla.com Andrea Marchesini]<br />
|peers=[mailto:ehsan@mozilla.com Ehsan Akhgari], [mailto:honzab.moz@firemni.cz Honza Bambas] <br />
|ownersemeritus=Monica Chew<br />
|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)]<br />
|group=dev-platform<br />
|source_dirs=netwerk/cookie/<br />
|url=<br />
|components=Core::Networking: Cookies<br />
}}<br />
<br />
{{Module<br />
|name=Permissions<br />
|description=<br />
|owner=[mailto:ehsan@mozilla.com Ehsan Akhgari]<br />
|peers=[mailto:amarchesini@mozilla.com Andrea Marchesini], [mailto:honzab.moz@firemni.cz Honza Bambas]<br />
|ownersemeritus=Monica Chew<br />
|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)]<br />
|group=dev-platform<br />
|source_dirs=extensions/permissions/<br />
|url=<br />
|components=Core :: Permission Manager<br />
}}<br />
<br />
{{Module<br />
|name=Cycle Collector<br />
|description=Code to break and collect objects within reference cycles<br />
|owner=[https://mozillians.org/en-US/u/mccr8/ Andrew McCreight]<br />
|peers=Peter Van der Beken, Olli Pettay, David Baron<br />
|source_dirs=xpcom/base/nsCycleCollector.* and some support headers<br />
|components=Core::XPCOM<br />
|group=dev-platform<br />
}}<br />
{{Module<br />
|name=C++/Rust usage, tools, and style<br />
|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<br />
|owner=[mailto:eakhgari@mozilla.com Ehsan Akhgari]<br />
|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]<br />
|source_dirs=non-third-party C++ and Rust code in the tree<br />
|components=Various components<br />
|group=dev-platform<br />
}}<br />
{{Module<br />
|name=docshell<br />
|description=<br />
|owner=[mailto:Olli.Pettay@helsinki.fi Olli Pettay], [mailto:nika@thelayzells.com Nika Layzell]<br />
|peers=[mailto:peterv@propagandism.org Peter Van der Beken], [mailto:afarre@mozilla.com Andreas Farre]<br />
|ownersemeritus=[mailto:bzbarsky@mit.edu Boris Zbarsky]<br />
|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]<br />
|group=dev-platform<br />
|source_dirs=docshell/, uriloader/<br />
|url=<br />
|components=Core::Document Navigation<br />
}}<br />
<br />
{{Module<br />
|name=Document Object Model<br />
|description=<br />
|owner=[mailto:peterv@propagandism.org Peter Van der Beken]<br />
|peers=[mailto:bzbarsky@mit.edu Boris Zbarsky], [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],<br />
[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]<br />
|ownersemeritus=[mailto:jstenback@gmail.com Johnny Stenback]<br />
|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]<br />
|group=dev-tech-dom<br />
|source_dirs=dom/*, except directories covered by other modules<br />
|url=http://developer.mozilla.org/en/docs/DOM<br />
|components=Core::DOM, Core::DOM: CSS Object Model, Core::DOM: Core & HTML<br />
}}<br />
<br />
{{Module<br />
|name=DOM File<br />
|description=DOM Blob, File and FileSystem APIs <br />
|owner=[mailto:amarchesini@Mozilla.com Andrea Marchesini]<br />
|peers=[mailto:olli@pettay.fi Olli Pettay]<br />
|group=dev-platform<br />
|source_dirs=dom/file, dom/filesystem<br />
|url=http://developer.mozilla.org/en/docs/DOM<br />
|components=Core::DOM: File<br />
}}<br />
<br />
{{Module<br />
|name=Event Handling<br />
|description=DOM Events and Event Handling <br />
|owner=[mailto:olli@pettay.fi Olli Pettay], [mailto:masayuki@d-toybox.com Masayuki Nakano]<br />
|peers=[mailto:echen@mozilla.com Edgar Chen]<br />
|peersemeritus=[mailto:sshih@mozilla.com Stone Shih]<br />
|group=dev-platform<br />
|source_dirs=dom/events and event handling related code elsewhere <br />
|url=http://developer.mozilla.org/en/docs/DOM<br />
|components=Core::DOM: Events, Core::DOM: UI Events & Focus Handling<br />
}}<br />
<br />
{{Module<br />
|name=Web Workers<br />
|description=<br />
|owner=[mailto:baku@mozilla.com Andrea Marchesini]<br />
|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]<br />
|ownersemeritus=[mailto:bent.mozilla@gmail.com Ben Turner]<br />
|group=dev-platform<br />
|source_dirs=dom/workers/<br />
|url=https://developer.mozilla.org/En/Using_web_workers<br />
|components=Core::DOM: Workers<br />
}}<br />
<br />
{{Module<br />
|name=IndexedDB<br />
|description=<br />
|owner=[mailto:jvarga@mozilla.com Jan Varga]<br />
|peers=[mailto:btseng@mozilla.com Bevis Tseng], [mailto:bugmail@asutherland.org Andrew Sutherland], [mailto:baku@mozilla.com Andrea Marchesini]<br />
|ownersemeritus=[mailto:bent.mozilla@gmail.com Ben Turner]<br />
|peersemeritus=[mailto:jonas@sicking.cc Jonas Sicking], [mailto:me@kylehuey.com Kyle Huey]<br />
|group=dev-platform<br />
|source_dirs=dom/indexedDB/<br />
|url=https://developer.mozilla.org/en/IndexedDB<br />
|components=Core::DOM: IndexedDB<br />
}}<br />
<br />
{{Module<br />
|name=Editor<br />
|description=<br />
|owner=[mailto:masayuki@d-toybox.com Masayuki Nakano]<br />
|peers=[mailto:m_kato@ga2.so-net.ne.jp Makoto Kato]<br />
|ownersemeritus=[mailto:ehsan@mozilla.com Ehsan Akhgari]<br />
|group=dev-platform<br />
|source_dirs=editor/<br />
|url=http://www.mozilla.org/editor/<br />
|components=Core::Editor<br />
}}<br />
<br />
{{Module<br />
|name=Gecko Profiler<br />
|description=Gecko's built-in profiler<br />
|owner=[mailto:mstange@themasta.com Markus Stange]<br />
|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).<br />
|ownersemeritus=[mailto:b56girard@gmail.com Benoit Girard]<br />
|peersemeritus=[mailto:shu@mozilla.com Shu-yu Guo] (JS integration), [mailto:tlee@mozilla.com Thinker Lee] (TaskTracer), [mailto:cyu@mozilla.com Cervantes Yu] (TaskTracer)<br />
|group=dev-platform<br />
|source_dirs=tools/profiler/<br />
|url=https://developer.mozilla.org/en-US/docs/Mozilla/Performance/Profiling_with_the_Built-in_Profiler<br />
|components=Core::Gecko Profiler<br />
}}<br />
<br />
{{Module<br />
|name=Global Key Bindings<br />
|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.<br />
|owner=[mailto:masayuki@d-toybox.com Masayuki Nakano]<br />
|peers=[mailto:neil@parkwaycc.co.uk Neil Rashbrook]<br />
|group=dev-accessibility<br />
|source_dirs=dom/events (and platform specific directories under it)<br />
|url=http://www.mozilla.org/projects/ui/accessibility/mozkeyintro.html<br />
|components=Core::Keyboard: Navigation<br />
}}<br />
<br />
{{Module<br />
|name=Graphics<br />
|description=Mozilla graphics API<br />
|owner=[mailto:jrmuizel@mozilla.com Jeff Muizelaar](Thebes, QCMS, YCbCr, Cairo/Pixman, Regions, OS X, Other)<br />
|ownersemeritus=[mailto:robert@ocallahan.org Robert O'Callahan]<br />
|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)<br />
|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]<br />
|group=dev-platform<br />
|source_dirs=gfx/, dom/canvas/<br />
|url=https://wiki.mozilla.org/Platform/GFX https://wiki.mozilla.org/Gecko:Layers https://wiki.mozilla.org/Gecko:2DGraphicsSketch<br />
|components=Core::Graphics, Core::Graphics: Layers, Core::Graphics: Text, Core::Graphics: WebRender, Core::GFX: Color Management, Core::Canvas: 2D, Core::Canvas: WebGL<br />
}}<br />
<br />
{{Module<br />
|name=WebGPU (Graphics submodule)<br />
|description=WebGPU implementation<br />
|owner=[mailto:dmalyshau@mozilla.com Dzmitry Malyshau]<br />
|peers=[mailto:josh@joshgroves.com Joshua Groves], [mailto:jgilbert@mozilla.com Jeff Gilbert],<br />
|group=dev-platform<br />
|source_dirs=dom/webgpu<br />
|url=https://wiki.mozilla.org/Platform/GFX/WebGPU<br />
|components=Core::Graphics::WebGPU<br />
}}<br />
<br />
{{Module<br />
|name=APZ (Graphics submodule)<br />
|description=Asynchronous panning and zooming<br />
|owner=[mailto:kgupta@mozilla.com Kartikaya Gupta]<br />
|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]<br />
|group=dev-platform<br />
|source_dirs=gfx/layers/apz<br />
|url=https://wiki.mozilla.org/Platform/GFX/APZ<br />
|components=Core::Panning and Zooming<br />
}}<br />
<br />
{{Module<br />
|name=Moz2D (Graphics submodule)<br />
|description=Platform independent 2D graphics API<br />
|owner=[mailto:bschouten@mozilla.com Bas Schouten]<br />
|peers=[mailto:jmuizelaar@mozilla.com Jeff Muizelaar], [mailto:gwright@mozilla.com George Wright], [mailto:jwatt@jwatt.org Jonathan Watt]<br />
|group=dev-platform<br />
|source=gfx/2d<br />
|url=https://wiki.mozilla.org/Platform/GFX/Moz2D<br />
|components=Core::Graphics<br />
}}<br />
<br />
{{Module<br />
|name=Legacy HTML Parser<br />
|description=<br />
|owner=[mailto:mrbkap@gmail.com Blake Kaplan]<br />
|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]<br />
|peersemeritus=[mailto:jstenback@gmail.com Johnny Stenback]<br />
|source_dirs=parser/htmlparser<br />
|url=http://www.mozilla.org/newlayout/doc/parser.html<br />
|components=Core::HTML: Parser<br />
}}<br />
<br />
{{Module<br />
|name=HAL<br />
|description=Hardware Abstraction Layer<br />
|owner=[mailto:gsvelto@mozilla.com Gabriele Svelto]<br />
|peers=<br />
|group=dev-platform<br />
|source_dirs=hal/<br />
|components=Core::Hardware Abstraction Layer (HAL)<br />
}}<br />
<br />
{{Module<br />
|name=HTML Parser<br />
|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++.<br />
|owner=[mailto:hsivonen@iki.fi Henri Sivonen]<br />
|peers=[mailto:wchen@mozilla.com William Chen]<br />
|group=dev-platform<br />
|source_dirs=parser/html<br />
|url=http://about.validator.nu/<br />
|components=Core::HTML: Parser<br />
}}<br />
<br />
{{Module<br />
|name=I18N Library<br />
|description=<br />
|owner=[mailto:hsivonen@hsivonen.fi Henri Sivonen (encoding)], [mailto:jfkthame@gmail.com Jonathan Kew (except to encoding)]<br />
|peers=[mailto:VYV03354@nifty.ne.jp Masatoshi Kimura], [mailto:gandalf@aviary.pl Zibi Braniecki], [mailto:m_kato@ga2.so-net.ne.jp Makoto Kato]<br />
|ownersemeritus=[mailto:jshin1987@gmail.com Jungshik Shin], [mailto:smontagu@smontagu.org Simon Montagu]<br />
|group=dev-i18n<br />
|source_dirs=intl/<br />
|url=http://mozilla.org/projects/intl/index.html<br />
|components=Core::Internationalization<br />
}}<br />
<br />
{{Module<br />
|name=ImageLib<br />
|description=<br />
|owner=[mailto:tnikkel@gmail.com Timothy Nikkel]<br />
|peers=[mailto:aosmond@mozilla.com Andrew Osmond], [mailto:jmuizelaar@mozilla.com Jeff Muizelaar]<br />
|peersemeritus=[mailto:seth.bugzilla@blackhail.net Seth Fowler], [mailto:netzen@gmail.com Brian Bondy], [mailto:justin.lebar@gmail.com Justin Lebar]<br />
|group=dev-platform<br />
|source_dirs=media/libjpeg/, media/libpng/, image/, modules/zlib/<br />
|url=<br />
|components=Core::ImageLib<br />
}}<br />
<br />
{{Module<br />
|name=IPC<br />
|description=Native message-passing between threads and processes<br />
|owner=[mailto:jld@mozilla.com Jed Davis]<br />
|ownersemeritus=Chris Jones, Bill McCloskey<br />
|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]<br />
|peersemeritus=[mailto:benjamin@smedbergs.us Benjamin Smedberg], [mailto:bent.mozilla@gmail.com Ben Turner], David Anderson, Kan-Ru Chen, Bevis Tseng, Ben Kelly<br />
|group=dev-platform<br />
|source_dirs=ipc/glue/, ipc/ipdl/, ipc/chromium/<br />
|url=<br />
|components=Core::IPC}}<br />
<br />
{{Module<br />
|name=JavaScript<br />
|description=JavaScript engine (SpiderMonkey)<br />
|owner=[mailto:jorendorff@mozilla.com Jason Orendorff]<br />
|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]<br />
|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<br />
|group=dev-tech-js-engine<br />
|source_dirs=js/src<br />
|url=http://www.mozilla.org/js/spidermonkey,<br />
http://developer.mozilla.org/en/docs/About_JavaScript<br />
|components=Core::JavaScript Engine<br />
}}<br />
<br />
{{Module<br />
|name=JavaScript JIT<br />
|description=JavaScript engine's JIT compilers (IonMonkey, Baseline)<br />
|owner=[mailto:jdemooij@mozilla.com Jan de Mooij]<br />
|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]<br />
|peersemeritus=[mailto:danderson@mozilla.com David Anderson], [mailto:hv1989@gmail.com Hannes Verschore]<br />
|group=dev-tech-js-engine-internals<br />
|source_dirs=js/src/jit<br />
|url=http://www.mozilla.org/js/spidermonkey<br />
|components=Core::JavaScript Engine: JIT<br />
}}<br />
<br />
{{Module<br />
|name=jsat<br />
|description=Javascript screen reader that is used in Android and B2G<br />
|owner=[mailto:eitan@monotonous.org Eitan Isaacson]<br />
|peers=[mailto:yzenevich@mozilla.com Yura Zenevich]<br />
|group=dev-accessibility<br />
|source_dirs=accessible/jsat/<br />
|url=http://www.mozilla.org/access/<br />
|components=Core::Disability Access APIs<br />
}}<br />
<br />
{{Module<br />
|name=js-ctypes<br />
|description=A foreign function interface which allows privileged JS code to interact with binary code without using XPCOM/XPConnect.<br />
|owner=[mailto:jorendorff@mozilla.com Jason Orendorff]<br />
|peers=[mailto:bobbyholley@gmail.com Bobby Holley]<br />
|group=dev-tech-js-engine<br />
|source_dirs=js/src/ctypes/<br />
|url=https://wiki.mozilla.org/JSctypes<br />
|components=Core::js-ctypes<br />
}}<br />
<br />
{{Module<br />
|name=js-tests<br />
|description=JavaScript test suite<br />
|owner=[mailto:bclary@bclary.com Bob Clary]<br />
|peers=<br />
|group=dev-tech-js-engine<br />
|source_dirs=js/tests/<br />
|url=http://www.mozilla.org/js/tests/library.html<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=Layout Engine<br />
|description=rendering tree construction, layout (reflow), etc.<br />
|owner=[mailto:dbaron@dbaron.org David Baron]<br />
|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]<br />
|group=dev-tech-layout<br />
|source_dirs=layout/%, layout/base/, layout/build/, layout/doc/, layout/forms/, layout/generic/, layout/html/, layout/printing/, layout/tables/, layout/tools/<br />
|url=https://wiki.mozilla.org/Gecko:Overview#Layout<br />
|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<br />
}}<br />
<br />
{{Module<br />
|name=libjar<br />
|description=The JAR handling code (protocol handler, stream implementation, and zipreader/zipwriter).<br />
|owner=[mailto:aklotz@mozilla.com Aaron Klotz]<br />
|ownersemeritus=Taras Glek, Michael Wu<br />
|peers=[mailto:mnovotny@mozilla.com Michal Novotny], [mailto:vgosu@mozilla.com Valentin Gosu]<br />
|group=dev-platform<br />
|source_dirs=modules/libjar<br />
|url=<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=MathML<br />
|description=MathML is a low-level specification for describing mathematics which provides a foundation for the inclusion of mathematical expressions in Web pages.<br />
|owner=[mailto:karlt+@karlt.net Karl Tomlinson]<br />
|peers=[mailto:robert@ocallahan.org Robert O'Callahan]<br />
|group=dev-tech-mathml<br />
|source_dirs=layout/mathml/<br />
|url=http://www.mozilla.org/projects/mathml/<br />
|components=Core::MathML<br />
}}<br />
<br />
{{Module<br />
|name=Media Playback<br />
|description=HTML Media APIs, including Media Source Extensions and non-MSE video/audio element playback, and Encrypted Media Extensions. (WebRTC and WebAudio not included).<br />
|owner=[mailto:jyavenard@mozilla.com Jean-Yves Avenard]<br />
|ownersemeritus=[mailto:robert@ocallahan.org Robert O'Callahan], [mailto:cpearce@mozilla.com Chris Pearce]<br />
|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]<br />
|group=dev-media<br />
|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/<br />
|url=<br />
|components=Core::Audio/Video<br />
}}<br />
<br />
{{Module<br />
|name=Media Transport<br />
|description=Pluggable transport for real-time media<br />
|owner=[mailto:ekr@rtfm.com Eric Rescorla]<br />
|peers=[mailto:bcampen@mozilla.com Byron Campen], [mailto:abr@mozilla.com Adam Roach], [mailto:nohlmeier@mozilla.com Nils Ohlmeier]<br />
|group=dev-media<br />
|source_dirs=media/mtransport<br />
|url=<br />
|components=Core::WebRTC::Networking<br />
}}<br />
<br />
{{Module<br />
|name=Memory Allocator<br />
|description=Most things related to memory allocation in Gecko, including jemalloc, replace-malloc, DMD (dark matter detector), logalloc, etc.<br />
|owner=[mailto:mh+mozilla@glandium.org Mike Hommey]<br />
|peers=[mailto:n.nethercote@gmail.com Nicholas Nethercote], [mailto:erahm@mozilla.com Eric Rahm]<br />
|group=dev-platform<br />
|source_dirs=memory/<br />
|components=Core::DMD, Core::jemalloc<br />
}}<br />
<br />
{{Module<br />
|name=mfbt<br />
|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).<br />
|owner=[mailto:jwalden@mit.edu Jeff Walden]<br />
|peers=[mailto:froydnj@mozilla.com Nathan Froyd], [mailto:Ms2ger@gmail.com Ms2ger], [mailto:mh+mozilla@glandium.org Mike Hommey]<br />
|group=dev-platform<br />
|source_dirs=mfbt/<br />
|url=<br />
|components=Core::MFBT<br />
}}<br />
<br />
{{Module<br />
|name=Mozglue<br />
|description=Glue library containing various low-level functionality, including a dynamic linker for Android, a DLL block list for Windows, etc.<br />
|owner=[mailto:mh+mozilla@glandium.org Mike Hommey]<br />
|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)<br />
|group=dev-platform<br />
|source_dirs=mozglue/<br />
|components=Core::mozglue<br />
}}<br />
<br />
{{Module<br />
|name=mozilla-toplevel<br />
|description=The top level directory for the mozilla tree.<br />
|owner=[[Modules/Firefox_Technical_Leadership|Firefox Technical Leadership module]]<br />
|ownersemeritus=[mailto:brendan@mozilla.org Brendan Eich]<br />
|peers=<br />
|group=<br />
|source_dirs=tools/README<br />
|url=<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=MSCOM<br />
|description=Integration with Microsoft Distributed COM<br />
|owner=[mailto:aklotz@mozilla.com Aaron Klotz]<br />
|peers=[mailto:jteh@mozilla.com James Teh], [mailto:jmathies@mozilla.com Jim Mathies]<br />
|group=dev-platform<br />
|source_dirs=ipc/mscom/%<br />
|url=<br />
|components=Core::IPC: MSCOM}}<br />
<br />
{{Module<br />
|name=Necko<br />
|description=The Mozilla Networking Library<br />
|owner=[mailto:dd.mozilla@gmail.com Dragana Damjanovic]<br />
|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]<br />
|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]<br />
|group=dev-tech-network<br />
|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/<br />
|url=http://www.mozilla.org/projects/netlib/, https://developer.mozilla.org/en/Necko<br />
|components=Core::Networking, Core::Networking: Cache, Core::Networking: Cookies, Core::Networking: FTP, Core::Networking: File, Core::Networking: HTTP, Core::Networking: JAR, Core::Networking: Websockets<br />
}}<br />
<br />
{{Module<br />
|name=NodeJS usage, tools, and style<br />
|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.<br />
|owner=[mailto:dmosedale@mozilla.com Dan Mosedale]<br />
|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]<br />
|source_dirs=package.json, package-lock.json, node_modules and others as appropriate<br />
|components=Various components<br />
|forum=[https://wiki.mozilla.org/Firefox/firefox-dev firefox-dev], #nodejs on slack<br />
}}<br />
<br />
{{Module<br />
|name=NSPR<br />
|description=Netscape Portable Runtime<br />
|owner=[mailto:kaie@kuix.de Kai Engert]<br />
|peers=[mailto:mh@glandium.org Mike Hommey]<br />
|ownersemeritus=[mailto:wtc@google.com Wan-Teh Chang]<br />
|group=dev-tech-nspr<br />
|source_dirs=nsprpub/<br />
|url=http://www.mozilla.org/projects/nspr/<br />
http://www.mozilla.org/projects/nspr/reference/html/<br />
http://www.mozilla.org/projects/nspr/release-notes/<br />
|components=NSPR<br />
}}<br />
<br />
{{Module<br />
|name=PDF<br />
|description=Rendering code to display documents encoded in the ISO 32000-1 `PDF' format.<br />
|owner=[mailto:bdahl@mozilla.com Brendan Dahl]<br />
|peers=[mailto:aadib@mozilla.com Artur Adib], [mailto:vnicolas@mozilla.com Vivien Nicolas]<br />
|group=dev-platform<br />
|source_dirs=media/pdf/<br />
|url=https://github.com/mozilla/pdf.js<br />
|components=Core::PDF<br />
}}<br />
<br />
{{Module<br />
|name=Plugins<br />
|description= NPAPI Plugin support.<br />
|owner=[mailto:jmathies@mozilla.com Jim Mathies]<br />
|peers=[mailto:davidp99@gmail.com David Parks]<br />
|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<br />
|group=<br />
|source_dirs=dom/plugins/, modules/plugin/<br />
|url=https://wiki.mozilla.org/Plugins<br />
|components=Core::Plug-ins<br />
}}<br />
<br />
{{Module<br />
|name=Preferences<br />
|description=Preference library<br />
|owner=[mailto:nnethercote@mozilla.com Nicholas Nethercote]<br />
|peers=[mailto:froydnj@mozilla.com Nathan Froyd], [mailto:glandium@mozilla.com Mike Hommey], [mailto:erahm@mozilla.com Eric Rahm]<br />
|peersemeritus=Felipe Gomes<br />
|group=dev-platform<br />
|source_dirs=modules/libpref/<br />
|url=<br />
|components=Core::Preferences: Backend<br />
}}<br />
<br />
{{Module<br />
|name=Private Browsing<br />
|description=Implementation of the Private Browsing mode, and the integration of other modules with Private Browsing APIs.<br />
|owner=[mailto:eakhgari@mozilla.com Ehsan Akhgari]<br />
|peers=[mailto:josh@joshmatthews.net Josh Matthews]<br />
|group=dev-platform<br />
|source_dirs=Implementation and consumers of Private Browsing APIs in nsILoadContext, nsIPrivateBrowsingChannel, PrivateBrowsingUtils.jsm and the related glue code. <br />
|url=https://wiki.mozilla.org/Private_Browsing<br />
|components=Firefox::Private Browsing<br />
}}<br />
<br />
{{Module<br />
|name=Privilege Manager<br />
|description="caps"<br />
|owner=[mailto:bobbyholley@gmail.com Bobby Holley]<br />
|peers=[mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:ckerschbaumer@mozilla.com Christoph Kerschbaumer]<br />
|peersemeritus=[mailto:brendan@mozilla.org Brendan Eich], [mailto:jstenback@gmail.com Johnny Stenback], [mailto:dveditz@mozilla.com Dan Veditz]<br />
|group=dev-tech-dom<br />
|source_dirs=caps/<br />
|url=http://www.mozilla.org/projects/security/components/index.html<br />
|components=Core::Security: CAPS<br />
}}<br />
<br />
{{Module<br />
|name=Push Notifications<br />
|description=Push is a way for application developers to send messages to their web applications.<br />
|owners=[mailto:lina@mozilla.com Lina Cambridge]<br />
|ownersemeritus=[mailto:doug.turner@gmail.com Doug Turner]<br />
|peers=[mailto:mt@lowentropy.net Martin Thomson], [mailto:ddamjanovic@mozilla.com Dragana Damjanovic]<br />
|peersemeritus=[mailto:nsm.nikhil@gmail.com Nikhil Marathe]<br />
|group=<br />
|source_dirs=dom/push<br />
|url=<br />
|components=Core::DOM: Push Notifications<br />
}}<br />
<br />
{{Module<br />
|name=security<br />
|description=Crypto/PKI code, including NSS (Network Security Services) and JSS (NSS for Java)<br />
|owner=[mailto:rrelyea@redhat.com Bob Relyea], [mailto:mt@lowentropy.net Martin Thomson]<br />
|ownersemeritus=[mailto:wtc@google.com Wan-Teh Chang], [mailto:ttaubert@mozilla.com Tim Taubert]<br />
|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]<br />
|peersemeritus=[mailto:emaldona@redhat.com Elio Maldonado]<br />
|group=dev-tech-crypto<br />
|source_dirs=dbm/, security/coreconf/, security/dbm/, security/jss/, security/nss/, security/tinderbox/, security/tinderlight/<br />
|url=http://mozilla.org/projects/security/pki/<br />
|components=NSS, JSS, Core::Security, Core::Security: S/MIME<br />
}}<br />
<br />
{{Module<br />
|name=Security - Mozilla PSM Glue<br />
|description=Personal Security Manager<br />
|owner=[mailto:dkeeler@mozilla.com Dana Keeler]<br />
|ownersemeritus=[mailto:kaie@kuix.de Kai Engert (2001-2012)]<br />
|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]<br />
|group=dev-tech-crypto<br />
|source_dirs=security/manager/<br />
|url=<br />
|components=Core::Security: PSM<br />
}}<br />
<br />
{{Module<br />
|name=Static analysis & rewriting for C++<br />
|description=Tools for checking C++ code looking for problems at compile time, plus tools for automated rewriting of C++ code.<br />
|owner=[mailto:andi@mozilla.com Andi-Bogdan Postelnicu]<br />
|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]<br />
|peersemeritus=[mailto:birunthan@mohanathas.com Birunthan Mohanathas]<br />
|group=dev-platform<br />
|source_dirs=build/clang-plugin, tools/rewriting among other out of tree tools<br />
|url=<br />
|components=Core::Rewriting & Analysis<br />
}}<br />
{{Module<br />
|name=storage<br />
|description=Storage APIs with a SQLite backend<br />
|owner=[mailto:mak77@bonardo.net Marco Bonardo]<br />
|peers=[mailto:bugmail@asutherland.org Andrew Sutherland], [mailto:jvarga@mozilla.com Jan Varga]<br />
|group=dev-platform<br />
|source_dirs=db/sqlite3/, storage/<br />
|url=http://developer.mozilla.org/en/docs/Storage<br />
|components=Toolkit::Storage, Core::SQL<br />
}}<br />
<br />
{{Module<br />
|name=String<br />
|description=<br />
|owner=[mailto:dbaron@dbaron.org David Baron]<br />
|peers=[https://mozillians.org/en-US/u/froydnj/ Nathan Froyd], [mailto:erahm@mozilla.com Eric Rahm]<br />
|group=dev-tech-xpcom<br />
|source_dirs=string/, xpcom/string/<br />
|url=https://developer.mozilla.org/En/Mozilla_internal_string_guide<br />
|components=Core::String<br />
}}<br />
<br />
{{Module<br />
|name=Style System<br />
|description=CSS style sheet handling; style data computation<br />
|owner=[mailto:cam@mcc.id.au Cameron McCormack]<br />
|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]<br />
|group=dev-tech-layout<br />
|source_dirs=layout/style/, servo/<br />
|url=https://wiki.mozilla.org/Gecko:Overview#Style_System<br />
|components=Core::CSS Parsing and Computation<br />
}}<br />
<br />
{{Module<br />
|name=SVG<br />
|description=Scalable Vector Graphics<br />
|owner=[mailto:jwatt@jwatt.org Jonathan Watt]<br />
|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]<br />
|group=dev-tech-svg<br />
|source_dirs=dom/svg/, layout/svg/, dom/smil/<br />
|url=https://developer.mozilla.org/en-US/docs/Web/SVG<br />
|components=Core::SVG<br />
}}<br />
<br />
{{Module<br />
|name=View System<br />
|description=The View Manager is responsible for handling "heavyweight" rendering (some clipping, compositing) and event handling tasks.<br />
|owner=[mailto:mstange@themasta.com Markus Stange]<br />
|ownersemeritus=[mailto:robert@ocallahan.org Robert O'Callahan]<br />
|peers=[mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:dbaron@dbaron.org David Baron]<br />
|group=dev-tech-layout<br />
|source_dirs=view/<br />
|url=<br />
|components=Core::Layout: View Rendering<br />
}}<br />
<br />
{{Module<br />
|name=Web Audio<br />
|description=Support for the W3C Web Audio API specification.<br />
|owner=[mailto:padenot@mozilla.com Paul Adenot]<br />
|ownersemeritus=[mailto:ehsan@mozilla.com Ehsan Akhgari]<br />
|peers=[mailto:robert@ocallahan.org Robert O'Callahan], [mailto:karlt+@karlt.net Karl Tomlinson]<br />
|group=dev-platform<br />
|source_dirs=dom/media/webaudio<br />
|url=https://wiki.mozilla.org/Web_Audio_API<br />
|components=Core::Web Audio<br />
}}<br />
<br />
{{Module<br />
|name=Web Painting<br />
|description=painting, display lists, and layer construction<br />
|owner=[mailto:matt.woodrow@gmail.com Matt Woodrow]<br />
|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]<br />
|group=dev-tech-layout<br />
|source_dirs= layout/painting, the display list and layer related methods on nsIFrame and its subclasses<br />
|url=http://mozilla.org/newlayout/doc/ ,<br />
http://lxr.mozilla.org/mozilla/source/layout/doc/<br />
|components=Core::Layout: Web Painting<br />
}}<br />
<br />
{{Module<br />
|name=WebRTC<br />
|description=WebRTC is responsible for realtime audio and video communication, as well as related issues like low-level camera and microphone access<br />
|owner=[mailto:rjesup@mozilla.com Randell Jesup]<br />
|peers=[mailto:ekr@mozilla.com Eric Rescorla], [mailto:bcampen@mozilla.com Byron Campen] [mailto:abr@mozilla.com Adam Roach]<br />
|peersemeritus=[mailto:ehugg@cisco.com Ethan Hugg]<br />
|group=dev-media<br />
|source_dirs=netwerk/sctp (also see submodules "WebRTC Media" and "WebRTC Signaling")<br />
|url=https://wiki.mozilla.org/Media/webrtc<br />
|components=Core::WebRTC, Core::WebRTC Networking<br />
}}<br />
<br />
{{Module<br />
|name=WebVR<br />
|description=Gecko's implementation of WebVR (Virtual Reality) functionality, including API, devices, graphics and integration<br />
|owner=[mailto:kgilbert@mozilla.com Kearwood (Kip) Gilbert]<br />
|peers=[mailto:dmu@mozilla.com Daosheng Mu], [mailto:igorostizaga@mozilla.com Imanol Fernández]<br />
|peersemeritus=[mailto:vladimir@pobox.com Vladimir Vukicevic]<br />
|group=dev-platform<br />
|source_dirs=dom/vr, gfx/vr<br />
|url=https://mozvr.com/<br />
|components=Core::WebVR<br />
}}<br />
<br />
{{Module<br />
|name=Widget<br />
|description=Top level Widget<br />
|owner=[mailto:jmathies@mozilla.com Jim Mathies]<br />
|ownersemeritus=[mailto:vladimir@pobox.com Vladimir Vukicevic], [mailto:robert@ocallahan.org Robert O'Callahan]<br />
|peersemeritus=[mailto:pavlov@pavlov.net Stuart Parmenter], <br />
|group=dev-platform<br />
|source_dirs=widget/, widget/xpwidgets/<br />
|url=<br />
|components=Core::Drag and Drop, Core::Widget, Core::Printing: Setup<br />
}}<br />
<br />
{{Module<br />
|name=Widget - Android<br />
|description=Android widget support<br />
|owner=[mailto:jwillcox@mozilla.com James Willcox]<br />
|peers=<br />
|ownersemeritus=[mailto:blassey.bugs@lassey.us Brad Lassey]<br />
|group=dev-platforms-mobile<br />
|source_dirs=widget/android/, embedding/android<br />
|url=<br />
|components=Core::Widget: Android<br />
}}<br />
<br />
{{Module<br />
|name=Widget - GTK<br />
|description=GTK widget support<br />
|owner=[mailto:karlt+@karlt.net Karl Tomlinson]<br />
|peers=[mailto:stransky@redhat.com Martin Stránský]<br />
|ownersemeritus=[mailto:robert@ocallahan.org Robert O'Callahan]<br />
|group=dev-platform<br />
|source_dirs=widget/gtk/, widget/gtk2/, widget/gtksuperwin/, widget/gtkxtbin/<br />
|url=http://www.mozilla.org/unix/, http://www.gtk.org, http://www.mozilla.org/ports/gtk/<br />
|components=Core::Widget: Gtk<br />
}}<br />
<br />
{{Module<br />
|name=Widget - Headless<br />
|description=Headless widget support<br />
|owner=[mailto:bdahl@mozilla.com Brendan Dahl]<br />
|peers=<br />
|ownersemeritus=<br />
|group=dev-platform<br />
|source_dirs=widget/headless/<br />
|url=<br />
|components=Firefox::Headless<br />
}}<br />
<br />
{{Module<br />
|name=Widget - OS X<br />
|description= OSX widget support<br />
|owner=[mailto:spohl@mozilla.com Stephen Pohl]<br />
|peers=[mailto:mstange@themasta.com Markus Stange]<br />
|ownersemeritus=[mailto:robert@ocallahan.org Robert O'Callahan], [mailto:mstange@themasta.com Markus Stange]<br />
|peersemeritus=[mailto:joshmoz@gmail.com Josh Aas], [mailto:b56girard@gmail.com Benoit Girard], [mailto:smichaud@pobox.com Steven Michaud]<br />
|group=dev-platform<br />
|source_dirs=widget/cocoa/<br />
|url=<br />
|components=Core::Widget: Cocoa<br />
}}<br />
<br />
{{Module<br />
|name=Widget - Windows<br />
|description=Windows widget support<br />
|owner=[mailto:jmathies@mozilla.com Jim Mathies]<br />
|peers=[mailto:neil@parkwaycc.co.uk Neil Rashbrook], [mailto:robert.strong.bugs@gmail.com Rob Strong], [mailto:aklotz@mozilla.com Aaron Klotz]<br />
|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]<br />
|group=dev-platform<br />
|source_dirs=widget/windows/<br />
|url=<br />
|components=Core::Widget: Win32<br />
}}<br />
<br />
{{Module<br />
|name=XML<br />
|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.<br />
|owner=[mailto:peterv@propagandism.org Peter Van der Beken]<br />
|peers=[mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:erahm@mozilla.com Eric Rahm]<br />
|peersemeritus=[mailto:jonas@sicking.cc Jonas Sicking], [mailto:jstenback@gmail.com Johnny Stenback]<br />
|group=dev-tech-xml<br />
|source_dirs=dom/xml/, extensions/xmlextras/, parser/expat/<br />
|url=http://www.mozilla.org/newlayout/xml/<br />
|components=Core::XML<br />
}}<br />
<br />
{{Module<br />
|name=XPApps<br />
|description=Cross-Platform Applications, mostly Navigator front end and application shell.<br />
|owner=[mailto:neil@parkwaycc.co.uk Neil Rashbrook]<br />
|peers=[mailto:dean_tessman@hotmail.com Dean Tessman], [mailto:timeless@mozdev.org Josh 'timeless' Soref]<br />
|group=dev-apps-seamonkey<br />
|source_dirs=xpfe/<br />
|url=http://www.mozilla.org/xpapps/<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=XPCOM<br />
|description=The cross-platform object model and core data structures.<br />
|owner=[https://mozillians.org/en-US/u/froydnj/ Nathan Froyd]<br />
|peers=[mailto:erahm@mozilla.com Eric Rahm], [mailto:nika@thelayzells.com Nika Layzell], [mailto:kmaglione@mozilla.com Kris Maglione]<br />
|ownersemeritus=Benjamin Smedberg<br />
|peersemeritus=[https://mozillians.org/en-US/u/dougt/ Doug Turner]<br />
|group=dev-platform<br />
|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/<br />
|url=http://developer.mozilla.org/en/XPCOM<br />
|components=Core::XPCOM<br />
}}<br />
<br />
{{Module<br />
|name=XPConnect<br />
|description=Deep Magic<br />
|owner=[mailto:bobbyholley@gmail.com Bobby Holley]<br />
|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]<br />
|peersemeritus=[mailto:gal@uci.edu Andreas Gal], [mailto:jstenback@gmail.com Johnny Stenback], [mailto:gkrizsanits@mozilla.com Gabor Krizsanits]<br />
|group=<br />
|source_dirs=js/xpconnect/<br />
|url=<br />
|components=Core::XPConnect<br />
}}<br />
<br />
{{Module<br />
|name=XPIDL<br />
|description=Cross-platform IDL compiler; produces .h C++ header files and .xpt runtime type description files from .idl interface description files.<br />
|owner=[mailto:nika@thelayzells.com Nika Layzell]<br />
|peers=[mailto:nfroyd@mozilla.com Nathan Froyd], [mailto:amccreight@mozilla.com Andrew McCreight]<br />
|ownersemeritus=[mailto:me@kylehuey.com Kyle Huey]<br />
|peersemeritus=[mailto:shaver@mozilla.org Mike Shaver], [mailto:timeless@mozdev.org Josh 'timeless' Soref]<br />
|group=dev-tech-xpcom<br />
|source_dirs=xpcom/typelib/<br />
|url=http://www.mozilla.org/scriptable/xpidl<br />
http://www.mozilla.org/scriptable<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=XSLT Processor<br />
|description=XSLT transformations processor<br />
|owner=[mailto:peterv@propagandism.org Peter Van der Beken]<br />
|peers=[mailto:axel@pike.org Axel Hecht], [mailto:erahm@mozilla.com Eric Rahm]<br />
|peersemeritus=[mailto:jonas@sicking.cc Jonas Sicking]<br />
|group=dev-tech-xslt<br />
|source_dirs=dom/xslt/<br />
|url=http://www.mozilla.org/projects/xslt/, http://www.w3.org/TR/xslt.html<br />
|components=Core::XSLT<br />
}}<br />
<br />
{{Module<br />
|name=Sandboxing - Windows <br />
|description=Sandboxing for the Windows platform <br />
|owner=[mailto:bobowencode@gmail.com Bob Owen] (:bobowen)<br />
|peers=[mailto:aklotz@mozilla.com Aaron Klotz] (:aklotz), [mailto:jimm@mozilla.com Jim Mathies] (:jimm), [mailto:davidp99@gmail.com David Parks] (:handyman)<br />
|ownersemeritus=[https://mozillians.org/en-US/u/TimAbraldes Tim Abraldes]<br />
|peersemeritus=[mailto:netzen@gmail.com Brian Bondy]<br />
|group=dev-platform<br />
|source_dirs=security/sandbox/win <br />
|url=https://wiki.mozilla.org/Security/Sandbox <br />
|components=Core::Security: Process Sandboxing<br />
}}<br />
<br />
{{Module<br />
|name=Sandboxing - OSX <br />
|description=Sandboxing for the OSX platform <br />
|owner=[mailto:haftandilian@mozilla.com Haik Aftandilian]<br />
|peers=<br />
|group=dev-platform <br />
|source_dirs=security/sandbox/mac <br />
|url=https://wiki.mozilla.org/Security/Sandbox <br />
|components=Core::Security: Process Sandboxing<br />
}}<br />
<br />
{{Module<br />
|name=Sandboxing - Linux<br />
|description=Sandboxing for the Linux platform<br />
|owner=[mailto:jld@mozilla.com Jed Davis]<br />
|peers=[mailto:gcp@mozilla.com Gian-Carlo Pascutto]<br />
|group=dev-platform<br />
|source_dirs=security/sandbox/linux<br />
|url=https://wiki.mozilla.org/Security/Sandbox <br />
|components=Core::Security: Process Sandboxing<br />
}}<br />
<br />
{{Module<br />
|name=Crash reporting<br />
|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.<br />
|owner=[mailto:gsvelto@mozilla.com Gabriele Svelto] (:gsvelto)<br />
|peers=[mailto:nfroyd@mozilla.com Nathan Froyd] (:froydnj)<br />
|group=dev-platform<br />
|source_dirs=toolkit/crashreporter, toolkit/components/crashes, tools/crashreporter, ipc/glue/CrashReporter*, mobile/android/geckoview/src/main/java/org/mozilla/geckoview/CrashReporter.java<br />
|url=https://firefox-source-docs.mozilla.org/toolkit/crashreporter/crashreporter/index.html<br />
|components=Toolkit::Crash Reporting<br />
}}<br />
<br />
===Submodules===<br />
{{Module<br />
|name=Build Config - Fennec<br />
|description=Submodule of the build config covering Fennec's build system in mobile/android.<br />
|owner=[mailto:nalexander@mozilla.com Nicholas Alexander]<br />
|peers=Same as Build Config<br />
|group=dev-builds<br />
|components=Core::Build Config<br />
}}<br />
<br />
{{Module<br />
|name=Build Config - Taskgraph<br />
|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.<br />
|owner=[mailto:mozilla@hocat.ca Tom Prince]<br />
|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]<br />
|components=Firefox Build System::Task Configuration<br />
}}<br />
<br />
{{Module<br />
|name=WebRTC Media<br />
|description=Submodule of WebRTC responsible for access to media input devices (microphones, cameras, screen capture), as well as realtime audiovisual codecs and packetization.<br />
|owner=[mailto:rjesup@mozilla.com Randell Jesup]<br />
|peers=[mailto:jib@mozilla.com Jan-Ivar Bruaroey], [mailto:dminor@mozilla.com Dan Minor], [mailto:apehrson@mozilla.com Andreas Pehrson], <br />
|peersemeritus=[mailto:pkerr@mozilla.com Paul Kerr], [mailto:ehugg@cisco.com Ethan Hugg]<br />
|group=dev-media<br />
|source_dirs=/media/webrtc, /dom/media/webrtc, /dom/media/systemservices<br />
|url=https://wiki.mozilla.org/Media/webrtc<br />
|components=Core::WebRTC (Audio/Video)<br />
}}<br />
<br />
{{Module<br />
|name=WebRTC Signaling<br />
|description=Submodule of WebRTC responsible for implementation of PeerConnection API, WebRTC identity, and SDP/JSEP handling<br />
|owner=[mailto:bcampen@mozilla.com Byron Campen]<br />
|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]<br />
|peersemeritus=[mailto:ehugg@cisco.com Ethan Hugg]<br />
|group=dev-media<br />
|source_dirs=/media/webrtc/signaling/<br />
|url=https://wiki.mozilla.org/Media/webrtc<br />
|components=Core::WebRTC (Signaling)<br />
}}<br />
<br />
<noinclude><br />
<br />
===Unassigned Bugzilla Components===<br />
<br />
The following Bugzilla components in the Core project have not been assigned to a module (this list is not exhaustive):<br />
<br />
<pre><br />
Core::Find Backend<br />
Core::General<br />
Core::History: Global<br />
Core::Image Blocking<br />
Core::Localization<br />
Core::Networking: Domain Lists<br />
Core::Selection<br />
Core::Serializers<br />
Core::Spelling checker<br />
Core::X-remote<br />
Core::XUL<br />
</pre><br />
</noinclude></div>Dbaronhttps://wiki.mozilla.org/index.php?title=Standards/Participating_in_a_W3C_Working_Group&diff=1225296Standards/Participating in a W3C Working Group2020-03-20T22:02:23Z<p>Dbaron: change wording a little more, from previous edit</p>
<hr />
<div>== Ways to participate (to join or not to join) ==<br />
<br />
W3C working groups have a defined membership: people can become a member of a working group or community group by being nominated by a W3C member company, by being invited by the chairs of the group (an invited expert), or by being a W3C staff member placed on the group by the W3C. However, most W3C working groups have most of their technical discussion on public mailing lists, which means that non-members can participate in many of the activities of the group. So, when you approach a W3C working group, you could decide to do so by becoming a member of the group or just by joining the public mailing list and participating in the discussion.<br />
<br />
How should one choose between these alternatives? While there's a good bit of variation between groups depending on the [http://www.w3.org/Consortium/activities charter] of the group, its chair(s), and the other participants in the group, I suggest considering the following factors:<br />
* being a member of the group signals Mozilla's support for a group to others (e.g., W3C staff, others in the industry). (This means that if the group is working on something we don't like, being a member may confuse other companies into thinking that Mozilla supports or is contributing to the work of the group).<br />
* members of the group may (depending on the charter of the group) have more ability to influence the decisions and the output of the group<br />
* if you want to attend face-to-face meetings or teleconferences of the group, you should be a member of the group<br />
* the group may have expectations that members participate (e.g., by attending phone or face-to-face meetings, by keeping up with certain aspects of the discussion). These vary by group and are described in the "Participation" section of the group's charter.<br />
* some mailing lists may require being a member of the group to subscribe (although this is rare), even when the archives are publicly viewable<br />
* becoming a member of the working group involves making some patent commitments, which may make other participants more comfortable accepting your contributions<br />
* other members of the group may expect somebody representing Mozilla is responsible for implementation work / decisions in Gecko; if you're not, you may wish to consider being extra clear about what your role is<br />
<br />
When you decide you want to participate:<br />
* If you want to just join the [http://lists.w3.org/Archives/Public/ public mailing list]:<br />
*# Send an email to "list-name-request@w3.org" with the subject "subscribe". (Don't forget to add the "-request" to the end of the list name.)<br />
*# Reply to the automated reply.<br />
* If you want to become a member of the working group, and you work for Mozilla:<br />
*# Make sure you have a W3C member access account associated with Mozilla:<br />
*#* if you don't already have a W3C user account, [https://www.w3.org/accounts/request create one]. Using a @mozilla.com email will lead to the account being created automatically; other email addresses will require that you choose '''Mozilla Foundation''' as the affiliation, and then there will be a human intervention step that requires a day or so, perhaps more.<br />
*#* if you have an W3C user account associated with a previous employer or as an invited expert, [https://www.w3.org/Systems/db/userInfo#affiliation change the affiliation of that account] to '''Mozilla Foundation'''<br />
*# Contact Mozilla's Advisory Committee Representative, [[User:Dbaron|David Baron]], and ask him to add you to the group.<br />
<br />
== Suggestions for participation ==<br />
<br />
* Avoid making promises you can't keep, even if pressured to do so.<br />
* Try to avoid speaking on behalf of Mozilla. If the process or other participants in the working group want you to speak on behalf of Mozilla, question such process or participants. However, rather than staying silent in such a situation, it's probably a good idea to both state your position and clearly state how much Mozilla consensus there is behind that position. Though it's not an ideal situation, it's ok for Mozilla's employees to disagree with each other on the best way to move the Web forward and implement Mozilla's mission.<br />
<br />
== Technical tips ==<br />
<br />
* Many W3C working groups work using GitHub. Your GitHub account should have a readable version of [https://github.com/settings/profile your name and affiliation and preferably a short relevant biography], so that people can recognize you as the person who joined the working group, and can know what implementation you work on.<br />
* You should [https://www.w3.org/users/myprofile/connectedaccounts connect your GitHub account to your W3C account] in order to make IPR-checking bots (which some working groups use) happy.<br />
* You should also connect your GitHub account to your [https://people.mozilla.org/ phonebook entry] since your colleagues may want to cc you on specification discussions.<br />
<br />
== Suggestions for chairing ==<br />
<br />
If you end up as the chair of a group, you should become more familiar with the process, since you'll sometimes be responsible for enforcing them (along with a team contact, if the group is a working group). Some documents that are helpful are:<br />
* [https://www.w3.org/Consortium/Process/ W3C Process] (for working groups)<br />
* [https://www.w3.org/community/about/agreements/#cgroups community group process] (for community groups)<br />
* [https://www.w3.org/Guide/ The Art of Consensus: A Guidebook for W3C Group Chairs and Participants]<br />
* [https://www.w3.org/Consortium/cepc/ W3C Code of Ethics and Professional Conduct]</div>Dbaronhttps://wiki.mozilla.org/index.php?title=All_Hands/Berlin2020&diff=1221166All Hands/Berlin20202019-12-10T17:37:53Z<p>Dbaron: /* S-Bahn */ remove statement that S-Bahn doesn't go through the city center and reword a little bit more</p>
<hr />
<div>'''What is it?''' -- Multiple team meetings, happening in the same city, at the same time + some opportunity to get together as one big group as well as with other teams as it makes sense. Then, on the last day, we have a fun social event for all, Mozilla-style! <br />
<br />
'''''The information on this wiki primarily applies to Full time and contractor staff. If you are a volunteer contributor please inquire with your community manager/program manager about [[All_Hands/Contributor_nominations|contributor nominations]], interns please inquire to your coordinator. Volunteer contributors who have recieved an invitation can find relevant information [[All_Hands/Berlin2020/contributors|here]]. '''''<br />
<br />
=='''Dates and Location'''==<br />
Monday, January 27, 2020 - Friday, January 31, 2020 (travel days are Monday, Jan 27 & Saturday, Feb 1) in Berlin, Germany.<br />
<br />
We have guestrooms at three hotels: [https://www.ihg.com/intercontinental/hotels/us/en/berlin/berha/hoteldetail InterContinental Berlin], [https://www.pullman-berlin-schweizerhof.com/en/ Hotel Pullman Schweizerhof], and [https://www.hotel-berlin.de/en/ Hotel Berlin, Berlin]. [https://drive.google.com/open?id=1eu_rYMxuc_hgSNqCJxW7Vn32pYMNayPa&usp=sharing View on map].<br />
<br />
''*For those countries where rest time is required on weekends (vs. work travel), Mozilla will cover a return on the next available work day, if you choose. This needs to pre-approved and pre-arranged.''<br />
<br />
=='''Registration'''==<br />
This is an invite-only event. All full time and Elance/Upwork employees are expected to attend this all company event. Contractors, Vendors and seasonal employees are included on a case by case evaluation based upon team needs and upon executive review and approval. <br />
<br />
Advance registration is required. Attendees will need to wear their event badge at all times, including to evening events. We will have security at our events who will be ensuring everyone in our space should be there. This includes facilitators, and other related business guests. <br />
<br />
=====New Hires=====<br />
We have a process to identify qualified regular full time new hires and Brianna will invite all new hires to register and book travel directly on their start date. No action is necessary from hiring managers other than to let them know about the event (please do not forward any links). Please work closely with your recruiting manager as they are aware of all deadlines.<br />
<br />
All regular full time new hires must have a start date of January 6, 2020 or earlier and in workday by December 13, 2019. Final invites will be extended on December 16, 2019. Contractors/vendors will require executive approval and those who are hired after the approval will not be invited. If you have any questions, please email bmark@mozilla.com.<br />
<br />
=====Volunteer Contributors=====<br />
There are a number of policies that apply specifically to contributors that are different than for staff. Please look [[All_Hands/Berlin2020/contributors|here]] for all contributor specific instructions and policies.<br />
<br />
'''Local contributors:'''<br />
<br />
Please note that because of the extensive nomination and screening process we apply to all contributors who attend the event - we are unable to invite local contributors or temporary participants to the event outside of the regular nomination and screening process.<br />
<br />
=====Registration Changes=====<br />
Everyone who registered received a confirmation email titled "Registration Confirmation to Mozilla Berlin All Hands" which shows you how you answered each question. If you didn't get the email and/or need to make changes to your registration, please email mozilla@shworldwide.com.<br />
<br />
=='''Immigration'''==<br />
If you have any questions about immigration, please email immigration@mozilla.com. <br />
<br />
==== STEP ====<br />
'''What is STEP?''' <br />
The [https://step.state.gov/ Smart Traveler Enrollment Program (STEP)] is a free service to allow U.S. citizens and nationals traveling abroad to enroll their trip with the nearest U.S. Embassy or Consulate. <br />
Benefits of Enrolling in STEP <br />
* Receive important information from the Embassy about safety conditions in your destination country, helping you make informed decisions about your travel plans.<br />
* Help the U.S. Embassy contact you in an emergency, whether natural disaster, civil unrest, or family emergency.<br />
* Help family and friends get in touch with you in an emergency.<br />
<br />
==== Visas ====<br />
You do not need a visa if you hold a passport issued from the EU, USA, Australia, New Zealand, Taiwan, or Canada. <br />
Please see here to confirm the entry document requirements for the country you’re from: https://www.auswaertiges-amt.de/en/einreiseundaufenthalt/visabestimmungen-node/staatenlistevisumpflicht-node <br />
<br />
If you are from a country that requires a visa to enter Germany, please plan to obtain one as early as possible as government processing times constantly change. You can find a broad overview of the process here: https://www.auswaertiges-amt.de/en/einreiseundaufenthalt/visabestimmungen-node . For more detailed instructions regarding the visa process you will need to refer to the website of your nearest Mission/Consulate General. You will be able to learn more about the process by searching for “business visa” or “visitor visa” on the website for that German Mission.<br />
<br />
'''Please keep in mind that while you are traveling for work, you are not traveling for a German based job.''' All Hands is a business conference/event. As you book your travel please also keep in mind that you could require a transit visa if you have a layover in a country that requires it. <br />
<br />
If you have questions specific to your circumstances, please email immigration@mozilla.com. <br />
<br />
==== Entering Germany ====<br />
Your passport or identity card will be checked when you arrive at an EU port or airport to make sure you’re allowed to come into the country. The passport must be valid for the whole of your stay. You may also need a visa to come into or travel through Germany, depending on your nationality. <br />
* If you are from an EEA country or Switzerland, you can enter Germany with either a valid passport or a national identity card issued by a EEA country. <br />
* If you need a United States Passport, start here: https://travel.state.gov/content/passports/en/passports.html. Please note it can take 4-6 weeks to receive your passport. Please plan ahead. <br />
<br />
==== EU Visa Waiver Program Suspension - Update ====<br />
In March 2019 the EU announced that the visa free entry requirements for third country visitors to Europe would be changing. This change will not go into affect until 1 January 2021, note this is one year after our Berlin All Hands trip. After this date, citizens from certain countries, including the USA and Canada, will be required to obtain an ETIAS travel authorization before they can enter Europe.<br />
<br />
==== More details: ==== <br />
Mission websites in popular Mozillian locations:<br />
* United States: https://www.germany.info/us-en/service/05-VisaEinreise/business-visa/963542<br />
* Canada: https://canada.diplo.de/ca-en/consular-services/visa/shortstay<br />
* UK: https://uk.diplo.de/uk-en/02/visa<br />
* Paris: https://allemagneenfrance.diplo.de/fr-de/service/00-visa-seite<br />
* Taiwan: https://taipei.diplo.de/tw-en/service/visa<br />
* Beijing: https://china.diplo.de/cn-zh/service/visa-einreise/schengenvisum/1343246<br />
* India: https://india.diplo.de/in-en/service/-/1908794<br />
<br />
=='''Travel to Berlin'''==<br />
Bookings to Berlin have begun. The Egencia instructions have be emailed to '''anyone approved to attend'''. New hires will have individual deadlines based upon hire/start date. Approved contractors, vendors, seasonal, status employees will be notified with an email from bmark@mozilla.com with specific instructions. <br />
<br />
Specific instructions were emailed to you about how to book, as we have a new process for anyone based outside the US, Canada & Central/South America. APAC employees will '''NOT''' be booking your All Hands travel in country based site, and will be using Egencia Americas. European employees '''WILL''' be booking in your country based site to allow access to trains and low cost airlines. <br />
<br />
Should you need to reach someone at '''Egencia Americas''' for special circumstances or changes that can't be done online:<br />
*Call+1 (800) 361-1120 or +1(702)939-2533; Hours of operations are Monday – Friday (except holidays) 5:00 AM– 6:00 PM PT or 8:00 AM – 9:00 PM ET or 12:00 PM - 1:00 AM UTC. If you call outside these hours, you will get an after-hours agent (not a meeting agent, who may not be as helpful) . Please ensure the agent you speak with knows you are booking for a meeting.<br />
*Email: groupagents@customercare.egencia.com. The email is monitored Monday - Friday.<br />
<br />
Other Egencia contact details:<br />
*Egencia UK+EMEA - Email: customer_service@egencia.co.uk; UK Local #: +44 203 077 2536 (charged at local rate). For calls made outside the UK, please dial +00 44 161 233 5525. (From anywhere outside the EU, please dial +011 44...)<br />
*Egencia FR - Email: service_client@egencia.fr; France Local #: +33 8 11 65 66 53. For calls made outside France, please dial +33 4 86 06 15 18 (From anywhere outside the EU, please dial +011 33)<br />
<br />
'''Important Details:'''<br />
Everyone should plan to arrive in Berlin Tegel Airport (TXL) on Monday, January 27 and leave on Saturday, February 1. Anyone who plans to arrive ahead of that or to stay longer, regardless of the reason, must follow the "arriving early/departing late guidelines." These guidelines also apply if you want to fly in or out of airports other than your home airport and Berlin Tegel (anything custom). A few notes:<br />
*If you are a vendor (paid by a company other than Mozilla or Upwork), contractor, or seasonal staff, those approved will be sent separate email.<br />
*Volunteers will be handled separate from this process.<br />
*We work closely with Recruiting to ensure new hires are invited after their start date. No need to let us know about these.<br />
*If you would like to invite someone who is a business partner, facilitator or some other category that isn't an employee or volunteer (not a personal guest/family), email bmark@mozilla.com.<br />
*Change fees will be covered by Mozilla for business reasons only. Please email bmark@mozilla.com ahead of calling Egencia to make the change. Any changes for personal reasons must be paid by the employee directly to Egencia over the phone. <br />
<br />
====Arriving Early/Departing Late Guidelines====<br />
<br />
Our standard travel guidelines apply (pre-populated in Egencia) when booking with a few additional budget constraints. Anything booked outside of them will require approval. Most people will arrive on Monday, January 27 and leave on Saturday, February 1. Here are some exceptions: <br />
<br />
# If you plan to spend some extra '''personal time in Berlin/Europe''' or nearby (choosing to arrive before Monday, Jan 27 or depart after Saturday, Feb 1), you'll need to create a itinerary in Egencia for standard dates/locations within the Egencia Portal and compare to the custom dates/locations you'd like. Pricing for the standard dates should be ''Round Trip only''. Pricing for custom dates/locations should be for ''Round trip or Multi city trips only''. Please share the difference via email to bmark@mozilla.com and receive approval ahead of submission in Egencia. You can ''sway up to +$100 over'' and Mozilla will cover it. Otherwise you'll need to come with an alternate itinerary that fits within the pricing (like a round trip in and out of TXL w/ longer dates, and you personally book & cover the rest). Please note that one way trips are only approved on a case by case basis. Do not book one ways without prior approval. ''We '''do not''' have the ability for employees to reimburse Mozilla for any overage.'' This scenario also applies for routing through different airports to/from Berlin Tegel than your home airport (ex. a layover in London for a few days, or flying out of something other than TXL). <br />
# If you are attending the '''Sunday/Monday CI event''' (by invite), you can arrive on Sunday, January 26.<br />
# If you would like to arrive early to '''recover from jetlag''', you will need manager approval for any additional costs associated with the extension. There is '''no unilateral''' "All Hands" approval based upon timezone to arrive early. For hotel, you will book and pay on your own, and expense the manager approved amount (which is coded to your cost center). This policy does not apply to volunteer contributors, any jetlag recovery costs must be self funded.<br />
# If you are celebrating the '''Lunar New Year''', [https://wiki.mozilla.org/All_Hands/Berlin2020#Lunar_New_Year see here].<br />
# If you live in a country where '''work travel is prohibited on weekends''', you may travel on Friday, Jan 24 and Monday, Feb 3, if you’d prefer (not required). For hotel, you will book and pay on your own, and expense the manager approved amount (which is coded to your cost center). You must have approval from our benefits team in writing (and send to bmark@mozilla.com) '''prior''' to booking any travel. Approvals and expenses will not be applied retroactively. <br />
# If you live in a country where '''work travel is prohibited on Sunday''', you may travel on Saturday, Jan 25, if you’d prefer (not required). For hotel, you will book and pay on your own, and expense the manager approved amount (which is coded to your cost center). You must have approval from our benefits team in writing (and send to bmark@mozilla.com) '''prior''' to booking any travel. Approvals and expenses will not be applied retroactively.<br />
<br />
====Booking Family Travel====<br />
Whether your family will accompany you on your flight or join us later; and you have two options: direct with the airline (recommended) or through Egencia.<br />
<br />
'''Direct (recommended):''' <br />
<br />
First, figure out which flights you want to be on as an employee in Egencia. Hold them in Egencia. Find the flights you want for your family on the airline site and book them. Go back to Egencia and book your flights. Once you have both sets of confirmation numbers, call the airline and ask them to LINK your two reservations. This shows that you are traveling together and shouldn't be moved. When you call, you can also ask the airline agent to assign seats together. By booking your family direct on the airline, it gives them "priority" with the airline over people who book via a third party (expedia, booking.com, kayak, etc). These aren't guarantees, but they do help.<br />
<br />
'''Via Egencia:'''<br />
<br />
We do not recommend booking family through Egencia. If you'd like details about how to do it, please email bmark@mozilla.com<br />
<br />
'''Notes:''' <br />
<br />
* If your family is arriving on a different flights than you but would like to take advantage of the airport shuttles on Sunday/Monday and/or Saturday, please email their itinerary to mozilla@shworldwide.com.<br />
* We are unable to accommodate volunteer contributor families/guests.<br />
* As of 20 November, we only have rooms that can accommodate 2 adults. If a larger room is needed, it will need to be booked and paid for on your own.<br />
<br />
====Not Flying====<br />
Mozilla will reimburse U-Bahn tickets for those based in the Berlin area for getting to/from hotels. For more information on the U-Bahn, please see the Berlin office guide on [https://mana.mozilla.org/wiki/display/WPR/Berlin+Office+Guide#BerlinOfficeGuide-MovingAroundBerlin mana]. <br />
<br />
For those outside of the Berlin area who are taking the train, please book by November 10. Instructions were emailed to everyone. <br />
<br />
Parking is not reimbursable.<br />
<br />
====Travel Insurance====<br />
Mozilla provides emergency medical accident and illness cover for all global MoCo employees/interns and their dependents. You can view more information on [https://mana.mozilla.org/wiki/display/PR/Travel+Insurance+-+Business Mana]. This coverage begins at the time the you leave home to start your business trip. It also has a provision for a 14 day extension for leisure travel outside of the business travel. If you have additional questions, please email benefits@mozilla.com. <br />
<br />
Mozilla does not cover travel insurance for elancers, upworkers, contractors, vendors, or volunteers/community members (unless required for visa application).<br />
<br />
====Air Travel Fine Print====<br />
*Change fees will be covered by Mozilla for '''business reasons only'''. If you need a change and have manager approval, email bmark@mozilla.com '''prior to requesting the change with Egencia'''. Once you have approval, call Egencia to make the change at 1-877-255-1090 (note this will not be possible without prior approval so be sure to get that by way of an email from your manager to Brianna Mark). If you are changing for personal reasons, the change in airfare, change fee and Egencia fee is your responsibility.<br />
*Mozilla will '''not''' reimburse for Business/First class upgrades, tickets or seat reservations. <br />
*Mozilla will reimburse for one checked bag each way.<br />
*''Mozilla Frequent Flyer perks do not apply for All Hands''. <br />
*Flights booked outside of Egencia will not be an approved expense unless email approval by Brianna is obtained prior to booking.<br />
*Any submitted expenses needs to have an itinerary attached to ensure it is employee expenses only and within policy.<br />
<br />
====Ground Transportation====<br />
Berlin Tegel airport is open from 4:00 - 0:00. <br />
Shuttles will be provided from Berlin Tegel Airport (TXL) to our 3 hotels:<br />
*Sunday, Jan 26 from 9:00 - 22:00, for flights landing between 7:45 and 21:45.<br />
*Monday, Jan 27 from 8:00 - 23:00, for flights landing between 7:15 and 22:55.<br />
<br />
Shuttles from our 3 hotels to Berlin Tegel will be provided:<br />
*Saturday, Feb 1 from 4:00 - 20:00, for flights departing 7:15 and 22:15.<br />
*Sunday, Feb 2 from 4:00 - 12:00, for flights departing 6:00 - 14:00. ''If you are on a later flight, you can take the last shuttle at 12:00.'' <br />
<br />
Taxis and Addison Lee are not reimbursable. <br />
<br />
If you are arriving by train to Hauptbahnhof:<br />
To Hotel Berlin Berlin<br />
* FROM HAUPTBAHNHOF STATION: Take the S-Bahn metro lines S5, S9 or S75 to the station “Zoologischer Garten” (20 min.). From there, take the bus 100 to the stop Lützowplatz. <br />
* Via U-BAHN: Take the U-Bahn metro lines U2, U3 and U1 to the station “U-Nollendorfplatz”. Exit the station in the direction of “Karl-Heinrich-Ulrichs-Straße." The road leads directly to the hotel (approx 5 mins). <br />
* [https://www.hotel-berlin.de/d/berlinberlinpro/media/PDF/Anfahrt_A4_E_Karl-Heinrich-Ulrichs-Strae_5c2ab7.pdf Map]<br />
<br />
To InterCon Berlin and Pullman<br />
* FROM HAUPTBAHNHOF STATION: Take the S-Bahn metro lines S3, S5, S7, or S9 to the station “Zoologischer Garten”. From there, walk 10 mins to hotel.<br />
<br />
Berlin's integrated public transport is divided in 3 tariff zones (ABC). To travel within the city, including from Tegel airport to the hotels, you only need an AB ticket. Tickets can be bought at automated booths in most stations (accept credit cards), and on Metro (need coins). You can use the same ticket to travel on buses, metro, S-Bahn, U-Bahn. More information, including PDF maps, are available on [https://www.berlin.de/en/public-transportation/1772016-2913840-tickets-fares-and-route-maps.en.html this website]. A mobile app is available on stores ("BVG FahrInfo Plus") and allows to create routes between stations, or you can use directly the [https://www.bvg.de/en BVG] website.<br />
<br />
====Getting around Berlin====<br />
You’ll rarely hear from your Berlin-based colleagues (or anyone else actually living in the city instead of the suburbs) that they prefer or even enjoy taking the car anywhere. Many don’t even own a car unless they truly need it because driving in Berlin is not a lot of fun with busy traffic, lots (looooots!) of construction sites, a bunch of one-way streets and barely any free parking spaces. When exploring the city, we recommend that you use public transportation instead, which takes you everywhere and is pretty reliable. Or you rent bikes and even add some exercise to your city tour.<br />
<br />
In order to make sure that you know your transportation options, here’s an overview of what you may use — and how.<br />
<br />
=====Buying tickets=====<br />
Most types of public transport require you to buy and validate your ticket before entering the respective vehicle. You can find ticket machines at the stations or buy a ticket at shops in one of the larger train stations. The machines usually inform you in German and in English, which makes them easy to use. <br />
<br />
You’ll be able to buy different types of tickets depending on where you go and duration of their validity, from just one ride up to 6 days. If you plan to use public transportation for several days in a row it’s definitely recommended to get a multi-day ticket because the relative price will be lower.<br />
<br />
Of course, there are also some peculiarities to each type of transportation when it comes to paying the fees:<br />
U-Bahn & S-Bahn: After buying a ticket at the machine, which you’ll most likely find on the platform or, if it’s a larger train station, in the entry area, you may need to validate it at an extra machine. They’re usually located on the platform, as well. [https://welcome2berlin.weebly.com/uploads/1/2/1/2/121289663/s-bahn-ticket-machine-00-img-6428-1920x2560-otmc-10-90_orig.jpg Here's a picture of a ticket machine with the ticket validation machine to its left.]<br />
Bus: Most bus stations don’t have ticket machines but you can buy one from the driver.<br />
Tram: Some trains have ticket machines inside; however, they don’t always work.<br />
<br />
Please also take into account where you’re actually planning to go when buying a ticket. Berlin has 3 fare zones: A (city center), B (wider Berlin city area) and C (outside of the actual Berlin city area; Brandenburg). Unless you’re only exploring the area around the All Hands site, you’ll probably want to get “AB” tickets. If you need to go to or from Berlin Schönefeld Airport (SXF), it is located in fare zone C, so you'll need a ticket that covers area “C”. If you have an “AB” ticket you can buy an extension ticket for a single trip.<br />
<br />
=====U-Bahn (the subway)=====<br />
The “U-Bahn” is our local subway system, which connects the entire city area, taking you almost everywhere within just a few minutes. There are 10 lines overall, named U1 to U9 (plus the kind of odd U55 that only connects very few stations). Big “U” signs all over Berlin help you spot the next station. <br />
<br />
The BVG (Berliner Verkehrsbetriebe, the Berlin transport company) offer a fully interactive route map on their website. If you prefer a printed version, you can pick one up for free at one of their customer centers; the main office is located in the subway station “Alexanderplatz” in the city center. Or you just download their app, which is available for all major OS. You can also buy tickets via the app.<br />
<br />
Pro tip: You may want to download the Berlin map in your favorite navigation app. Given that your phone plan may not apply to Europe (or it’s ridiculously expensive to go online), this can actually save your day because public WiFi isn’t as widely available in Germany as e.g. in North America.<br />
<br />
=====Tram/Straßenbahn=====<br />
The tram is Berlin’s overground train service within the city. There are 22 lines overall: 9 so-called MetroTram lines (names consist of “M” plus a line number) and 13 streetcar lines (where the name is a simple number). They complement the U-Bahn and S-Bahn system by running on important routes that are not covered otherwise. <br />
<br />
Given the size of the Berlin city area, you’ll most likely need to switch between trains and types of public transport, which includes the trams. They’re usually easy to find since they’re comparatively loud, painted in shining yellow and, well, run on overground tracks through pedestrian zones and next to roads used by cars. Also, big red signs with the word “tram” on them guide the way.<br />
<br />
=====S-Bahn=====<br />
The S-Bahn is another overground train but covers longer distances than the tram (and doesn't run in or cross streets).<br />
<br />
You’ll probably want to take the S-Bahn when visiting the neighbourhoods that are further out, doing a day trip to Potsdam or going to Schoenefeld Airport. If Berlin’s 3rd airport, BER, ever happens to open, transport from the city will also be covered by S-Bahn. It's also good for some trips within the city center.<br />
<br />
=====Other trains=====<br />
Are you planning a trip through Germany or even beyond? Then you may want to consider taking one of the trains of the Deutsche Bahn (German railway company).<br />
<br />
Trains leave from the 7 long-distance train stations in Berlin. You can buy tickets online (bahn.de) or at the machines in each of the stations. If you’re planning a longer trip or want to travel during peak times, it’s recommended to buy your ticket in advance, add a seat reservation and take sufficient provisions for the trip since food and drinks at the “Bord-Bistro” are ridiculously expensive.<br />
<br />
Pro tip: If you bought a seat reservation in advance and there’s someone sitting in your spot, don’t be shy and ask them to get up. It may be awkward but it’s totally normal. Also, the reservation goes away if you don’t claim your seat within a certain amount of time after getting on the train.<br />
<br />
Even though it carries about two billion passengers annually, it’s unlikely that you’ll experience amazing service or punctuality on your Deutsche Bahn trip — which is at least a little bit funny given that it used to be owned by the government of a country that’s mostly known for its efficiency. Just kidding ;) German trains are quite comfortable to use, prices are okay and from Berlin, you’ll arrive in most other larger cities in Germany and the neighbouring countries within comparatively short times as the trains can go up to 300 km/h.<br />
<br />
=====Busses=====<br />
Just like in any other country, busses combine all of the inconveniences of public transportation and driving a car in the city: it’s crowded, you may need to stand for a pretty long time and it takes forever to get to your destination. Still, busses are used a lot (at least in Berlin) because they cover many short routes where there’s not S-Bahn, U-Bahn or Tram service.<br />
<br />
When entering a bus in Berlin, operated by the aforementioned BVG, you’re theoretically required to show your ticket to the diver; some don’t really care while others are quite strict about it. Beyond that, there are a couple of additional rules you should be aware of before stepping into a BVG bus:<br />
* Don’t stand anywhere close to a door unless you feel prepared to deal with the rage of the bus driver. They don’t mind yelling at someone in the very back of the bus or even interrupt their route until the respective person behaves as they’re expected to.<br />
*This applies to your luggage just as much as to you as a person.<br />
*Make sure to monitor the route closely. If you want to get off the bus you need to push the button to request a stop soon enough or stay on the bus until the driver finishes their tour.<br />
<br />
Pro tip: If you get on a bus that isn’t too crowded let the driver know where you want to go and take a seat nearby. They’re not all grumpy. Some of them are actually quite friendly and helpful when you approach them directly.<br />
<br />
=====Taxi & Uber=====<br />
Uber has grown to become the most successful driving services in many countries but it is currently banned in Germany after its UberX service has been found in violation of German federal law prohibiting private citizens (e.g. without background checks) to offer transport services. Instead use one of the many (7500 in total) regular yellow licensed taxis. When calling a driver in Berlin you have several choices:<br />
<br />
*Get a regular taxi by calling one over the phone (+49 30 20 20 20 OR +49 30 26 10 26), find a taxi stop, or stop a taxi on the street. Just make sure to have some cash on you as some of them don’t take credit cards. Remember, licensed Taxis are a light yellow ("light ivory", [https://upload.wikimedia.org/wikipedia/commons/e/e0/Taxis_at_EDDT-%28jha%29.jpg picture]).<br />
<br />
*Call a regular taxi via the [https://www.taxi.eu/en/cities/berlin/ taxi.eu] app. This app (download: [http://itunes.apple.com/de/app/taxi.eu/id465315934 Apple iOS], [https://market.android.com/details?id=at.austrosoft.t4me.MB_BerlinTZBEU Android]) offers a similar service as Uber but gives access to the majority of Berlin's regular (and regulated) taxis (7200 of the 7500 total). The main difference is that you can either pay cash or need to be connected to the internet in order to pay through the app at the end of your ride: while you agree on a price with your Uber driver before getting into their car, taxi.eu will charge you for the actual distance/time it took to get you to your destination, which isn’t clearly determined before your arrival and only an estimate is shown during booking.<br />
<br />
=='''Hotels'''==<br />
<br />
For anyone who was registered by October 13, your hotel assignments/confirmations will be emailed by November 14. <br />
If you registered October 14 or later, you will get your confirmation by November 27. <br />
<br />
The emails are coming from bmark@mozilla.com, not the hotel directly. Please make sure to read and check for accuracy. <br />
<br />
In each email, you will find:<br />
*Your assigned hotel<br />
*The dates that have been booked for you<br />
*Links to book extra nights beyond what has been booked for you<br />
<br />
A few things to note:<br />
#If you have any changes or questions about your reservation, email mozilla@shworldwide.com. The hotel cannot make changes to All Hands reservations so we’d like very much if you didn’t try (it complicates things).<br />
#If you registered that you have guests joining you for all or part of the week:<br />
*You will be responsible for covering all additional fees at the hotel. <br />
*All hotel rooms have a maximum capacity of 2 adults (with some exceptions limited to very small children)<br />
*If you registered by October 13:<br />
*Guests have already been added to your hotel reservation on your behalf. You have been assigned a room that can accommodate you and your guests. Please refer to the total occupants listed in your hotel confirmation.<br />
*If you need to add a guest, please email mozilla@shworldwide.com. Please note: all hotel rooms that can accommodate more than 2 adults have been alloted. If a larger room is needed, it will need to be booked and paid for on your own. <br />
<br />
If you are planning to book pre/post stays, links to do so will be provided in your confirmation email. I recommend you do that soon, as rates and availability are limited, and will not be available after December 20. Please use your legal name and use LDAP email so we can match reservations. Reservations booked outside of these portals cannot be linked to All Hands reservations.<br />
<br />
Everyone will be required to present a form of payment on check-in for incidentals. For your own sanity, please do not provide a debit/cash card. If you are unable to provide a credit card, please email mozilla@shworldwide.com and we can request special accommodations.<br />
<br />
=='''Families/Guests'''==<br />
Of course our focus, for the majority of the week, will be on Mozilla. Everyone is expected to be present and engaged each day, during work hours (as your schedule dictates). Please do what you can to make sure your loved ones understand the kind of commitment you’ve made. Please note that what are able to do for families varies by each location. We are unable to accommodate volunteer contributor or intern families/guests at our All Hands. <br />
<br />
====Quick summary logistics====<br />
* Air Travel: Employees do need to book via Egencia regardless of how families are booked. <br />
* Hotel: Family/friends are welcome to stay with you. All room rates are based upon single occupancy and include breakfast. Guests must be added to reservations in advance and any additional room expenses will be yours to cover. Most of our hotel rooms have a maximum of double occupancy (2 adults), with very limited availability of rooms for higher occupancy. Higher occupancy rooms will be assigned in the order that you register. As of 20 November, we only have rooms that can accommodate 2 adults. If a larger room is needed, it will need to be booked and paid for on your own. <br />
* Lunch & Dinner: Family will be on their own for lunch daily and dinner on Tuesday, Wednesday & Thursday. <br />
* Monday & Friday Night Events: Family members who are registered for the event and registered with the hotel, are invited to join us for our evening events.<br />
* Childcare Services: We will not provide centralized childcare services. We have found that every family has different needs and centralized childcare does not deliver on those needs. If you are in need of help finding options for your family, we are happy to connect you with staff whose families who are coming (#allhands-childcare and #parents are great places to start), as well we are happy to help support finding of resources (although you are likely better at it than us). Given every circumstance is unique, we defer to your manager to determine what Mozilla can support you with financially.<br />
<br />
On demand babysitting services in Berlin: <br />
* https://extra-arms.com/for-families-babysitting/<br />
* https://www.withourbaby.com/<br />
<br />
====Exploring Berlin with Kids====<br />
Berlin is a great city to explore with kids as it offers lots of fun, interesting and educational activities that are even suitable for the cold weeks of January. Which brings us to a very important recommendation we want to share right at the beginning of this section: dress your kids up appropriately to the weather but focus on layers. The onion look may not always be super fancy but both you and your kids will appreciate it: Since it can get unpleasantly cold in the Berlin winter, public places and attractions tend to heat up their indoor offers. Wearing layers makes sure that your kids neither get cold outside nor sweaty when going inside.<br />
<br />
=====Inside activities=====<br />
*The Deutsches Technikmuseum (German Technical Museum) is a great place to spend time on a cold January day. It’s exciting for both adults and kids and offers a lot to explore. Discover the cultural history of technology by yourself! Also, you can get there from the All Hands location in just 20 minutes by public transport. <br />
Deutsches Technikmuseum, Trebbiner Straße 9, 10963 Berlin-Kreuzberg<br />
Opening hours: TUE-FRI 9am-5:30pm, SAT+SUN 10am-6pm<br />
*MACHmit! museum für Kinder is a museum like no other: Endless opportunities to discover and try new things encourage children to learn through play, whilst also gaining new and exciting experiences that they would not come across in an average day. Arts and crafts activities, lots of running and being loud and for parents a nice area where you can get coffee and snacks.<br />
MACHmit! Museum für Kinder, Senefelderstraße 5, 10437 Berlin<br />
Opening hours: TUE-SUN 10am-6pm<br />
*The Aquarium Berlin in the center of Berlin is one of Europe’s best-known and most notable aquariums. Behind the building’s historic façade awaits an impressive diversity of species that few facilities in the world can rival. The Aquarium not only houses numerous extraordinary fish, it is also home to hundreds of impressive reptiles and insects. Also, it’s just a 5 minutes walk from the All Hands location.<br />
Aquarium Berlin, Budapester Str. 32, 10787 Berlin<br />
Opening hours: Daily 9am-6pm<br />
*View the night sky without any clouds disrupting your view at the Zeiss-Großplanetarium! The largest planetarium in Central Europe was inaugurated in 1987. The Planetarium offers lots of events for young and older kids and is just impressive to be in. You should check it out!<br />
Zeiss-Großplanetarium, Prenzlauer Allee 80, 10405 Berlin<br />
Opening hours: TUE+SUN 9:30am-6pm, WED+THU 9:30am-9pm, FRI+SAT 9:30am-10:30pm<br />
*Tropical Island: Taking a break at Tropical Island means swimming, diving or just relaxing by the Tropical Sea or Lagoon, exploring the world's largest indoor rainforest or getting your adrenaline pumping on Germany's highest water slide tower -- plus lots of other great attractions. Disclaimer: It’s crowded, so if you are not so much into big groups of people, this might not be for you -- but kids LOVE IT. You can easily reach Tropical Island within a one-hour train ride. <br />
<br />
=====Outside activities=====<br />
You and your kids don’t mind the cold too much? Great! There are plenty of nice things to do outside even the winter. As the train services run pretty well and Berlin is well connected even to the rural areas, you have a lot to choose from and it’s pretty easy as well as inexpensive to get there.<br />
*Just a few minutes outside of Berlin you’ll find Karls Erlebnis-Dorf (Karl’s Adventure Village) in Elstal. In addition to offering a spacious farmers market, many attractions for children are waiting for you, including a big wooden roller coaster. Admission is free. You can get there by car, bus and train.<br />
Karls Erlebnis-Dorf, Döberitzer Heide 1, 14641 Elstal<br />
Opening hours: Daily 8am-7pm<br />
*Tempelhofer Feld is a big recreation area in the Berlin districts Neukölln and Tempelhof. It’s actually the largest inner-city open space worldwide, Berlin’s most spacious urban park as well as part of larger historical project. Throughout the year, the park is used for outdoor sports like jogging, biking, roller-blading, and kiting, but is also a popular spot for wild gardening and barbecues. The Mozilla Berlin Family Day 2017 took place right there.<br />
Accessible via 10 entrances<br />
Opening hours: From sunrise to sunset<br />
<br />
=='''Lunar New Year'''==<br />
We are aware of the overlap in the Lunar New Year celebrations with the Berlin All Hands. To help folks who decide to attend the Berlin All Hands and who also celebrate Chinese New Year, we will offer the following:<br />
* A higher airfare caps for air travel to allow for fewer layovers on Monday, January 27<br />
* Assurance that Berlin is optional but if employee wants to attend they can shift their holiday days to another time. <br />
* Live Airmo Feeds of Plenary (+ relevant team all hands meetings) + quick posting of recording to accommodate those who choose not to travel. <br />
* Potentially shifting any main plenary session date/time<br />
<br />
We are working with leadership and representatives of those most affected and will update wiki regularly with updates. Feel free to reach out to Brianna with questions.<br />
<br />
=='''Week at a Glance'''==<br />
View [https://docs.google.com/spreadsheets/d/1kIwKEmlYE9tMuWRvSNZnYDGWFwEumcHVp1s0LVPz-e8/edit#gid=0 Week at a glance]<br />
<br />
====Monday====<br />
*Monday is travel/arrival day<br />
*Registration<br />
*Welcome Reception from 6:00 pm - 9:00 pm<br />
<br />
====Tuesday====<br />
*Breakfast in hotel restaurants<br />
*Lunch in hotels of your team homeroom<br />
*Dinner on own<br />
<br />
====Wednesday====<br />
*Breakfast in hotel restaurants<br />
*Lunch in hotels of your team homeroom<br />
*Dinner on own<br />
<br />
====Thursday====<br />
*Breakfast in hotel restaurants<br />
*Lunch in hotels of your team homeroom<br />
*Dinner on own<br />
<br />
====Friday====<br />
*Breakfast in hotel restaurants<br />
*Lunch in hotels of your team homeroom<br />
*Closing event at Motorwerk<br />
<br />
====Saturday====<br />
*Breakfast in hotel restaurants<br />
*Departure day only. No scheduled activities.<br />
<br />
===Berlin All Hands Event Calendar===<br />
Coming soon!<br />
<br />
=='''Food, Drink & Events'''==<br />
Lunch & snacks will be provided and paid for centrally for attendees. Breakfast is provided Tuesday - Saturday as part of your guestroom reservation - you must eat breakfast in the hotel you sleep in. You will not be reimbursed if you go to another hotel and pay to eat there. <br />
<br />
Allergies/preferences: We will ensure that all food/environmental allergies are taken into consideration and will always have gluten-free and vegan options. If you have severe allergies that we need to know about; you can indicate in registration.<br />
<br />
===Hosted Evening Events===<br />
We have evening events on the Monday and Friday nights.<br />
<br />
====Monday Night Welcome Reception====<br />
6 pm - 9 pm, InterCon hotel<br />
<br />
====Friday Night at Motorwerk====<br />
6:00 pm - 11:00 pm<br />
<br />
======Getting to/from the event======<br />
Shuttles depart from the hotels starting at 5:00 pm. Shuttles will return starting at 8:00 pm. The last departure returning will leave at 11:05 pm. The only way to access the event is via our shuttles.<br />
<br />
=====Coat Check=====<br />
Coat check will be available for clothing only, no bags. <br />
<br />
====Tuesday, Wednesday & Thursday Night Dinners====<br />
You'll be on your own for Tuesday, Wednesday & Thursday and will have a similar expense policy from past all hands (50EUR/night - 150EUR total to include food, beverage, transportation, exchange fees, etc). <br />
<br />
Here is how this will work:<br />
<br />
For all evenings, once your meetings have concluded, you and your team, friends, new acquaintances, are free to explore and to find somewhere great to eat that suits you. Each of you can expense a total of 150EUR over the three days (or 50EUR/night).<br />
<br />
This amount includes:<br />
*Meal cost, including tax & gratuity<br />
*Any beverages<br />
*Transportation to/from the restaurant<br />
*Conversion fees (for credit cards) or cash withdrawal fees<br />
<br />
Anything over the 150EUR for the three evenings will be your own expense. The fine print:<br />
*If your team is hosting an evening event 1 of the nights and the payment is coordinated (meaning, you don’t have to open your wallet and pay), you can expense up to 100EUR for the other night.<br />
*You will be asked (later) to submit a Berlin All Hands only expense report. You can submit ONE report for Berlin only and must be submitted no later than February 28, 2020.<br />
*No expenses over 50 EUR per night will be [https://docs.google.com/document/d/1XUD5KYotSr5SNi0q4ldgGG3bzBu-G3q4l5i-JiPE5ko/edit approved].<br />
<br />
Volunteer Contributors will have a separate process that will be communicated directly.<br />
<br />
=====Groups, Restaurants & Reservations=====<br />
*Group dinners - All large (eight or more people) reservations must go through Lisa Carlson (email lcarlson@mozilla.com) and dinners must stay within the per diem per night (50EURpp including, food, beverage, tax, gratuity and transportation), and employees attending must not also expense their per diem for that night.<br />
<br />
In no case should employees expense or use MoCo corporate cards to cover purchases of alcohol outside of team dinners or the 50EUR individual per diem.<br />
<br />
=='''Safety & Security'''==<br />
=====Alcohol at Events=====<br />
To better support and sustain an environment (and workplace culture) where people feel safe and included, we have made a set of changes regarding alcohol at our events. In all cases, our approach aligns with our [https://www.mozilla.org/en-US/about/governance/policies/participation/ Community Participation Guidelines] (“CPG”).<br />
*All participants are '''required to read and acknowledge our new Community Participation Guidelines as a condition of participation'''.<br />
*We will '''limit bar-servings to beer and wine''' and ensure an equal number and quality (i.e. not just Coke) of non-alcoholic drink options are available and displayed.<br />
*Team dinners should be '''thoughtful about the potential exclusionary nature of alcohol when planning'''.<br />
*Clearly outlined, communicated (to event teams, HR and managers) and understood '''escalation process''' for behavior that might be deemed counter to the spirit of our CPG.<br />
<br />
=====Device Security=====<br />
If you are traveling to the All Hands with a device that has Mozilla data (laptop, personal cell phone/tablet with @mozilla gmail, etc) on it and your device has been retained for further inspection by border agents, or if your device has been inspected outside your immediate presence - and you believe your credentials have been compromised - you must notify the Enterprise Information Security team as soon as possible at infosec@mozilla.com or by calling Mozilla End User Services at +1 650-963-8811. (This number will be staffed 24x7)<br />
<br />
We will work with you to reset your credentials and help you get your device back to a known good state either by getting you a new one (if it’s been taken), or by resetting it back to a verifiable Mozilla-approved installation.<br />
<br />
=====Physical Security=====<br />
Badges are required to access all meeting spaces and evening events.<br />
<br />
=='''Accessibility'''==<br />
====Evenings====<br />
Monday Night reception is at the InterContinental Berlin. No stairs or elevators required. <br />
<br />
====Meeting spaces====<br />
* InterCon: Most meeting space levels are accessible by elevators.<br />
* Pullman: All meeting space levels are accessible by guestroom elevators.<br />
* Hotel Berlin: All meeting space is on the ground level.<br />
<br />
====Listen Systems====<br />
We will have Listen Systems available for any meeting in the main plenary space. Visit the AV booth to pick one up.<br />
<br />
====Bathrooms====<br />
TBA <br />
<br />
====Breastfeeding/pumping stations====<br />
Milk Stork Services are reimbursable - please contact benefits@mozilla.com for more information.<br />
<br />
=='''Sustainability'''==<br />
'''Hotel Berlin, Berlin''' is certified partner of visitBerlin we stand for sustainable, green meetings and events. For more information, visit https://convention.visitberlin.de/en/sustain.<br />
<br />
'''InterContinental Hotel Berlin''' is Green Globe Certified. Green Globe Certification is the worldwide sustainability system based on internationally accepted criteria for sustainable operation and management of travel and tourism businesses. Operating under a worldwide license, Green Globe Certification is based in California, USA and is represented in over 83 countries. Green Globe Certification is a member of the Global Sustainable Tourism Council, supported by the United Nations World Tourism Organization. Additonally, as part of IHG’s Green Engage™ program the InterContinental Berlin has implemented best practices at all operational levels. The innovative Environmental Management System not only measures the day-to-day energy, water and waste consumption, but also provides recommended actions – ‘green solutions’ – to improve energy conservation and the property’s carbon footprint score.<br />
<br />
=='''Berlin: In your spare time (likely pre/post)'''==<br />
=====First things first=====<br />
Germany overall is widely diverse with regard to mentality, language, architecture, history, and more. In this guide we’re focusing on Berlin. However, if you have the opportunity to see a bit more of the country, you should definitely take it. We may also add that if you plan for a larger Europe trip, while there might be overlaps and similarities between the individual European countries, there are also lots and lots of differences -- and we’re by far not only referring to language. If you want to learn more about any other places you’re planning to go reach out to Mozillians who’re based there or otherwise know the city/country well. First-hand information is usually the most valuable and we have so many amazing people from anywhere in the world at our organization that it’s almost impossible that you don’t find someone who can help!<br />
<br />
=====Exploring the city -- beyond Charlottenburg and Mitte!=====<br />
For the All Hands week we’re going to be in Charlottenburg, one of the neighbourhoods most visited by tourists. Along with Mitte (basically the city center), it’s an attractive destination for shopping and sightseeing. Nevertheless, we can only recommend that you leave the usual tourist trail in order to get a more diverse impression of Germany’s capital. There’s, for example, kind-of-hipster Kreuzberg, where our German office is located -- along with a bunch of amazing bars, restaurants, clubs and much more. Or take vibrant Friedrichshain, which is just across the Spree river from Kreuzberg, or family-friendly Prenzlauer Berg, all of which have their own interesting tourist attractions that are complemented by a relaxed local vibe. Overall, Berlin has 12 boroughs and a total of 96 officially recognized localities, so there’s clearly a lot to see!<br />
<br />
=====Orientation=====<br />
Berlin is a pretty large city (891 qm, or 344 sq mi), so even Berliners use navigation apps regularly -- especially when leaving their “Kiez”. We therefore recommend that you download the Berlin map to your phone, as well, in order to make orientation easier, especially when doing some sightseeing.<br />
<br />
This is also due to peculiarities that may make orientation less obvious, such as house numbers which do not necessarily run in the same direction (up or down) everywhere: On a lot of streets, the numbers ascend on one side and descend on the other. So to avoid getting you lost, you should check the numbering scheme first: you can find the name of the street at nearly every street corner. The same sign will usually state the range of house numbers in that segment.<br />
<br />
Thanks to the subway system in particular, you can actually visit multiple neighbourhoods on the same day even if they’re not close. You can go from east to west in not much more than half an hour (if you’re lucky and have a good connection) and, even though it’s recommended to dedicate at least a few hours to each of the neighbourhoods you visit in order to get a proper impression, you should make use of it. Only by visiting different parts of the city that don’t share all of their history and demographics, you’ll be able to truly “see” Berlin. <br />
<br />
=====Sightseeing & history=====<br />
As mentioned (multiple times) before Berlin is full of history. It’s almost impossible to walk around the city for half an hour without coming across some sort of historical site. This ranges from a huge range of museums and galleries, which you’ll best get informed about through a guidebook, as well as historical buildings, such as churches.<br />
<br />
If you don’t mind the cold weather, make sure to set aside some time for sites outside. You could, for example, explore cold war history and go to Checkpoint Charlie, the former border crossing between East and West Berlin, which is undoubtedly one of the city’s top attractions. Another recommendation would be a visit to Hohenschönhausen, a former Stasi prison where East German dissidents were incarcerated. Tours of the prison are conducted daily and often led by a former prisoner, who will give you a real insight into this fascinating, albeit traumatic time in history.<br />
<br />
If you’re looking for something more cheerful and/or a bunch of suggestions for historical sightseeing options by neighbourhood, you should check out Wikivoyage, a free web-based travel guide that has also been called the “Wikipedia of travel guides”. Take a look at the article on City West, if you want to explore the vicinity of our All Hands location. Literally every other Berlin tourist would likely favor the eastern districts of Friedrichshain, Prenzlauer Berg and (western) Kreuzberg, for its lower price and a lot of international bars, cafés and many other tourist attractions.<br />
<br />
Links<br />
https://en.wikivoyage.org/wiki/Berlin/City_West<br />
https://en.wikivoyage.org/wiki/Berlin/East_Central<br />
<br />
=====Food!=====<br />
Being an international city, almost any cuisine you can imagine is available in Berlin. Still, we recommend that you try out some actual German food during your stay. For example, go to a local bakery and you’ll be stunned by the variety: There are over 300 types of dark and white breads, and more than 1,200 different kinds of “Brötchen” and “Kleingebäck” (bread rolls and mini-breads). We’re so much into bread that every region in Germany even has their own term for bread rolls (“Brötchen” vs. “Schrippe” vs. “Weck” vs. Semmel”...). Bread is central to the “German diet”: For breakfast, many people eat it with cheese, sausage products, honey or marmalade and “Abendbrot” (“evening bread” = dinner) usually consists of sandwiches.<br />
<br />
If you’re rather looking for a warm meal, you should try a Currywurst (“curry sausage”). Over the last couple of years, the Berlin foodie scene has truly exploded and you can get so much more than the stereotypical type of curry sausage nowadays, from plain to fancy, for meat lovers or for vegans. You can get them in restaurants, at street food markets or even from salespeople in the pedestrian zones.<br />
<br />
When visiting restaurants that offer German cuisine, you’ll notice that meat is a main ingredient for many meals -- though there are also plenty of fish and vegetarian options nowadays. With regard to side dishes, potatoes (in a lot of different varieties, such as cooked, roasted, mashed or as cakes) are very popular as well as noodles. <br />
<br />
In Germany as in many other countries it’s quite common to meet friends and family for dinner and go to a bar or pub afterwards. Berlin has a lot to offer in that respect and most places have their very individual flair. If you’re not into the aforementioned beer options, you could go for a (non-alcoholic or boozed) cocktail or a good glass of wine. Since Germany has several renown wine-growing regions, there’s a lot to choose from!<br />
<br />
=='''All Hands Expense Policy'''==<br />
1. All "All Hands" Expenses must be submitted on 1 (and only 1) Expense report (e.g. Berlin All Hands Expense Report). Each expense must be tagged with "All Hands - Jan 2020"<br />
<br />
2. It must contain only those expenses relative to the All Hands Event in Berlin. <br />
<br />
3. If your submitted expense report for All Hands is submitted outside these guidelines, it will be rejected and you will be asked to re-submit with only All Hands Expenses<br />
<br />
4. The deadline to submit the All Hands Expense Report is '''February 28, 2020'''.<br />
<br />
5. Expenses related to team events (except those coordinated through Lisa Carlson), parking, room service, mini-bar charges, and food/drink costs above the vouched amounts, will not be approved. <br />
<br />
6. When submitting your expense report through Egencia, make sure to "attached the PDF" (toggle on mobile, check box on desktop). <br />
<br />
<br />
'''The intention of our all hands are to centrally organize a structure that includes:'''<br />
*Meals (2 evening events + breakfast, lunch, drinks and snacks Tuesday - Friday)<br />
*Transportation<br />
*Accommodations<br />
<br />
Expenses submitted can not exceed the approved amounts. Any social events (except dinners/team building activities coordinated through Lisa Carlson) that are not part of our central plan will generally be self-organized and funded by participants. <br />
<br />
=====Travel expenses policy=====<br />
Reimbursement will be made for necessary and reasonable expenses. <br />
<br />
* Getting to/from home to your airport: We ask that you use the most economical option, while balancing your personal needs - whether that be mileage/parking, public transportation or ride shares. We will not reimburse for private towncar services or car rental. <br />
* Per standard Mozilla travel policy, Travel Meal Policy: Employees are eligible for travel meals when traveling. For Meals: There is a $75 USD per day meal policy while traveling. This covers breakfast (est. $15), lunch (est. $20), and dinner (est. $40). Receipts: Receipts are required. When submitting a meal for reimbursement, please include how many people attended the meal. There is no need to include names.<br />
* We will not reimburse for seat/class upgrades. Frequent flyer status does not apply for All Hands. <br />
* We will reimburse for bag checking fees for one bag. <br />
<br />
Any other expenses must be approved by your manager ahead of time. Any expenses for extending your stay for business reasons - such as additional hotel nights, meals, etc must be approved by your manager before booking and travel.<br />
<br />
=====Cell phone reimbursement policy=====<br />
Cell phone reimbursement must be approved by your manager prior to submitting the expense. Teams will decide for their staff what is appropriate to expense. <br />
<br />
=====Internet reimbursement policy=====<br />
Internet will be provided in all guestrooms and meeting space in all hotels. If you opt to upgrade/add service, those costs are not reimbursable, unless previously approved by your manager and are for business reasons.<br />
<br />
=='''Activities'''==</div>Dbaronhttps://wiki.mozilla.org/index.php?title=ExposureGuidelines&diff=1220950ExposureGuidelines2019-12-04T17:18:40Z<p>Dbaron: /* Intent to prototype */ mention users too</p>
<hr />
<div>=Adding features=<br />
<br />
One way Mozilla aims to advance the state of the web platform is with new features. Always ask: ''Is this good for the web?''<br />
<br />
If you aim to expose a new feature to the web or change an existing feature, please follow these steps:<br />
<br />
# Email [https://lists.mozilla.org/listinfo/dev-platform dev-platform] declaring your [[#Intent to prototype|intent to prototype]]. (It is okay to skip this step for small changes.)<br />
## If you are implementing a feature that is working its way through a standards body process such as the W3C's, it's best to email as soon as possible (i.e., before [http://www.w3.org/2005/10/Process-20051014/tr#q74 W3C CR status] if possible).<br />
# Implement as normal. Code review rounds will take place, etc. Module owners or their designated peers will provide a super-review for all interface changes.<br />
## [https://blog.mozilla.org/security/2018/01/15/secure-contexts-everywhere/ Restrict the feature to secure contexts].<br />
## Ensure the feature has [https://github.com/w3c/web-platform-tests web-platform-tests] coverage.<br />
## Land potentially disruptive features behind a preference which is off by default.<br />
# Email [https://lists.mozilla.org/listinfo/dev-platform dev-platform] declaring your [[#Intent to ship|intent to ship]] on [[Release_Management/Release_Process|Firefox Release]].<br />
# If there's no negative feedback, ship.<br />
<br />
==Intent to prototype==<br />
<br />
<blockquote><br />
'''To''': <tt>dev-platform@lists.mozilla.org</tt><br><br />
'''Subject''': Intent to prototype: <your feature goes here><br />
<br />
''Summary'': [https://en.wikipedia.org/wiki/Elevator_pitch elevator pitch] for the new functionality including benefits to users and web developers.<br><br />
''Bug'': link to Bugzilla (tracking) bug.<br /><br />
''Standard'': link to standard or link to public discussions with other browser vendors.<br /><br />
''Platform coverage'': where will this be available? Android, Desktop, only exposed to privileged apps (certified app-only functionality does not require an email), etc.<br /><br />
''Preference'': if applicable, how can interested parties test this before it ships pref'd on by default?<br /><br />
''DevTools bug'': link to a [https://bugzilla.mozilla.org/enter_bug.cgi?product=devtools Developer Tools bug] coordinating work with the DevTools team to build tools for this feature.<br /><br />
''Other browsers'': address with "shipped" (since version X, behind what flags if any), "intent emailed" (mailing list URL), or "considering" (citation).<br /><br />
''web-platform-tests'': Please link to the test suite. If any part of the feature is not tested by web-platform-tests, please include links to one or more of:<br />
* A web-platform-tests issue explaining why a certain thing cannot be tested ([https://github.com/w3c/web-platform-tests/issues/3867 example]).<br />
* A spec issue for some change that would make it possible to test ([https://github.com/whatwg/fullscreen/issues/70 example]).<br />
* A Bugzilla bug for the creating web-platform-tests.<br />
''Secure contexts'': Provide justification if this feature is not restricted to secure contexts. Otherwise, use "Yes".<br><br />
''Is this feature enabled by default in sandboxed iframes?'' If not, is there a proposed sandbox flag to enable it? If allowed, does it preserve the invariants in terms of what sandboxed iframes can do?<br />
</blockquote><br />
<br />
===Suggested additions===<br />
<br />
The above is the minimum required that should be in an "Intent to prototype" email. If you've covered those, you're good, and brevity is a virtue.<br />
<br />
If you're looking for extra credit, or to preempt common questions, consider adding any or all of the following (all based on existing dev-platform examples, and questions asked on dev-platform in response to intent to ship emails).<br />
* ''Link to standards-positions discussion'': Link to a discussion in [https://github.com/mozilla/standards-positions mozilla/standards-positions] about what we think about the specification.<br />
* ''How stable is the spec'': Note that even if it's unstable that shouldn't stop us implementing; that mostly affects shipping. So as long as we're pretty sure that the basic set of functionality is stable, even if the actual names of the values are not, implementing makes sense.<br />
* ''Security & Privacy Concerns'': consider providing a link to answers in [https://mikewest.github.io/spec-questionnaire/security-privacy/ this security/privacy questionnaire] for a spec feature, if the spec doesn't already answer it. In particular, consider if the spec exposes new information about a user's computer or behavior that can contribute to fingerprinting.<br />
* ''Web designer / developer use-cases'' AKA ''Why a developer would use Feature X?'': Provide a URL to at least briefly documented use-cases for web designers and developers that illustrate why and when they would use this feature.<br />
* ''Example'': Provide a brief code sample on how to use the API. Even with a formal specification, not everyone will know about the feature just from the name of the spec. An example will make it easier to understand how this feature can be used. This can either be an inline code sample, or a direct link to an example on the web.<br />
<br />
==Intent to ship==<br />
<br />
<blockquote><br />
'''To''': <tt>dev-platform@lists.mozilla.org</tt><br /><br />
'''Subject''': Intent to ship: <your feature goes here><br />
<br />
As of <target date> I intend to turn <feature> on by default [<on these platforms>]. It has been developed behind the <pref> preference. Status in other browsers is <details>.<br />
<br />
''Product'': name of the product manager responsible for the feature.<br><br />
''Bug to turn on by default'': link to main relevant bug (https://bugzilla.mozilla.org/show_bug.cgi?id=) Please set the ''dev-doc-needed'' keyword.<br />
<br />
This feature was previously discussed in this "Intent to prototype" thread: <https://groups.google.com/forum/#!forum/mozilla.dev.platform>. '''If anything changed since that thread please include that information in this email'''.<br />
</blockquote><br />
<br />
It's acceptable to merge the "intent to prototype" into the "intent to ship" email as long as all the relevant requirements are met.<br />
<br />
=Removing features=<br />
<br />
Occasionally there is a need to remove features. These could be features that are proprietary to Mozilla, were standardized but never got adopted by all browsers, or features that are so bad that all browsers want to get rid of them together.<br />
<br />
In order to make this possible while impacting users as little as possible the following steps are to be taken:<br />
<br />
* Gather telemetry on the feature.<br />
* Consult dev-platform with an [[#Intent to unship|intent to unship]] that includes the telemetry data.<br />
* Indicate in the developer console whenever the feature is used that it's deprecated and might be removed. It's best to avoid doing this until there's agreement that the feature can be removed (which requires telemetry) as otherwise developers are needlessly spammed in the console.<br />
* Remove the feature when the telemetry data and dev-platform agreement indicate it can be.<br />
<br />
==Intent to unship==<br />
<br />
<blockquote><br />
'''To''': <tt>dev-platform@lists.mozilla.org</tt><br /><br />
'''Subject''': Intent to unship: <your feature goes here><br />
<br />
As of <target date> I intend to remove <feature> [<on these platforms>]. Status in other browsers is <details>.<br />
<br />
''Product'': name of the product manager responsible for the feature.<br><br />
''Bug to remove'': link to main relevant bug (https://bugzilla.mozilla.org/show_bug.cgi?id=) Please set the ''dev-doc-needed'' keyword.<br />
<br />
<Include rationale, telemetry analysis, links to related discussions if any, and developer console suggestions.><br />
</blockquote><br />
<br />
= See Also =<br />
* [[WebAPI/DesignGuidelines]]<br />
* [[WebAPI/WebIDL_Review_Checklist]]<br />
* [https://www.chromium.org/blink Chrome/Blink change process]<br />
** [https://www.chromium.org/blink/launching-features Chrome/Blink process for Launching Features] in particular<br />
<br />
=FAQ=<br />
<br />
==When is a feature ready to ship?==<br />
<br />
Features which Mozilla makes available by default to the web on the release channel should be "ready". This can mean that they are de jure standards (e.g., a W3C Recommendation) or de facto standards. Indications that a feature is ready for shipping to the web include:<br />
<br />
# other browser engines ship compatible implementations in their releases or behind a preference with clear signals it will graduate to being on by default<br />
# other browser engines state their ''intention'' to ship a compatible implementation<br />
# a large number of web developers indicate their satisfaction with the feature design<br />
# there exists a specification that is no longer at risk of significant changes, is on track to become a standard with a relevant standards body, and is acceptable to a number of applicable parties and other browser engines<br />
<br />
==How do we know what web developers want?==<br />
<br />
* Mozilla's [[Engagement/Developer_Engagement|Developer Engagement]] coordinates a [https://openwebapps.uservoice.com/forums/258478-open-web-apps Open Web Apps UserVoice] forum<br />
* [http://chromestatus.com chromestatus.com] has a column for new features entitled "Documented or perceived web developer views"<br />
<br />
==How do we know what other browser engines think?==<br />
<br />
* Some of them participate in dev-platform discussions<br />
* Watch for positive signals on the specification's discussion forum (likely a GitHub repository)<br />
* Watch for "intent to *" emails on mailing lists such as [https://groups.google.com/a/chromium.org/forum/#!forum/blink-dev blink-dev]<br />
<br />
Note: lack of feedback will not delay our implementation as it may simply indicate lack of interest at that time from another browser engine.<br />
<br />
==How do we let other browser engines know what we think?==<br />
<br />
* By documenting our position on [standards-positions https://github.com/mozilla/standards-positions].<br />
* Participating in public discussions of new features.<br />
* Comment on "intent to *" threads on [https://groups.google.com/a/chromium.org/forum/#!forum/blink-dev blink-dev].<br />
<br />
==What about prefixes?==<br />
<br />
In the past, Mozilla has shipped experimental features with a "moz" prefix to indicate their lack of standardization (e.g., <code>mozRequestAnimationFrame()</code>). Unfortunately, this approach turned out to be harmful to the web as experimental features ended up being used in some websites before they were ready. In many cases, this meant that we were unable to innovate on certain features because to change them would break content on the web. Browsers have in some cases also been [https://compat.spec.whatwg.org/ forced to implement each other's prefixed features]. Therefore, to allow us to continue innovating without negatively affecting content on the web, '''Mozilla will no longer ship new "moz"-prefixed features''' (see [https://groups.google.com/forum/#!topic/mozilla.dev.platform/34JfwyEh5e4 Henri Sivonen's proposal]).<br />
<br />
We will instead prototype features behind preferences which can be toggled through <code>about:config</code>. Once we feel there is an acceptable level of consensus in the web community about the stability of an feature and we feel it is ready, we will make it generally available to the web platform (more details below on this process). We feel this strikes the right balance between allowing developers to experiment with new features, while at the same time protecting the web from being exposed to new functionality prematurely.<br />
<br />
==Who decides?==<br />
<br />
If the dev-platform thread results in a conflict, the respective [[Modules|module owner]] is responsible for resolving that conflict and making a decision on how to proceed.</div>Dbaronhttps://wiki.mozilla.org/index.php?title=Pastebin&diff=1217138Pastebin2019-08-29T00:47:39Z<p>Dbaron: add paste.mozilla.org, which given the domain probably shouldn't be in the "unsupported" category</p>
<hr />
<div>=Pastebin.Mozilla.org=<br />
<br />
==Important: Pastebin.mozilla.org was shut down on September 1st, 2018. ==<br />
<br />
A list of alternatives in [https://bugzilla.mozilla.org/show_bug.cgi?id=1480438 bug 1480438] including:<br />
<br />
Public-facing, authentication required:<br />
* [https://gist.github.com/ Github gists] <br />
* [https://docs.google.com/ Google Docs]<br />
<br />
Public-facing, unauthenticated:<br />
* [https://paste.mozilla.org/ paste.mozilla.org (a dpaste instance)]<br />
<br />
Public-facing, unauthenticated, unsupported:<br />
* [https://dpaste.de/ dpaste]<br />
* [https://hastebin.com/ hastebin]<br />
* [https://pastebin.com/ Pastebin.com]<br />
<br />
Authenticated Mozillians can choose:<br />
<br />
* gdocs/gdrive <br />
* the Mana collaborative editor (coming soon)<br />
<br />
Other, less practical suggestions have included:<br />
<br />
* Postcards<br />
* Bathroom walls<br />
* Various proposals involving the phrase "beware of the leopard"</div>Dbaronhttps://wiki.mozilla.org/index.php?title=ExposureGuidelines&diff=1214060ExposureGuidelines2019-06-21T21:22:13Z<p>Dbaron: /* Intent to implement */ mention standards-positions in suggested additions section</p>
<hr />
<div>=Guiding Principles=<br />
Mozilla aims to advance the state of the web platform with new features. In past years, Mozilla has shipped experimental features with a "moz" prefix to indicate their lack of standardization (e.g., <code>mozRequestAnimationFrame()</code>). Unfortunately, this approach turned out to be harmful to the web as experimental features ended up being used in some websites before they were ready. In many cases, this meant that we were unable to innovate on certain features because to change them would break content on the web. Browsers have in some cases also been forced to implement each other's prefixed features. Therefore, to allow us to continue innovating without negatively affecting content on the web, '''Mozilla will no longer ship new "moz"-prefixed features''' (see [https://groups.google.com/forum/#!topic/mozilla.dev.platform/34JfwyEh5e4 Henri Sivonen's proposal]).<br />
<br />
We will instead make experimental features available behind preferences which can be toggled through <code>about:config</code>. Once we feel there is an acceptable level of consensus in the web community about the stability of an feature and we feel it is ready, we will make it generally available to the web platform (more details below on this process). We feel this strikes the right balance between allowing developers to experiment with new features, while at the same time protecting the Web from being exposed to new functionality prematurely.<br />
<br />
==Special Cases==<br />
There may be special cases where we deviate from this goal. New user-facing products may need to ship features that have not yet been embraced by other browser engines or thoroughly discussed by standards bodies. This allows Mozilla to provide functionality that other browser engines aren't working on or the majority of the Web community isn't interested in at that time. We will avoid exposing such functionality to the web at large. Developing these features without much involvement from the Web community comes with the price of temporary proprietary features. This clearly indicates their lack of standardization at that time and limits the number of developers relying upon them. Mozilla will learn from such efforts and use this knowledge to inform various standardization efforts. Our aim is to standardize our proprietary features as soon as possible so they become available on a royalty-free basis for the benefit of the web community at large.<br />
<br />
=Guidelines for Mozillians developing new features=<br />
The following is put forward as a set of guidelines for Mozillians -- especially [[Modules|module owners and peers]] -- to refer to while developing new APIs for the Web. The primary question that must be asked is:<br />
<br />
::''Is this good for the web?''<br />
<br />
If the answer to that question is yes, look below for some guidance on how you should proceed with shipping your new feature. Note that trivial changes need not worry about these suggested guidelines.<br />
<br />
==When is an feature ready to be shipped by Gecko?==<br />
Features which Mozilla makes available by default to the web on the release channel should be "ready". This can mean that they are de jure standards (e.g., a W3C Recommendation) or de facto standards. Indications that a feature is ready for shipping to the web include:<br />
<br />
# other browser engines ship compatible implementations in their releases or behind a preference with clear signals it will graduate to being on by default<br />
# other browser engines state their ''intention'' to ship a compatible implementation<br />
# a large number of web developers indicate their satisfaction with the feature design<br />
# there exists a specification that is no longer at risk of significant changes, is on track to become a standard with a relevant standards body, and is acceptable to a number of applicable parties and other browser engines<br />
<br />
==How do we know what other browser engines think?==<br />
* some of them participate in dev-platform discussions<br />
* watch for positive signals on the specification's discussion forum (likely a GitHub repository)<br />
* watch for "intent to implement" emails on mailing lists such as [https://groups.google.com/a/chromium.org/forum/#!forum/blink-dev blink-dev]<br />
* lack of feedback will not delay our implementation as it may simply indicate lack of interest at that time from another browser engine<br />
<br />
==How do we know what web developers want?==<br />
* Mozilla's [[Engagement/Developer_Engagement|Developer Engagement]] coordinates a [https://openwebapps.uservoice.com/forums/258478-open-web-apps Open Web Apps UserVoice] forum<br />
* [http://chromestatus.com chromestatus.com] has a column for new features entitled "Documented or perceived web developer views"<br />
<br />
==How do we let other browser engines know what we think?==<br />
* participate in public discussions of proposed features<br />
* blog and/or tweet about proposed features<br />
* comment on "intent to implement" threads on [https://groups.google.com/a/chromium.org/forum/#!forum/blink-dev blink-dev]<br />
<br />
==Suggested implementation process==<br />
If your work is going to expose a new feature to the web or non-trivially change an existing one, it is requested that you follow these steps:<br />
<br />
# Email [https://lists.mozilla.org/listinfo/dev-platform dev-platform] declaring your [[#Intent to Implement|intent to implement]]. If you are implementing a feature that is working its way through a standards body process such as the W3C's, it's best to email as soon as possible (i.e., before [http://www.w3.org/2005/10/Process-20051014/tr#q74 W3C CR status] if possible).<br />
# Implement as normal. Code review rounds will take place, etc. Module owners or their designated peers will provide a super-review for all interface changes.<br />
# [https://blog.mozilla.org/security/2018/01/15/secure-contexts-everywhere/ Restrict the feature to secure contexts].<br />
# Ensure the feature has [https://github.com/w3c/web-platform-tests web-platform-tests] coverage.<br />
# Land potentially disruptive features behind a preference which is off by default.<br />
<br />
==Turning a preference on by default==<br />
When you are satisfied that your new feature is stable enough for exposure to the web at large (see [[#When is a feature ready to be shipped by Gecko?|above]]), it is requested that implementers send another email to dev-platform declaring their [[#Intent to ship|intent to ship]]. Among other things, this email serves to inform those that are interested in the new API but have not been closely following the implementation bug(s).<br />
<br />
=Guidelines for removing features=<br />
<br />
Occasionally there is a need to remove features. These could be features that are proprietary to Mozilla, were standardized but never got adopted by all browsers, or features that are so bad that all browsers want to get rid of them together.<br />
<br />
In order to make this possible while impacting users as little as possible the following steps are to be taken:<br />
<br />
* Gather telemetry on the feature.<br />
* Consult dev-platform with an "Intent to unship" that includes the telemetry data.<br />
* Indicate in the developer console whenever the feature is used that it's deprecated and might be removed. It's best to avoid doing this until there's agreement that the feature can be removed (which requires telemetry) as otherwise developers are needlessly spammed in the console.<br />
* Remove the feature when the telemetry data and dev-platform agreement indicate it can be.<br />
<br />
=Decision making=<br />
<br />
If the dev-platform thread results in a conflict, the respective module owner is responsible for resolving that conflict and making a decision on how to proceed.<br />
<br />
=Email templates=<br />
==Intent to implement==<br />
'''To''': <tt>dev-platform@lists.mozilla.org</tt><br /><br />
'''Subject''': Intent to implement: <your feature goes here><br />
<br />
''Summary'': [https://en.wikipedia.org/wiki/Elevator_pitch elevator pitch] for the new functionality including benefits to web developers<br /><br />
''Bug'': link to main implementation tracking bug<br /><br />
''Link to standard'': if no formal specification exists yet, link to public discussions with other browser vendors<br /><br />
''Platform coverage'': where will this be available? Android, Desktop, only exposed to privileged apps (certified app-only functionality does not require an email), etc.<br /><br />
''Estimated or target release'': in which version do you want to/plan to release this?<br /><br />
''Preference behind which this will be implemented'': if applicable, how can interested parties test this before it ships pref'd on by default?<br /><br />
''Is this feature enabled by default in sandboxed iframes?'' If not, is there a proposed sandbox flag to enable it? If allowed, does it preserve the current invariants in terms of what sandboxed iframes can do?<br/><br />
''DevTools bug'': link to a [https://bugzilla.mozilla.org/enter_bug.cgi?product=Firefox&component=Developer%20Tools Firefox :: Developer Tools bug] coordinating work with the DevTools team to build tools for this feature.<br /><br />
''Do other browser engines implement this?'' Answer with: shipped (since version X, behind what flags if any); intent to implement emailed (mailing list URL); considering (citation).<br /><br />
''web-platform-tests'': Please link to the test suite. If any part of the feature is not tested by web-platform-tests, please include links to one or more of:<br />
* A web-platform-tests issue explaining why a certain thing cannot be tested ([https://github.com/w3c/web-platform-tests/issues/3867 example]).<br />
* A spec issue for some change that would make it possible to test ([https://github.com/whatwg/fullscreen/issues/70 example]).<br />
* A Bugzilla bug for the creating web-platform-tests.<br />
''Is this feature restricted to secure contexts?'' Provide justification if this feature is not restricted to secure contexts. Otherwise, use "Yes".<br />
<br />
<br />
<br />
=== Suggested additions ===<br />
The above is the minimum required that should be in an "Intent to implement" email. If you've covered those, you're good, and brevity is a virtue.<br />
<br />
If you're looking for extra credit, or to preempt common questions, consider adding any or all of the following (all based on existing dev-platform examples, and questions asked on dev-platform in response to intent to ship emails).<br />
* ''Link to standards-positions discussion'': Link to a discussion in [https://github.com/mozilla/standards-positions mozilla/standards-positions] about what we think about the specification.<br />
* ''How stable is the spec'': Note that even if it's unstable that shouldn't stop us implementing; that mostly affects shipping. So as long as we're pretty sure that the basic set of functionality is stable, even if the actual names of the values are not, implementing makes sense.<br />
* ''Security & Privacy Concerns'': consider providing a link to answers in [https://mikewest.github.io/spec-questionnaire/security-privacy/ this security/privacy questionnaire] for a spec feature, if the spec doesn't already answer it. In particular, consider if the spec exposes new information about a user's computer or behavior that can contribute to fingerprinting.<br />
* ''Web designer / developer use-cases'' AKA ''Why a developer would use Feature X?'': Provide a URL to at least briefly documented use-cases for web designers and developers that illustrate why and when they would use this feature.<br />
* ''Example'': Provide a brief code sample on how to use the API. Even with a formal specification, not everyone will know about the feature just from the name of the spec. An example will make it easier to understand how this feature can be used. This can either be an inline code sample, or a direct link to an example on the web.<br />
<br />
==Intent to ship==<br />
'''To''': <tt>dev-platform@lists.mozilla.org</tt><br /><br />
'''Subject''': Intent to ship: <your feature goes here><br />
<br />
As of <target date> I intend to turn <feature> on by default [<on these platforms>]. It has been developed behind the <pref> preference. Other UAs shipping this or intending to ship it are <details>.<br />
<br />
''Bug to turn on by default'': link to main relevant bug (https://bugzilla.mozilla.org/show_bug.cgi?id=) ['''note''': this bug should ideally have the ''dev-doc-needed'' keyword set]<br /><br />
<br />
This feature was previously discussed in this "intent to implement" thread: <https://groups.google.com/forum/#!forum/mozilla.dev.platform>. '''If anything changed since that thread please include that information in this email'''.<br />
<br />
==Intent to implement and ship==<br />
'''To''': <tt>dev-platform@lists.mozilla.org</tt><br /><br />
'''Subject''': Intent to implement and ship: <your feature goes here><br />
<br />
It's acceptable to combine the "intent to implement" and "intent to ship" emails as long as all the relevant requirements are met.<br />
<br />
<br />
==Intent to unship==<br />
<br />
'''To''': <tt>dev-platform@lists.mozilla.org</tt><br /><br />
'''Subject''': Intent to unship: <your feature goes here><br />
<br />
<The body of the email should contain rationale, telemetry analysis, links to related discussions if any, and developer console suggestions.><br />
<br />
= See Also =<br />
* [[WebAPI/DesignGuidelines]]<br />
* [[WebAPI/WebIDL_Review_Checklist]]<br />
* [https://www.chromium.org/blink Chrome/Blink change process]<br />
** [https://www.chromium.org/blink/launching-features Chrome/Blink process for Launching Features] in particular</div>Dbaronhttps://wiki.mozilla.org/index.php?title=Writing_Code_for_Chemspill_Releases&diff=1213478Writing Code for Chemspill Releases2019-06-10T02:22:08Z<p>Dbaron: add additional point based on comment a few days ago from jesup (my reformulation, though). (Unfortunately, the good set of comments I got right after my lightning talk are lost to our document retention policy.)</p>
<hr />
<div>Writing code for a chemspill release is different from writing most other code in Firefox. Chemspill releases are what we do to handle a security vulnerability that's publicly known or being used in the wild. The goal of these releases is to ship very quickly, hopefully in less than 24 hours, from when we learn about the problem. Rollout of these releases is not throttled. So we're shipping code really fast. The code goes to millions of users within hours after release, and very few safeguards exist. There's no chance for users to report bugs, or for us to triage incoming crash reports, or to look at telemetry.<br />
<br />
We've messed these up in the past, to the point of having to ship more dot releases to fix the problems. We've also almost messed up in ways that would have made us do this. We haven't *really* messed up, though, by breaking updates, or breaking the ability to start Firefox and thus update.<br />
<br />
When you're writing code for a chemspill release:<br />
* "probably" isn't good enough. "sounds like it should work" is not good enough. Can you prove it? Go through the things that could possibly go wrong.<br />
* change as little as possible (effects, not diffs). Don't change dependencies, and don't change web-exposed behavior more than absolutely required.<br />
* Defense in depth (multiple fixes that would fix the issue) may be a good idea. But be aware that some of the fixes might be too risky for a chemspill release, and it may be worth getting the others out sooner. Falling back to a controlled crash may be better than leaving part of the security bug unpatched.<br />
<br />
When you're reviewing code for a chemspill release (which the author of the code should do too):<br />
* go through all the possible codepaths and understand all of the cases (and do this on all relevant branches, not just mozilla-central)<br />
* a code reviewer should probably rewrite the patch from scratch; you might find interesting things in the differences between the patches.</div>Dbaronhttps://wiki.mozilla.org/index.php?title=Writing_Code_for_Chemspill_Releases&diff=1213421Writing Code for Chemspill Releases2019-06-07T01:52:58Z<p>Dbaron: stub out based on lightning talk I gave last December in Orlando</p>
<hr />
<div>Writing code for a chemspill release is different from writing most other code in Firefox. Chemspill releases are what we do to handle a security vulnerability that's publicly known or being used in the wild. The goal of these releases is to ship very quickly, hopefully in less than 24 hours, from when we learn about the problem. Rollout of these releases is not throttled. So we're shipping code really fast. The code goes to millions of users within hours after release, and very few safeguards exist. There's no chance for users to report bugs, or for us to triage incoming crash reports, or to look at telemetry.<br />
<br />
We've messed these up in the past, to the point of having to ship more dot releases to fix the problems. We've also almost messed up in ways that would have made us do this. We haven't *really* messed up, though, by breaking updates, or breaking the ability to start Firefox and thus update.<br />
<br />
When you're writing code for a chemspill release:<br />
* "probably" isn't good enough. "sounds like it should work" is not good enough. Can you prove it? Go through the things that could possibly go wrong.<br />
* change as little as possible (effects, not diffs). Don't change dependencies, and don't change web-exposed behavior more than absolutely required.<br />
<br />
When you're reviewing code for a chemspill release (which the author of the code should do too):<br />
* go through all the possible codepaths and understand all of the cases (and do this on all relevant branches, not just mozilla-central)<br />
* a code reviewer should probably rewrite the patch from scratch; you might find interesting things in the differences between the patches.</div>Dbaronhttps://wiki.mozilla.org/index.php?title=Standards/Participating_in_a_W3C_Working_Group&diff=1213007Standards/Participating in a W3C Working Group2019-05-29T21:13:07Z<p>Dbaron: /* Technical tips */ link to github settings</p>
<hr />
<div>== Ways to participate (to join or not to join) ==<br />
<br />
W3C working groups have a defined membership: people can become a member of a working group or community group by being nominated by a W3C member company, by being invited by the chairs of the group (an invited expert), or by being a W3C staff member placed on the group by the W3C. However, most W3C working groups have most of their technical discussion on public mailing lists, which means that non-members can participate in many of the activities of the group. So, when you approach a W3C working group, you could decide to do so by becoming a member of the group or just by joining the public mailing list and participating in the discussion.<br />
<br />
How should one choose between these alternatives? While there's a good bit of variation between groups depending on the [http://www.w3.org/Consortium/activities charter] of the group, its chair(s), and the other participants in the group, I suggest considering the following factors:<br />
* being a member of the group signals Mozilla's support for a group to others (e.g., W3C staff, others in the industry). (This means that if the group is working on something we don't like, being a member may confuse other companies into thinking that Mozilla supports or is contributing to the work of the group).<br />
* members of the group may (depending on the charter of the group) have more ability to influence the decisions and the output of the group<br />
* if you want to attend face-to-face meetings or teleconferences of the group, you should be a member of the group<br />
* the group may have expectations that members participate (e.g., by attending phone or face-to-face meetings, by keeping up with certain aspects of the discussion). These vary by group and are described in the "Participation" section of the group's charter.<br />
* some mailing lists may require being a member of the group to subscribe (although this is rare), even when the archives are publicly viewable<br />
* becoming a member of the working group involves making some patent commitments, which may make other participants more comfortable accepting your contributions<br />
* other members of the group may expect somebody representing Mozilla is responsible for implementation work / decisions in Gecko; if you're not, you may wish to consider being extra clear about what your role is<br />
<br />
When you decide you want to participate:<br />
* If you want to just join the [http://lists.w3.org/Archives/Public/ public mailing list]:<br />
*# Send an email to "list-name-request@w3.org" with the subject "subscribe". (Don't forget to add the "-request" to the end of the list name.)<br />
*# Reply to the automated reply.<br />
* If you want to become a member of the working group, and you work for Mozilla:<br />
*# Make sure you have a W3C member access account associated with Mozilla:<br />
*#* if you don't already have a W3C user account, [https://www.w3.org/accounts/request create one], and choose '''Mozilla Foundation''' as the affiliation. Using a @mozilla.com email will lead to the account being created automatically; other email addresses will require human intervention but often (but not always) should be created within a day.<br />
*#* if you have an W3C user account associated with a previous employer or as an invited expert, [https://www.w3.org/Systems/db/userInfo#affiliation change the affiliation of that account] to '''Mozilla Foundation'''<br />
*# Contact Mozilla's Advisory Committee Representative, [[User:Dbaron|David Baron]], and ask him to add you to the group.<br />
<br />
== Suggestions for participation ==<br />
<br />
* Avoid making promises you can't keep, even if pressured to do so.<br />
* Try to avoid speaking on behalf of Mozilla. If the process or other participants in the working group want you to speak on behalf of Mozilla, question such process or participants. However, rather than staying silent in such a situation, it's probably a good idea to both state your position and clearly state how much Mozilla consensus there is behind that position. Though it's not an ideal situation, it's ok for Mozilla's employees to disagree with each other on the best way to move the Web forward and implement Mozilla's mission.<br />
<br />
== Technical tips ==<br />
<br />
* Many W3C working groups work using GitHub. Your github account should have a readable version of [https://github.com/settings/profile your name and affiliation and preferably a short relevant biography], so that people can recognize you as the person who joined the working group, and can know what implementation you work on.<br />
* You should [https://www.w3.org/users/myprofile/connectedaccounts connect your github account to your W3C account] in order to make IPR-checking bots (which some working groups use) happy.<br />
<br />
== Suggestions for chairing ==<br />
<br />
If you end up as the chair of a group, you should become more familiar with the process, since you'll sometimes be responsible for enforcing them (along with a team contact, if the group is a working group). Some documents that are helpful are:<br />
* [https://www.w3.org/Consortium/Process/ W3C Process] (for working groups)<br />
* [https://www.w3.org/community/about/agreements/#cgroups community group process] (for community groups)<br />
* [https://www.w3.org/Guide/ The Art of Consensus: A Guidebook for W3C Group Chairs and Participants]<br />
* [https://www.w3.org/Consortium/cepc/ W3C Code of Ethics and Professional Conduct]</div>Dbaronhttps://wiki.mozilla.org/index.php?title=Standards/Participating_in_a_W3C_Working_Group&diff=1212975Standards/Participating in a W3C Working Group2019-05-29T04:14:07Z<p>Dbaron: /* Technical tips */ github user info</p>
<hr />
<div>== Ways to participate (to join or not to join) ==<br />
<br />
W3C working groups have a defined membership: people can become a member of a working group or community group by being nominated by a W3C member company, by being invited by the chairs of the group (an invited expert), or by being a W3C staff member placed on the group by the W3C. However, most W3C working groups have most of their technical discussion on public mailing lists, which means that non-members can participate in many of the activities of the group. So, when you approach a W3C working group, you could decide to do so by becoming a member of the group or just by joining the public mailing list and participating in the discussion.<br />
<br />
How should one choose between these alternatives? While there's a good bit of variation between groups depending on the [http://www.w3.org/Consortium/activities charter] of the group, its chair(s), and the other participants in the group, I suggest considering the following factors:<br />
* being a member of the group signals Mozilla's support for a group to others (e.g., W3C staff, others in the industry). (This means that if the group is working on something we don't like, being a member may confuse other companies into thinking that Mozilla supports or is contributing to the work of the group).<br />
* members of the group may (depending on the charter of the group) have more ability to influence the decisions and the output of the group<br />
* if you want to attend face-to-face meetings or teleconferences of the group, you should be a member of the group<br />
* the group may have expectations that members participate (e.g., by attending phone or face-to-face meetings, by keeping up with certain aspects of the discussion). These vary by group and are described in the "Participation" section of the group's charter.<br />
* some mailing lists may require being a member of the group to subscribe (although this is rare), even when the archives are publicly viewable<br />
* becoming a member of the working group involves making some patent commitments, which may make other participants more comfortable accepting your contributions<br />
* other members of the group may expect somebody representing Mozilla is responsible for implementation work / decisions in Gecko; if you're not, you may wish to consider being extra clear about what your role is<br />
<br />
When you decide you want to participate:<br />
* If you want to just join the [http://lists.w3.org/Archives/Public/ public mailing list]:<br />
*# Send an email to "list-name-request@w3.org" with the subject "subscribe". (Don't forget to add the "-request" to the end of the list name.)<br />
*# Reply to the automated reply.<br />
* If you want to become a member of the working group, and you work for Mozilla:<br />
*# Make sure you have a W3C member access account associated with Mozilla:<br />
*#* if you don't already have a W3C user account, [https://www.w3.org/accounts/request create one], and choose '''Mozilla Foundation''' as the affiliation. Using a @mozilla.com email will lead to the account being created automatically; other email addresses will require human intervention but often (but not always) should be created within a day.<br />
*#* if you have an W3C user account associated with a previous employer or as an invited expert, [https://www.w3.org/Systems/db/userInfo#affiliation change the affiliation of that account] to '''Mozilla Foundation'''<br />
*# Contact Mozilla's Advisory Committee Representative, [[User:Dbaron|David Baron]], and ask him to add you to the group.<br />
<br />
== Suggestions for participation ==<br />
<br />
* Avoid making promises you can't keep, even if pressured to do so.<br />
* Try to avoid speaking on behalf of Mozilla. If the process or other participants in the working group want you to speak on behalf of Mozilla, question such process or participants. However, rather than staying silent in such a situation, it's probably a good idea to both state your position and clearly state how much Mozilla consensus there is behind that position. Though it's not an ideal situation, it's ok for Mozilla's employees to disagree with each other on the best way to move the Web forward and implement Mozilla's mission.<br />
<br />
== Technical tips ==<br />
<br />
* Many W3C working groups work using GitHub. Your github account should have a readable version of your name and affiliation, so that people can recognize you as the person who joined the working group, and can know what implementation you work on.<br />
* You should connect your github account to your W3C account at https://www.w3.org/users/myprofile/connectedaccounts in order to make IPR-checking bots (which some working groups use) happy.<br />
<br />
== Suggestions for chairing ==<br />
<br />
If you end up as the chair of a group, you should become more familiar with the process, since you'll sometimes be responsible for enforcing them (along with a team contact, if the group is a working group). Some documents that are helpful are:<br />
* [https://www.w3.org/Consortium/Process/ W3C Process] (for working groups)<br />
* [https://www.w3.org/community/about/agreements/#cgroups community group process] (for community groups)<br />
* [https://www.w3.org/Guide/ The Art of Consensus: A Guidebook for W3C Group Chairs and Participants]<br />
* [https://www.w3.org/Consortium/cepc/ W3C Code of Ethics and Professional Conduct]</div>Dbaronhttps://wiki.mozilla.org/index.php?title=Travel_Guide&diff=1204845Travel Guide2018-12-06T23:22:06Z<p>Dbaron: /* Trains */ start a section on trains</p>
<hr />
<div>----<br />
:: This page was originally created on Mozilla's internal intranet. However, it contains lots of information that could be useful to Mozillians who travel to Mozilla events, or really, anyone who travels, period. The original page (and its history) disappeared when the intranet site was retired.<br />
----<br />
<br />
Travel doesn’t have to suck. In fact, there are probably relatively few parts of your life where optimizations can make such a difference. We (the authors) have millions of miles travelled between us.<br />
<br />
* We never lose our luggage.<br />
* We can get from the airport entrance to our gate in 7 minutes.<br />
* We get free booze at the airport, upgraded flights, nicer rooms in hotels.<br />
* We don’t eat crap on the road, indeed we often discover great restaurants.<br />
* We have secrets.<br />
<br />
Let us show you them.<br />
<br />
But first, '''the 3 simplest things you can do to make travel a lot better''':<br />
<br />
# Don’t check luggage<br />
# Check in online<br />
# Pick a Frequent Flyer program<br />
<br />
Do those three and you’re already in the 80th percentile for travel success. What follows below is travel brilliance.<br />
<br />
= Planning =<br />
<br />
== Quick Tips ==<br />
* Scan a copy of your passport and any other travel documents, and put them somewhere web accessible but password protected (like Dropbox or Google Drive). This is helpful for getting replacements, and for getting consular help in the meantime.<br />
* Let your credit card company know that you travel. Anti-fraud measures might lock your card the first time you use it on foreign soil, but they can flag your account so that doesn’t happen. This is no fun to discover after the fact.<br />
<br />
== Pick a Frequent Flyer Program ==<br />
<br />
Prices are generally going to be competitive, so figure out your most common trip(s) and figure out which airline/alliance is best for those. Use that group for everything. You can easily sign up for FF programs online, and add it to your travel agency profile (Egencia for Mozilla employees).<br />
<br />
Even if you travel rarely, you'll eventually accrue enough mileage for free travel, and having a FF number makes online check-in easier.<br />
<br />
If you travel often enough, though, (25k+/year on most airlines) you start earning preferred status. This is the difference between "scum" and "How can I help you?" You have shorter lines for agents, shorter lines for security, you board first. You get access to elite lounges while you wait, and free upgrades to business class to make the trip more pleasant. These are little niceties, but they add up, and make travel much nicer. You can often share status with someone less privileged, which means your spouse likes traveling with you more, too.<br />
<br />
== Check In Online ==<br />
<br />
Every airline will let you check in online, usually 24 hours before your flight leaves. I know this will feel weird the first time, but it is an absolute necessity. With online check-in and no checked luggage, you can skip all the lines at the airport except security (and possibly customs/immigration).<br />
<br />
Checking in early may put you into a lower "group" for boarding (or at least not the suckiest, all-the-overhead-bins-are-full group). Check in as early as possible, even if you don't know how many bags you will check (correct answer: 0). You can always add (and pay for) checked bags when you get to the airport.<br />
<br />
The one '''exception''' to this guideline is that if you think your flight might be delayed or cancelled due to weather, ''don't'' check in online ahead of time. If you have to re-book, and you are already checked-in, the agent will have to "uncheck" you, which may slow down the re-booking process and cause you to miss out on alternate flight options. Keep in mind that weather problems cause ripple effects even in locations where weather is good. For example, your flight out of sunny Phoenix might be cancelled because the aircraft is grounded by a snowstorm in Chicago. (See this Egencia blog post for [http://info.egencia.com/wintertraveltips2014.html tips for avoiding weather delays].)<br />
<br />
Online check-in also lets you choose your seats, which brings us to...<br />
<br />
== Choose Your Seats ==<br />
<br />
* Take a window seat for very short flights or very long flights. Window seats have more shoulder room, less hassle from other passengers, and a window. The only downside is bladder management, but on short flights you can stick it out and on long ones you can get up when your fellow passengers do.<br />
* ''Every'' plane has some seats that suck. No recline, noisy, cold, lack of floor storage or slightly narrower than most, [http://www.seatguru.com SeatGuru] will tell you what to avoid. It'll also tell you which seats are great (extra legroom, etc) that you should take given half a chance. Usually, exit-row seats have extra legroom (good for tall people), and the last row and the row in front of the exit row do not recline (bad in general). The first row in a section (where you have a bulkhead in front of you instead of another seat) typically does not have under-seat storage, so everything must go in overhead bins, but it typically does have more legroom. (Seatguru will tell you whether or not this is the case on a particular plane.)<br />
* ''The Middle Seat Gambit'' - If you’re traveling with someone else, check in online together and look for an empty 3-person row. Take the aisle and window. Middle seats fill up last, there’s a decent chance the seat stays empty. If so, you have a lot more space to dump things during the flight, and more legroom since you can use that space instead of putting things under the seat in front of you.<br />
* If you’re traveling alone, you can still use the middle seat gambit by checking in online and looking at the seat map for someone acting as a de facto accomplice.<br />
* If there is only one (worst possible) seat left when you go to select seats, ''don't take it''. It will be claimed by someone else, and the gate agent will assign you a different seat. A flight that full might mean that someone gets bumped, but lack of a seat assignment doesn't guarantee it will be you.<br />
<br />
== Manage Layovers ==<br />
<br />
Flying nonstop to your destination is always easiest, but if that’s not a possibility for whatever reason, here are some other things to keep in mind:<br />
<br />
* Major metropolitan centers are often served by multiple airports, and each airline will have a preference. If you can’t get the flight you want with the airline you like, look to see whether you’re just pointing at the wrong airport.<br />
* If you can’t fly nonstop, you probably at least have your choice of connection airports, and the choice matters there. What’s more, a given airline will have certain preferred connection cities, so a couple trips should get you a reasonably complete list. (For example, connecting from Toronto to San Francisco on Star Alliance, it is much preferable to connect in Denver or Vancouver than it is to connect in Chicago O’Hare.) Consider the immigration/customs procedures of the country you're connecting in if it's separate from the origin or destination (e.g., prefer Vancouver over a US airport for connecting between Toronto and Auckland, since the US requires internationally-connecting passengers to go through immigration and customs).<br />
* If you have to have a connection, you might also have the opportunity to fly to a better airport (e.g., if you have to connect to Washington, DC, you are likely to be able to fly to DCA instead of IAD).<br />
* Take the season and likely weather into account when picking connecting airports; avoid snowy airports in winter, thunderstorm-y airports in summer.<br />
* If you have to layover overnight, prefer airports that have on-site hotels (and for god’s sake prefer Munich over Frankfurt).<br />
* If you’re crossing a border during your flight, it’s often preferable to layover in-country before crossing over. It means your first flight is domestic, so you can arrive later at the airport since there’s no immigration headache there. <br />
* Another reason not to check a bag is that when you have a connection after arriving in some countries (e.g., the USA, but not EU countries), you have to claim your bag, take it through customs (even though they rarely look at it), and then check it again for your connecting flight. More time and hassle.<br />
* Remember to account for boarding time when calculating layovers. If flight A arrives at 12:00 and flight B leaves at 1:00, you do not have an hour, you have about 20 minutes (because you need to get OFF of flight A once it arrives, transit to whichever gate/terminal flight B is in, and then be there for flight B '''boarding''', not flight B '''departure''').<br />
<br />
= Immigration and Customs =<br />
<br />
== General advice ==<br />
* Make sure you know what the requirements are for crossing all immigration and customs barriers before you do so. If you don't know what those requirements are, embassy or consulate websites are often useful, as are the US government's [http://travel.state.gov/content/passports/english/country.html country specific information] (though somewhat tending towards information useful to Americans).<br />
* Make sure you have any documentation needed in your carry-on luggage. When entering a country where you're not a citizen or resident, you should carry proof of onward travel, particularly if the reservation on which you're flying doesn't return you to your home country (e.g., because you're traveling on separate reservations).<br />
* If you're ''transferring'' in a country (or multi-country immigration zone) that's different from your origin or destination, figure out whether you'll need to deal with immigration there, and if so, what the rules are. This might vary depending on the airport, or in some cases even on which terminal you arrive at and depart from. (In the latter case, airport websites are often helpful.)<br />
* always carry a pen (blue or black) somewhere in your checked luggage for filling out the immigration and customs forms<br />
<br />
== Country-specific notes ==<br />
<br />
=== USA ===<br />
* visitors under the [https://travel.state.gov/content/travel/en/us-visas/tourism-visit/visa-waiver-program.html visa waiver program] (those who don't need a visa) must apply online for an [http://www.cbp.gov/travel/international-visitors/esta ESTA].<br />
<br />
=== Canada ===<br />
* visitors who do not need a visa, are entering Canada by air, and are not US citizens or Canadian citizens or Canadian permanent residents, must apply online for an [http://www.cic.gc.ca/english/visit/eta.asp eTA].<br />
<br />
=== Schengen Area (Europe) ===<br />
* The [http://en.wikipedia.org/wiki/Schengen_Area Schengen Area] is an immigration-barrier-free zone covering most of the European Union and some additional non-EU countries, but not the UK or Ireland.<br />
* If you need a visa to visit the Schengen Area, it is easier to get such a visa if your point of arrival in the Schengen Area is the same country as your destination. (For example, if you're traveling to Spain, it is easier to arrive in Madrid after connecting in the UK or US than connecting via Amsterdam, since in the latter case getting the visa requires dealing with both the Spanish and Dutch authorities.)<br />
* If your nationality requires a visa to visit the Schengen Area and your trip does not terminate in Schengen, avoid making more than one connection in Schengen; in such a case you must get a Schengen visa, even though that's not your destination. Schengen immigration authorities look at your ''next'' point of travel (not your final one) to decide whether you need a visa; if it is Schengen, they will ask for one.<br />
<br />
=== New Zealand ===<br />
* Make sure to declare any shoes in your checked luggage. The authorities just want to look at them and maybe clean the dirt off for you, but they'll be upset if you don't declare them.<br />
* Don't even think about [http://www.nzherald.co.nz/nz/news/article.cfm?c_id=1&objectid=11404025 bringing fresh fruit] into New Zealand or you will get an instant fine.<br />
<br />
=== Australia ===<br />
* Visitors who can can enter without a visa must apply online for an [https://www.eta.immi.gov.au/ ETA].<br />
<br />
= Packing =<br />
<br />
'''Quick Tips'''<br />
* Have a toiletry bag that you keep stocked, rather than trying to remember to pack toothbrushes &c the day of. It doesn’t cost much to buy the duplicates once, and saves hassle/forgetting.<br />
* Put your favourite head, stomach, and sleep meds in the toiletry bag. You can buy most things on the road, but meds are sometimes an exception.<br />
* Throw a couple of large ziploc bags in there, too. They are immensely useful for storing wet clothing or leaking bottles or, by contrast, for putting things like passports in when you need them to stay dry. They weigh nothing and disappear into a pocket until needed.<br />
* Layers. You can adapt to a wide range of climates, even multi-city travel, by packing layers. Shirt, Sweater, Hoodie, Jacket is plenty warm, packs much more compactly than a parka, and gives you middle ground for an overwarm restaurant or an overcool office.<br />
* While you're packing, make a text list on your phone of everything you pack. Towards the end of your trip (such as waiting for your flight home), put a '+' next to every item you actually used. Next time, don't pack the things you didn't use. Also, if your bag goes missing, you have a list of what was in it.<br />
<br />
== Don’t Check Luggage ==<br />
<br />
:: Repeat after me: Checked luggage is for chumps.<br />
<br />
:: Again. Checked luggage is for chumps.<br />
<br />
:: -- George Clooney, ''Up in the Air''<br />
<br />
Every time you give your bag to the airlines, you're inviting them to lose it, abuse it, leave it in your departure city, forget about it on the tarmac during a rain delay, etc. North American airlines will allow you one carry on suitcase and one “personal bag” which usually means a purse or laptop. This is easily enough for a week of travel, and can be extended indefinitely with laundry service. Invest in a good carry-on and bring it with you.<br />
<br />
Put everything you need during the flight in your laptop bag, in case you have to gate-check your carry-on suitcase (common on short flights with smaller planes).<br />
<br />
== Choose the Right Luggage ==<br />
Checked luggage will inevitably be destroyed over time, regardless of quality. If you stick to carry on, though, good luggage will last forever; be willing to pay once for something that gets it right. Your happiness while traveling is worth it.<br />
<br />
His bias for non-rolling luggage notwithstanding, [http://www.onebag.com/bags.html this is the single best guide out there] for evaluating luggage. The highlights:<br />
<br />
* Lighter is better<br />
* Curvy designs rob you of packing volume, prefer right angles<br />
* Chain zippers are stronger than coil zippers (look for YKK as the brand of zipper)<br />
* Pocket design and positioning matters<br />
* So do tie-downs<br />
<br />
In truth, the best way to maximize quality while minimizing weight is to let go of the dependence on rolling bags. Soft-sided, non-wheeled bags are exceptionally light and versatile. [http://www.tombihn.com Tom Bihn] and [http://www.redoxx.com/ Red Oxx] are your best plays. Tom Bihn’s Aeronaut is is a full-sized carry-on that converts to a backpack for long walks across cobblestones/sprints to catch a connection/etc. The Red Oxx Air Boss was designed by the same guy who wrote the luggage-choosing guide above.<br />
<br />
If you're not ready to let go of wheeled bags, any manufacturer with a lifetime warranty is probably worth considering. These include:<br />
<br />
* [http://www.briggs-riley.com/ Briggs & Riley]<br />
* [http://www.travelpro.com Travelpro] ("the best" carry-on according to [http://thewirecutter.com/reviews/best-carry-on-luggage/ The Wirecutter])<br />
* Certain models of [http://shop.eaglecreek.com/lightweight-carry-on/l/111 Eagle Creek] (not all models have a lifetime warranty)<br />
<br />
Pay attention to the bag’s extensible arm: is it well constructed? What does it do to your interior space? 2 segments of extension or 3? Moving parts make everything more fragile -- if you are choosing moving parts in your luggage, they need to be brilliant.<br />
<br />
== Buy It There (BIT) ==<br />
<br />
Don’t try to anticipate every contingency and pack for it. You will bog yourself down with unnecessary cruft. Pack for what you ''know'' you’ll need, or at most what you reasonably expect to need the majority of the time. You can find contact solution, toothpaste, aspirin, and dental floss at almost any convenience store. For the rest, shove an extra $50 into a pocket somewhere and buy whatever you need there, if it comes up. <br />
<br />
(Good news: It comes up less often than you’d think.)<br />
<br />
BIT exceptions: <br />
There are some things you don't want to source while traveling - if you only use one specific brand of shampoo, conditioner, etc, transfer it to a small, travel-friendly bottle. Depending on where you're traveling BIT can be tough if you don't speak the language and are looking for something very specific (like Cipro in India or a flat iron in China). Goes without saying, but BIT does *not* apply to medications (remember that what requires a prescription varies by country, but you can apply it if you know that something can be bought without a prescription at your destination).<br />
<br />
=== Corollary: Wash It There ===<br />
If you’re gone for longer than a carry-on can reasonably contain (which is longer than you think), don’t fail over to multiple suitcases; just get things laundered partway through. Your hotel will offer laundry service, though it will be overpriced. Most of the time you’ll find a wash and fold place within walking distance or a service that does pick up and next day drop off.<br />
<br />
Also keep in mind that at most Mozilla or other geek events, you will probably acquire at least one or two t-shirts. You can bring one or two fewer shirts; if this guideline fails, wash one of the ones you brought.<br />
<br />
If you bring quick-drying underwear and socks, you can wash them in the sink or bathtub and dry them overnight on the towel rack (except in humid climates). You can skip bringing detergent by using the hotel's shampoo (as long as you don't mind your underwear smelling like "ginger lemongrass" or whatever); shampoo is just mild detergent. Check the plumbing before you fill the sink; some hotels don't install the lever for raising the plug. Before hanging items to dry, roll them in a towel and squeeze out excess moisture.<br />
<br />
== Counterpoint: The case for checking a suitcase ==<br />
A few heavy-traveling Mozillians are in the "checked bag" camp. Add your reasons for using this strategy here:<br />
* Problems with checked luggage are actually quite rare.<br />
* You don't have to schlep a roll-aboard through the airport with you, including squeezing it into tiny toilet stalls.<br />
* You can pack a few extra things that help you be more comfortable on an extended trip.<br />
* At least one airline (American) gives early boarding privileges (after Elite and Priority but before Zone 1) to passengers with no overhead baggage.<br />
* You aren't limited to 100ml bottles of liquid/gel/cream, and can bring home ''properly packed'' wine, booze, perfume, etc. (Wrap the bottle in at least two plastic bags and nestle it in the groove left by the extending handle, surrounded tightly by clothes.)<br />
* Having airline status often helps your bag appear on the belt faster. Also, if the final segment of your trip is an international arrival in the United States, you're unlikely to have to wait long for your bag, since all baggage goes to the same belt, so it gets there quickly.<br />
* TIP: Get a suitcase with four wheels. Baggage handlers can slide it across the floor of the cargo hold instead of tossing it, subjecting the suitcase and its contents to much less abuse. Anything that protrudes, like carry straps or zipper pulls, can get snagged and chewed up in baggage-handling equipment; go for streamlined.<br />
* TIP: Ask for your checked luggage to be marked "Fragile". It will be loaded on top of other bags, and usually be unloaded first.<br />
* TIP: If you check luggage, don't let your eyes off the bag until there's a tag on it, and if you can, check that the tag is correct (with your name and correct destination airport on it). One of the common reasons for lost/delayed luggage is getting the wrong tag on it right at the check-in desk.<br />
* TIP: Things to make sure are '''not''' in your checked bag: everything you need to get through customs and immigration and get to your final destination. Any electronics that might be stolen. Lithium-ion batteries (prohibited).<br />
<br />
Some airlines (particularly non-North American ones) have much lower limits for what you're allowed to carry on, so you'll have to check luggage anyway.<br />
<br />
Some airlines (e.g., Air France, KLM) will even want to weigh your carry-on bag (often although not reliably), and want it to be a weight that's lower than what it is with your laptop in it (e.g., 6kg, 8kg). Remember that your laptop often counts as a separate personal item and you can take it out of the bag before weighing.<br />
<br />
==Packing Techniques and Tools==<br />
Your strategy for how to put your stuff in your suitcase is very much a matter of personal preference, along with the type of travel you're doing (destination vs. touring) and the type of clothes you bring. Here are some ideas that may be helpful.<br />
<br />
* The [http://www.onebag.com/pack.html bundle method] is great for avoiding wrinkles, but it tends to require that you unbundle ''everything'' to get out any single thing.<br />
* It's extremely helpful to have some kind of containers to organize your stuff. Purpose-made packing "cubes" are great, but are absurdly expensive. You can get by with zip-top plastic bags if you don't travel often, or while you're waiting to find ready-made cubes on sale. <br />
* If you buy only one packing accessory, consider getting a [http://www.amazon.com/Eagle-Creek-Travel-Pack-It-Folder/dp/B002YIRC3O/ packing folder], which helps you fold larger items (shirts, pants, skirts) to a uniform footprint, and then encloses them like an envelope.<br />
* Compression bags, which let you squeeze all the air out of your clothes, are good only for clothes that don't easily wrinkle. However, a compression bag can be great as a laundry bag to minimize the volume of dirty clothes on your way home.<br />
<br />
= Airport Hacking =<br />
'''Quick Tips'''<br />
* ABC: Always Be Charging. Wherever you come to rest, be charging. Maybe your flight has power plugs, that's swell, but maybe they stop working, or your seatmate gets to it first, or you need it to charge your phone. If you're at rest for more than 10 minutes, find a plug. If you bring a power strip so others can plug in, too, you can make friends anywhere :-)<br />
* Watch where uniformed crew members go. They know the best eateries in any given airport, and even where to stand on the tram platform in order to get off quickly at the other end.<br />
* The internet knows about delays before your gate agents do. Bookmark [http://flightaware.com/live/ flightaware] right now, and use it from your phone at the airport to keep tabs. Caveat: Flightaware may show your flight as delayed because the inbound plane you're getting on is delayed; if the airline substitutes another aircraft, your flight could be on time or only a little delayed.<br />
* If you do see signs of a significant delay, particularly at night when it's likely you'll be put off until morning, act swiftly before the lines form. Talk to gate agents about rebooking onto other flights and if the line there is long, be on the phone with your airline as well. First to rebook means first to call hotels and taxis and all the rest. Being last to rebook means sleeping in the airport. If you have elite status, call the customer service number for elite members, not the general customer service number.<br />
* When you get off the plane, the restroom closest to your gate will be crowded with other people from your flight. Keep going to the next one further away.<br />
* No one wants to sleep in an airport, but flight delays or cancellations, or just poor planning, may require it. There is actually a whole website devoted to [http://www.sleepinginairports.net/tips.htm sleeping in airports].<br />
<br />
<br />
== Being prepared for security ==<br />
* Bring identification. [http://www.tsa.gov/traveler-information/acceptable-ids Here's a list of acceptable IDs] in the US. If you forget your ID, all is not lost. It's possible, with some extra hassle, to travel within the US even if you don't have your identification. [http://blog.tsa.gov/2013/04/tsa-travel-tips-tuesday-can-you-fly.html Here's what the TSA says to do if you don't have ID.]<br />
* Avoid getting into a screening line behind people who look like they don't travel often (families with kids, retirement-age folks, large groups).<br />
* Wear slip-on shoes (and wear socks if you don't want your feet getting dirty).<br />
* Consider not wearing a belt, or wear one with no metal, so you don't have to take it off.<br />
* Avoid clothes with extra pockets, like cargo pants. They can be flagged by the nudie-scan, and cause you to get a pat-down. Same for "travel" clothes with hidden pockets; these can be handy while touring, but not while flying. Even a hoodie can win you a pat-down for the hood and kangaroo pocket. <br />
* On the other hand, a jacket with lots of pockets is like an extra carry-on; you have to remove it for security anyway, and you can keep your in-flight necessities (gadgets, etc.) close to hand during your flight.<br />
* Know the drill with liquids, gels, and creams: containers at most 100ml/3oz, in a clear zip-top bag, 1 liter/1 quart size. Have this in an external pocket of your carry-on, ready to pull out and put in a bin. (If you travel often, you might want to get a sturdier bag than the grocery store kind. It must still be clear and zip-top.)<br />
* Avoid large metal jewelry.<br />
* Take everything, but especially metal (keys, coins, etc.), out of your pockets.<br />
* Leave your pocket knives and multitools at home.<br />
* If you're wearing an activity monitor, such as a FitBit, take it off for screening.<br />
* You should hang onto your ID and boarding pass as you go through the line, but you can't carry them through screening; put them in your bin.<br />
* Put the bin with your shoes, jacket, and liquids onto the conveyor belt first. You can be getting dressed while the rest of your stuff comes through.<br />
* Take your laptop out of your bag and put it in a separate bin. You can usually leave it in a sleeve, as long as there's nothing else in the sleeve. <br />
* Consider getting a checkpoint-friendly laptop bag, with a laptop-only section that folds out without taking out the computer. The less you handle your laptop, the less likely you are to drop it. (US TSA allows you leave the computer in this type of bag; other countries often do not.)<br />
* Don't go through the screening machine until your stuff is on the conveyor belt.<br />
<br />
== US Trusted Traveler Programs ==<br />
If you frequently cross US borders, you can save time and hassle in the long run by enrolling in one of the programs that provide expedited entry for pre-approved travelers. Enrolling involves an application fee and form, and an in-person interview at an entry point, so there is a start-up cost in time and money. Which program you should enroll in depends on the type of crossing you do most; you can enroll in more than one. <br />
<br />
* When entering the US, if you're not in a "trusted traveler" program, try to get into the immigration queue that is ''next to'' the Global Entry lane. If no one is in the Global Entry lane, the officer there will often take people from the nearby queue, making it move faster. Do likewise for NEXUS when entering Canada.<br />
* Wear Firefox gear when going through immigration, anywhere. It creates goodwill and starts pleasant conversations.<br />
<br />
===Automated Passport Control===<br />
Automated Passport Control kiosks are available to citizens of the US, Canada, and [http://www.cbp.gov/travel/international-visitors/frequently-asked-questions-about-visa-waiver-program-vwp-and-electronic-system-travel Visa Waiver Program] countries, for entry into the US, in an expanding number of North American cities. Unlike Global Entry or Nexus, these kiosks require no pre-registration. You swipe your passport, let the kiosk take a photo, answer some questions, and then get a receipt that you show to a Customs and Border Patrol officer. The kiosk replaces filling out a customs card by hand.<br />
<br />
See the [http://www.cbp.gov/travel/us-citizens/Automated%20Passport%20Control Automated Passport Control] webpage for a list of cities with APC kiosks.<br />
<br />
=== Global Entry ===<br />
[http://globalentry.gov/about.html Global Entry] provides expedited screening for entry ''into'' the US at certain airports. Once in the program, you can go to an automated kiosk instead of an immigration agent (skipping the enormous lines that result from multiple international flights arriving at about the same time), and you can answer the customs questions at the kiosk instead of filling out a paper form. Unless there is an issue with your kiosk interaction (such as it couldn't read your fingerprints), you don't need to talk to a CBP agent. Global Entry is open to U.S. citizens, lawful permanent residents of the U.S., Dutch citizens, South Korean citizens and Mexican nationals.<br />
<br />
=== NEXUS ===<br />
[http://www.globalentry.gov/nexus.html NEXUS] provides expedited screening for crossing the US-Canada border in both directions. It can be used at land and sea entry points as well as at airports. You can use the NEXUS-only lanes at land crossings only if every person in the vehicle (including children) has a NEXUS card. Using NEXUS at an airport requires scanning your irises. If you wear contact lenses, you must remove them for the initial iris scan that is taken after your enrollment interview.<br />
<br />
=== Other US programs ===<br />
* [http://www.globalentry.gov/netherlands.html FLUX] expedites passage between the US and '''the Netherlands''', and is open to US and Dutch citizens.<br />
* Global Entry members can receive expedited entry into '''[http://www.globalentry.gov/newzealand.html New Zealand]'''.<br />
* [http://www.globalentry.gov/sentri.html SENTRI] provides expedited entry into the US from '''Mexico''' at specific land crossings.<br />
* [http://www.globalentry.gov/korea.html Smart Entry Service] provides expedited entry into the Republic of '''Korea'''. It is open to US and Korean citizens.<br />
* [http://www.globalentry.gov/smartgate.html SmartGate] provides streamlined entry into '''Australia''' for US Global Entry members. Visa requirements still apply.<br />
* [http://www.globalentry.gov/tsa.html TSA PreCheck] enables US Global Entry and Canadian NEXUS members to use designated TSA airport screening lanes, without removing liquids, laptops, shoes, jackets, or belts. You must provide your membership number when booking flights with participating airlines. TSA is expanding the PreCheck program to include more people, including US military members and those invited by their airline's frequent flyer program. You must still apply, pay a fee, and go through an interview. See the [http://www.tsa.gov/tsa-precheck TSA PreCheck] website for details.<br />
<br />
== Other countries' traveler programs ==<br />
* The UK's [https://www.gov.uk/registered-traveller Registered Traveller service] enables certain citizens of Australia, Canada, Japan, New Zealand and the USA to get faster entry to the UK, without filling out a landing card. <br />
<br />
<br />
Still to write:<br />
* priority security lanes<br />
* being nice to security<br />
* priority boarding (travel with a colleague who has priority status as their guest if you don't have it yourself)<br />
* lounges<br />
* watch your crew<br />
<br />
= Flying =<br />
<br />
'''Quick Tips'''<br />
* Hydrate, hydrate, hydrate. Air in an airplane at altitude is incredibly dry and dries you out. Drink water whenever you can. Bring an empty water bottle (even better: collapsible) and fill it from a water fountain inside security. (Some airports, like SFO, have water bottle filling spots that make this a little easier.) Don't drink the water that comes out of the water tanks onboard an airplane, including coffee and tea; you don't want to know how disgusting those tanks are. If you get water in the beverage service, ask for fizzy water (club soda) to ensure it came out of a bottle or can. If you need to brush your teeth in-flight, use water from your water bottle, not the tap in the toilet.<br />
* Request an alternate meal (kosher, indian, vegan, whatever) - they tend to be tastier, and often come first. (However, the downside to the meal coming first is that the tray is going to be in your way substantially longer.)<br />
* If you're in an aisle seat, you’ll find that the aisle-side armrest won’t lift. This is annoying, because it is much easier to deplane with that thing out of the way. Reach back to where the armrest joins the back of the chair -- there may be a release latch or button. (This works on some Boeing 777s; most smaller craft do not have this feature. See [http://brokensecrets.com/2011/01/17/raising-the-airplane-aisle-armrest/ this article] for a photo.)<br />
* Always wear shoes before going to the airplane lavatories; never go barefoot or wearing socks only. <br />
<br />
== Headphones ==<br />
Enjoying music or movies during travel is much better with headphones designed for travel use. You need to consider three types: <br />
* active noise-cancelling headphones<br />
* those without noise-cancellation<br />
* in-ear monitors. <br />
Generally speaking, on airplanes, active noise-cancellation will be better on the plane but worse when you're not on the plane (in the hotel room, for instance.) A quality headphone without noise cancellation will almost always sound better when not on an airplane. In-ear monitors allow for excellent sound quality and also allow one to rest your head on a pillow without the headphone pushing against one's ear, but some are uncomfortable with putting anything in one's ear. In-ear monitors are also much more compact. For those who want the sound quality of in-ear monitors and the compactness, but find that fit is a problem, consider Comply foam tip replacements which can be selected to fit your ear size.<br />
<br />
* For active noise cancellation headphones, the Bose Quiet Comfort 15 is the most popular model sold and for good reason. However if you want the headphone to be good when the noise-cancellation is turned off, you may want to consider the [http://www.psbspeakers.com/products/headphones/M4U-2-Headphones Psb m4u 2], which is more expensive but also more versatile.<br />
* For headphones without active noise cancellation, consider rugged models that have reputations burnished by decades of use by audio professionals such as the Sennheiser HD-25 1-ii. Another popular option is the V-Moda M-80 which has similar sound quality, has a good reputation for build quality, and also comes with a nice travel case.<br />
* For in ear monitors, there are too many to list but one line that is very popular is the Shure SE series which have models from $99 on up. These are very rugged models which allow for replaceable cables, replaceable tips and have very good sound quality.<br />
Additional resources for headphones include [http://www.innerfidelity.com/content/innerfidelitys-wall-fame Innerfidelity's Wall of Fame] and Head-fi.org's [http://www.head-fi.org/t/618255/check-out-the-head-fi-summer-2012-buying-guide 2012 Summer Buying Guide].<br />
<br />
== Make friends with TSA and your flight crew ==<br />
<br />
Airplanes are a sea of grumpy, tired, unhappy people. A little friendliness goes a long way -- especially if you're regularly flying the same route with the same flight crew.<br />
<br />
== Seat etiquette ==<br />
The following tips are about showing consideration to your fellow passengers, who unfortunately may not even notice it. But violating these norms is likely to cause annoyance. You don't want to be "that guy", do you?<br />
<br />
* The person in the middle seats gets to use both armrests. The people in the window and aisle seats get a little extra space, so yielding one armrest each is the least they can do. In any case, try to keep your elbows in your own space.<br />
* Consider the person behind you before reclining your seat into their space, especially if they are trying to eat or use a laptop. Avoid reclining abruptly (though it's not always possible to control this). Raise your seat back during meals.<br />
* If you need to leave your seat during the flight, try to avoid hoisting yourself up by yanking on the seat in front of you. This may be difficult to avoid if the seat is reclined (see above).<br />
* If you have an individual touchscreen in the seat back in front of you, jabbing it forcefully doesn't make the touchscreen work any better. If it's really not responding to touch input, try controlling it from the armrest controls.<br />
<br />
* [http://www.independenttraveler.com/travel-tips/travelers-ed/the-etiquette-of-seat-backs-and-elbow-room The Independent Traveler: The etiquette of seat backs and elbow room]<br />
<br />
<br />
<br />
Still to write:<br />
* how to sleep (Needs to be written by someone who is actually able to sleep on planes)<br />
** [http://gizmodo.com/how-to-get-the-best-sleep-of-your-life-on-an-airplane-1598708044 Gizmodo: How to get the best sleep of your life on an airplane]<br />
** [http://www.independenttraveler.com/travel-tips/travelers-ed/sleeping-on-planes Independent Traveler: Sleeping on Planes]<br />
* move on long flights<br />
<br />
= Tips for specific airports =<br />
As a general rule of thumb, in any airport, the terminal or concourse that serves international flights has nicer shops and restaurants than the areas for domestic flights. So, if you're traveling domestically, have time to kill, and can get into the international terminal without going through passport control, you might want to go hang out there.<br />
<br />
== AMS Amsterdam ==<br />
* in the international section (only?), there are nice quiet places to sit on the upper level outside the lounges (even if you don't have lounge access)<br />
* if you want to take the train to/from the airport, hoard coins (€4 to Amsterdam-Centraal, less to Amsterdam-Lelylaan or Amsterdam Zuid), since the ticket machines don't take bills or American credit cards. (The city trams/buses in Amsterdam do take bills, but this is a national train.)<br />
* note that the entirety of the outside-[https://en.wikipedia.org/wiki/Schengen_Area Schengen]-immigration part of the airport does security at the gate, per flight<br />
<br />
== AUS Austin, Texas ==<br />
The food available in the airport is actually pretty good, since most of the food concessions offer menus from local restaurants. Get to the airport early enough to have a last plate of barbecue or breakfast tacos. <br />
<br />
Another reason to get to the airport early is the "Knot Anymore" chair massages available near gates 13 and 7. Austin is awash in good massage therapists, so the ones working in the airport are far better than most airport massage services.<br />
<br />
== CDG Paris / Charles de Gaulle ==<br />
* CDG airport has multiple airport hotels on premises (on the around-the-airport CDGVal shuttle train); typically at least one of the fancy ones has good prices because it isn't hosting a conference that week, but there's also an Ibis. <br />
* CDG airport has four disconnected parts:<br />
** Terminal 1 (the cylinder with pods) (United is here)<br />
** Terminal 3 (the discount airlines)<br />
** Terminal 2A-2B-2C-2D-2E-2F (the bulk of the airport) (Air France is here)<br />
*** note that there are two satellite piers attached by train (outside immigration but not inside security) attached to Terminal 2E (the attached part of terminal 2E is called K, the satellites are called L and M)<br />
** Terminal 2G<br />
* transport<br />
** there's a train (CDGVal) connecting Terminal 1, Terminal 3 / Roissypole (where most but not all of the hotels are), and Terminal 2 (the station is between 2C/2D/2E/2F)<br />
** high speed trains stop only at the terminal 2 station (between 2C/2D/2E/2F)<br />
** RER trains (Paris's suburban rail network) stop at Terminal 2 (same station, again) and at "Terminal 1" (which is actually the Terminal 3 / Roissypole station for CDGVal)<br />
** Terminal 2G is reachable only by shuttle (I think, never done it)<br />
** If you want to take the RER to/from the airport, hoard coins in advance to pay the €9.50, since foreign cards don't work, and the machines don't take bills. <br />
** The RoissyBus is only €10.50 and runs nonstop between CDG and the Paris Opera, only a few blocks from the Mozilla Paris office. Look for signs for "RoissyBus" or "Paris by bus" within each terminal to find the bus stop.<br />
<br />
== JFK New York ==<br />
* The wifi password of the British Airways' lounge is "London" (according to Reddit). You can usually get in range of the wifi hotspot without going inside the lounge.<br />
<br />
== LHR London Heathrow ==<br />
* Terminal 5 (international) <br />
** If you need to take the train to concourse B or C, go to the far end of the platform. You'll bypass the crowds at the near end, and be closest to the escalators when you exit.<br />
** If you need to backtrack from concourses B or C to concourse A, ''don't'' take the train; you'll be routed through security again. There's a pedestrian tunnel that parallels the train, and comes out next to elevators that let out inside security in concourse A. The tunnel doors are marked "Emergency Exit", but do not have alarms, and in fact open automatically, to accommodate mobility-assistance carts. Stay to the left (remember: you're in England) to keep from being run over by them.<br />
** If you're going to the Mozilla London office, [[London#From_Heathrow_by_traincheck the directions]] and don't bother with Heathrow Express.<br />
<br />
== NCE Nice, France ==<br />
* if you have a really early flight, there are multiple decent airport hotels nearby. But do '''not''', under any circumstances, stay at the Etap.<br />
* if you want to avoid a really early flight, consider as an alternative doing an overnight layover at CDG, which has multiple airport hotels walking distance from Terminal 1 (but poorly signed). Make sure your layover is long enough, though.<br />
* if you're traveling to west of the airport (e.g., towards W3C's European offices near Antibes) and want to take public transit, it's possible to walk to the Nice - St. Augustin train station ('''not''' the main Nice - Ville train station) in about 15-20 minutes, but there's basically no signage. But definitely look at the train schedules before trying this. Buses from the bus station (gare routière) at the airport may be better.<br />
* there's a free shuttle between Terminals 1 and 2. Don't try walking between terminals.<br />
* There are bus stations at both terminals, but some bus routes stop at both terminal and some stop only at Terminal 1. You need to buy a ticket at the station before boarding.<br />
* the airport does not have water fountains behind security. But restaurants will probably be willing to fill up a water bottle for you, especially if you've bought something there.<br />
<br />
== NRT Tokyo/Narita ==<br />
* If you can do so just as easily, fly to Haneda Airport (HND) instead, which is closer to the city.<br />
* Don't even ''think'' of taking a taxi. It will take hours, and cost multiple hundreds of US dollars.<br />
* Two companies (JR and Keisei) run trains to Tokyo, and both have express and local services at different prices. Choices depend on where in Tokyo you're going. Google Maps might be helpful, or just figure it out when you get there.<br />
* Consider taking a [http://www.limousinebus.co.jp/en/ Limousine Bus] to somewhere close to your destination, and take a taxi from there.<br />
<br />
== ORD Chicago O'Hare ==<br />
* In Terminal 3, at the beginning of concourse G, there is a "Chicago Urban Garden" on the second floor, with aeroponic herbs and vegetables. This is a nice quiet place to wait if you don't have access to an airline lounge. <br />
<br />
== SFO San Francisco ==<br />
* if you're through security and looking for food, realize that some pairs of terminals are connected behind security. In particular, there are four separated behind-security zones at SFO right now: International-G/Terminal3-F/Terminal3-E, Terminal2-D/Terminal1-C, Terminal1-B, and International-A. In particular, if you're in C, you can probably find better food and better places to sit in D, and at some hours there's not much open in G, but you can head over to F.<br />
* The recently renovated terminal areas are the International Terminal (2000), Terminal 2 (gates D) (2011), and Terminal 3 gates E only (2014)<br />
* If you're taking BART to the airport, you can take the airtrain or walk to get around the airport from the airport BART station. You should definitely walk to International (G or A, which share a large central checkin hall but have separate gate areas), maybe walk to Terminal 3 (at least if you're ready to go straight to the security line), and you can walk to the other terminal if you like.<br />
<br />
== SJC San Jose CA ==<br />
<br />
== TPE Taipei Taoyuan ==<br />
* if you're coming from within Asia to Taipei, fly to Songshan Airport (TSA) instead<br />
* if you have Star Alliance gold, there are multiple EVA lounges to choose from. The main one, with all the good food, is on the same side of the open (to the floor below) space as the tropical bar one, with entrance across the hallway from it (not across the open space)<br />
<br />
== YVR Vancouver ==<br />
* As airports go this one is a pretty beautiful. If you're departing to the US from Vancouver note that you will go through US customs and immigration at YVR, so arrive 2 hours before your scheduled departure time. <br />
<br />
= Trains =<br />
<br />
* for booking long-distance trains within Europe, https://www.trainline.eu/ is often better than the national train company sites, because they tend to be clearer about both giving you the better options for ticket retrieval and explaining those options to you<br />
<br />
= Hotels =<br />
<br />
'''Quick Tips'''<br />
* Ask for upgrades. I know, this sounds trite, but it works. If you don’t know how that works, just remember, when checking in, to ask “Is there a better room available?” If they say yes, you’re set. If they say no, that’s fine. If they say “yes, for a price” then you can consider that price and make the call. We’ve gotten $2000/night rooms on a $180/night booking just by asking. This tends to work well when the hotel has a lot of open inventory (particularly effective in LAS, less effective near Moscone during a conference).<br />
* When checking in, adjust your interactions with the clerk based on whether they smile when you approach. Chit-chat with a smiling clerk, but not with an unsmiling clerk. The latter is just as much a form of establishing rapport as chit-chat, because you're not wasting the time of a transaction-oriented person. And establishing rapport can make the marginal difference in whether they decide to give you an upgrade.<br />
* Expensive hotels tend to have sensors in the minibars, but most of the rest still just have housekeeping track what’s missing each visit and bill you. If you do get the munchies, just head out to a convenience store the next day before housekeeping and buy matching replacements at the saner price. <br />
* You can avoid the minibar entirely by grabbing a granola bar or two from a Mozilla kitchen before departing. They are bound to be healthier than anything you find in the minibar late night. <br />
* Every hotel has a bucket of standard toiletry items (toothbrush, razor, &c). You should have a toiletry bag stocked and ready to go (see above) but if you find yourself missing something, just call the front desk.<br />
* Likewise, every hotel has a bucket of left-behind chargers/power cables.<br />
* Set your climate controls when you first get into the room. Forgetting until you come back after dinner ready for sleep and finding the room is hot and stale is no fun.<br />
* Some hotels won’t let the climate controls work unless your room keycard is stuck into a switch by the door. This isn’t a magstripe reader, it’s just a physical switch - use a business card or a folded up piece of paper (or your library card) and have your room the way you want it.<br />
* If the drapes that don't quite meet, and therefore let in unwanted sunlight or street light, use one or two big binder clips to keep the drapes closed.<br />
* You can usually get a later check-out time just by asking. This doesn't work indefinitely, but they can't clean every room at once, so asking for 1pm instead of 11am just means they move your room to the bottom of the list for cleaning that day.<br />
* Repack for departure before you go to sleep, except for the clothes and toiletries you'll need in the morning. That way, if you oversleep for whatever reason, you can throw on your clothes, grab those last items, and go without wasting any more time.<br />
* To avoid leaving things behind:<br />
** Bring your original packing checklist, and use it to repack.<br />
** Pull all the linens off the bed and throw all used towels into the shower, so you're sure nothing's hidden, and check every wall socket for chargers.<br />
** If you unpack into drawers, check every drawer before you leave.<br />
<br />
== Pick a hotel, get into the frequent guest program ==<br />
<br />
Same deal as airlines. At the least, it eventually adds up to free stays, but getting to status means room upgrades, easier check-in, more flexibility on check-in/check-out times, and extra points for each stay. Some hotel loyalty points can also be transferred to airline loyalty programs.<br />
<br />
It can be harder to consistently stay with the same hotel group than to consistently fly the same airline (they're sold out or not convenient, the conference hotel is elsewhere, etc.). However, it's good to join the loyalty program for any hotel you stay at, before you make your reservation. You may get a better rate or a better room. Hotel staff seem to give an extra measure of courtesy and consideration when you're in the loyalty program. (When booking by phone, I've had a "sold out" group rate suddenly become available when I gave my membership number.) If you haven't joined by the time you check in, ask the clerk to sign you up; they'll get credit for signing you up, and will be even more inclined to treat you nicely.<br />
<br />
Linked below are the programs associated with the hotels that are typically used for visiting Mozilla in Mountain View.<br />
<br />
{|<br />
|-<br />
|Holiday Inn Express<br />
|[http://www.priorityclub.com/ Priority Club]<br />
|<br />
|-<br />
|Avante/Wild Palms<br />
|[http://www.joyoflifeclub.com/ Joy of Life Club]<br />
|(Does not give points for stays that are paid through corporate billing.)<br />
|}<br />
<br />
== Choose Your Room ==<br />
<br />
It's a good practice to indicate that you have any preference on your room at all. Put this into your loyalty program profile and your travel agency profile (Egencia, for Mozilla employees), so it's transmitted with your reservation. If you have no preference, they will put you in the room for people who do not indicate a preference. You know, the one in the basement. With the leaky faucet and carpet from 1973. <br />
<br />
If you have a choice between one or two beds, choose two, even though you'll only use one for sleeping. The other one makes a great surface for spreading out your stuff. Often, hotel beds are on casters, so you can shove the extra bed against the wall, to prevent stuff falling between the bed and the wall.<br />
<br />
Generally, you'll do well to ask for a high floor and a room away from the elevator. Many hotels do renovations by floor starting from the top and working their way down. So high floors have a better chance of being recently renovated. They are also further away from street noise or the bar in the atrium. A room away from the elevator means less foot traffic and not waking up at 5am to repeated "ding!" of the elevator door opening. For motels, you want upstairs (less foot traffic) and outside (away from the courtyard with the pool).<br />
<br />
If the room is awful, don't be afraid to walk back downstairs and see if they have anything a bit more updated. If the whole hotel is awful, check your luggage at the desk and walk in a square block radius around the hotel to see if there's something less frightening. <br />
<br />
Never pick a hotel based on a picture of the lobby. Lobbies are always the first thing to get renovated.<br />
<br />
== Tipping Hotel Staff ==<br />
If you believe in tipping (which varies across cultures):<br />
* If you take a hotel shuttle from the airport, be sure to tip the shuttle driver. Don't just hand it to them and walk away; look them in the eye and express genuine appreciation for their service while you give them the tip. This is your first contact with the hotel staff, and if you make a good impression, word will spread to the other staff, and you'll get great service throughout your stay. This driver may also be the person who gets you to your outbound flight, through heavy traffic, just in the nick of time.<br />
* Similarly, leave a tip for housekeeping after the first night. This paves the way for good service when you make special requests, such as extra towels or toiletries, or to come back later because you're still in the room. Leave the money on top of a note that says at least "Thanks!" so the housekeeper knows it's for them.<br />
<br />
= Money =<br />
<br />
* Exchange: Do not change money at the airport. The rates are higher there than anywhere else. If you have a local bureau de change, use that, or order currency online for pickup at the airport. If you can find a company that does that (Travelex in the UK, at least) the rates will be much better than those posted on the wall that they charge you when you are a captive customer. The best rates are likely to be had by using an ATM. <br />
* Debit: Using an ATM card can be an easy and inexpensive way to secure some local currency. Make sure your card will work abroad before you travel. Common ATM networks that are broadly available include Pulse and Plus. Consider getting a debit card with no foreign transaction fees (Charles Schwab offers one).<br />
* Stay organized: It's helpful to keep your currency separate from your home currency, particularly if you're going to cycle through multiple currencies during your trip (usd > euro > pounds). Don't underestimate the power of a ziploc baggie if you're American and unaccustomed to coinage-heavy currencies.<br />
<br />
== Credit cards ==<br />
The US has historically had a different system (magnetic strips) for credit card security from the rest of the world (which uses the chip-and-pin system). This can cause headaches for both Americans traveling abroad, and others traveling to the US, as the systems are incompatible. Most US stores now support chip-and-signature cards, but you might run into smaller ones that don't have chip-reading equipment (e.g., a food truck using Square). <br />
<br />
* A very few US banks offer true chip-and-pin cards, including Citibank and [https://www.andrewsfcu.org/credit_cards_and_loans/credit_cards/globetrek_rewards.html Andrews Federal Credit Union]. The latter also has no annual fee and no international transaction fees. See this extensive but not exhaustive [http://thepointsguy.com/2013/05/us-credit-cards-with-smart-chips/ list of US-based chip-and-pin cards]. <br />
* You can get a pre-paid, reloadable chip-and-pin card called [http://www.cashpassport.com/1/travelex/ "Cash Passport"] from Travelex. You can buy it and reload it online or at Travelex locations in the US. You can load it in multiple currencies: GBP, EUR, CAD, AUD and JPY. The security seems a bit crappy (you can't change the PIN, and their only security question is mother's maiden name), but since it's pre-paid, you can limit your financial exposure, and reload online as needed.<br />
<br />
Another issue for travelers is transaction fees when making purchases in currencies other than your home currency; these can range from 1% up to as much as 7%. US-based credit cards that don't charge international transaction fees include CapitalOne and Andrews FCU.<br />
<br />
More and more US retailers have card readers that accept chip-based cards, so the situation is improving for visitors to the US. However, they probably don't understand the PIN system, so you will still need to sign (either on the reader, or on paper).<br />
<br />
= Preparing to be less-online than normal =<br />
<br />
If your cellphone plan doesn't have reasonable data roaming, or if you might be in areas with poor cell coverage, you should be prepared to survive without your usual data connection. This might include things like:<br />
* downloading offline maps in advance. ([http://maps.me/ maps.me] for Android and iOS lets you download offline OpenStreetMap maps by country or part-of-country.)<br />
* knowing where you're going to need to be (hotels, meeting locations) before you leave<br />
<br />
= On Foreign Soil =<br />
<br />
* Data/Voice rates<br />
** You can use Skype to call US 1-800 numbers toll free from anywhere in the world.<br />
** Before you leave your home country, add $20-40 of SkypeOut credits to your account. While Skype to Skype calls are free, SkypeOut credits will let you call any number internationally for about $.02 per minute.<br />
** International text messages are typically NOT covered under your mobile plan. For US cell plans, it's usually about $.50 per SMS. If you have a good international rate, think long and hard about when you use SMS and why. A conversation about when you landed and where to meet and what time to get there on SMS may be more than a 2 minute call that covers the same details.<br />
** [http://readwrite.com/2014/06/17/5-secrets-avoiding-hefty-international-data-roaming-charges-fees 5 secrets to avoiding hefty international data roaming fees] <br />
* Finding wifi<br />
** In airports, airlines' priority lounges often have no wifi password, and you can access their hotspots from outside the lounge. (See note above for JFK airport.)<br />
** Starbucks, McDonalds, and Burger King are sadly ubiquitous, and often have free wifi.<br />
** You can sometimes find the password for a business's wifi in the comments for that business on FourSquare.<br />
* Language barriers<br />
** Grab some business cards or stationery with your hotel's address on them before you head out. You can hand one to a cabbie whose language you do not speak, to get yourself back to home base. <br />
<br />
Still to write/update:<br />
* Language barriers<br />
** Add Line2 details...<br />
<br />
==Coping with jet lag==<br />
* Do not go to sleep. Do not nap. Stay up as long as you possibly can. Eat meals at local times and get into bed when it's dark outside. It will hurt on day one but by day three, you'll be glad you did. <br />
* If you absolutely must sleep, do a 20 minute powernap and then get up, walk around, and do not fall back to sleep. (Powernapping pro tip: drink a cup of coffee, and ''then'' take a nap; the coffee will wake you up in a short while.) <br />
* In a pinch, Benedryl (dipenhydramine) can help you reset your internal clock and it's substantially gentler on your system than the prescription sleep aids. (It's also good for nausea if you get motion sickness, and of course, allergic reactions.)<br />
* If you find yourself awake when you should be sleeping (by local time), avoid bright screens (computers, phones, e-readers), because they activate wakefulness in your brain. Try reading a paper book or magazine (radical, I know). If you must use a screen, set it to white text on a black background, to reduce the overall brightness; or get an app (such as [https://justgetflux.com/ f.lux] for Mac/iOS or [https://play.google.com/store/apps/details?id=com.urbandroid.lux Twilight] for Android) that reduces the amount of blue light emitted by your device at night.<br />
* If possible, follow the [http://www.wikihow.com/Prevent-Jet-Lag-with-a-Modified-Diet Anti-Jet Lag Diet]; this is easier to do at home than while traveling, but IME even an approximation helps. <br />
** As an abbreviated version: eat as little as possible on your day of travel, avoiding caffeine and alcohol; eat a high-protein breakfast at breakfast time in your new time zone.<br />
** Bring protein bars with you to ensure that you can get protein at the right time.<br />
<br />
= Transportation =<br />
<br />
'''Quick Tips'''<br />
* Talk to cabbies. Not only do they know their city, they are less likely to have kickbacks in place than the hotel concierge, more likely to give you good answers.<br />
* Learn the taxi rules. Las Vegas doesn’t let you hail cabs on the street (creates traffic problems). New York cabs have credit card swipes in the back seat, whereas DC cabs just started actually using their meters at all. San Francisco cabs won’t let you exit except curbside.<br />
<br />
Still to write:<br />
* public transit<br />
* hotel shuttles<br />
<br />
== Rental Cars ==<br />
<br />
=== Enterprise Rent-a-Car ===<br />
<br />
Mozilla's preferred vendor<br />
<br />
=== Hertz ===<br />
<br />
If for some reason you end up with Hertz (late evening arrivals mean Enterprise might be closed) you'll want to sign up for [[HertzBusinessAccountProgram|Hertz #1 Gold]] and use that. At most airports, you walk in, your name is on a board with a parking spot number, and the keys and contract are already in the car waiting for you. Really nice after a 5+ hour flight!<br />
<br />
= Eating =<br />
<br />
Eat like a local.<br />
<br />
Never ask the front desk at your hotel for a dinner recommendation. If possible, ask anyone else to weigh in. The bellhop, your taxi driver, the barista at Starbucks, Yelp, Chowhound, etc. The best recommendations come from people who are actually living and working in the area. (TripAdvisor tells you what people who ''don't'' live there think.) The concierge at the hotel will always orient toward broad, tourist-pacifying tastes. The food will be edible, but forgettable. They'll never tell you about the super tasty hole-in-the-wall joint three blocks away.<br />
<br />
= Staying healthy =<br />
* Wash hands frequently! <br />
* Carry and use hand-sanitizer wipes. (A bottle of hand-sanitizer gel takes up valuable room in your liquids bag.) Sanitize your hands in-flight before you eat or drink, and after washing your hands in the lavatory (on-board water, again). Also use them to wipe off [http://www.travelmath.com/feature/airline-hygiene-exposed/ tray tables, seatbelt buckles, and air vents], where germs lurk on airplanes.<br />
* Set the fan above your seat on the plane to low or medium, and position it to blow into your lap, just in front of your face. This will help knock airborne pathogens out of the air, so you'll be less likely to breathe them in. ([http://www.npr.org/blogs/goatsandsoda/2014/07/14/319194689/pathogens-on-a-plane-how-to-stay-healthy-in-flight?ft=1 (NPR) Pathogens on a plane: how to stay healthy in flight])<br />
* Keep your exercise routine as much as possible. Exercise burns calories, relieves stress, and helps reset your body clock, if you're in a different time zone.<br />
** Pick a hotel that has a fitness center. If you must use a hotel that doesn't have one (or you need specific equipment, like a stationary bike) call and ask; they may have an arrangement with a nearby gym.<br />
** If you're out of luck on the fitness center, bring an exercise DVD, and/or small lightweight equipment like a jump rope or tension bands. Or do a [http://well.blogs.nytimes.com/2013/05/09/the-scientific-7-minute-workout/ body-weight-only exercise routine].<br />
** Bring quick-drying workout clothes. Rinse them in the shower, and dry them over the shower rod, so they're ready for tomorrow.<br />
** Bring athletic shoes that double as casual street shoes, so you don't need to take up luggage space with extra shoes.<br />
** See the Quartz [http://qz.com/287800/the-complete-guide-to-staying-in-shape-on-the-road/ Complete guide to staying in shape on the road].<br />
<br />
= Redux =<br />
<br />
'''Most people travel infrequently, and aren’t very skilled at it...'''<br />
* and there are a lot of people, so despite the infrequency of their travel, the Don’t Know path is very crowded<br />
* Businesses on the Don’t Know path have no loyalty to you (since infrequent travellers have no meaningful loyalty to them) so their main goal is to extract money from you immediately, even at the cost of the relationship<br />
* People on the Don’t Know path have to deal with the same Don’t Know problems every single day, which is exhausting and saps their empathy<br />
<br />
'''BUT - If you know what you’re doing...'''<br />
* You can shortcut around the Don’t Know path everywhere. Airports, Hotels, Restaurants<br />
* The businesses you deal with will view you as a regular, and want to keep you happy<br />
* The people you deal with will view you as a breath of fresh air, and feel understood, and be grateful and human in the ways that travel never is for others.<br />
<br />
= More advice =<br />
* [http://www.jonobacon.org/2016/08/10/the-bacon-travel-survival-guide/ Travel Survival Guide] by Jono Bacon<br />
* [http://christianheilmann.com/2014/02/16/how-i-save-money-when-traveling-for-work-san-franciscovalleyus/ How I save money when traveling for work] by Christian Heilmann<br />
<br />
These podcasts have some excellent advice on business travel:<br />
* [http://www.manager-tools.com/2009/07/airline-travel-basics-1-part-1 Airline Travel Basics, part 1]<br />
* [http://www.manager-tools.com/2009/08/airline-travel-basics-1-part-2 Airline Travel Basics, part 2]<br />
* [http://www.manager-tools.com/2008/08/business-travel-packing Business Travel Packing]<br />
* [http://www.manager-tools.com/2009/07/travel-airline-seats Travel - Airline Seats]<br />
<br />
The what and how of packing only a carry-on: [http://www.onebag.com/ Onebag.com]</div>Dbaronhttps://wiki.mozilla.org/index.php?title=All_Hands/Orlando2018&diff=1204467All Hands/Orlando20182018-11-28T05:05:27Z<p>Dbaron: /* Dates, Location and Weather */ add weather forecast links</p>
<hr />
<div>'''What is it?''' -- Multiple team meetings, happening in the same city, at the same time + some opportunity to get together as one big group as well as with other teams as it makes sense. Then, on the last day, we have a fun social event for all, Mozilla-style! <br />
<br />
'''''The information on this wiki primarily applies to Full time and contractor staff. If you are a volunteer contributor or intern, please inquire to your coordinator. '''''<br />
<br />
=='''Dates, Location and Weather'''==<br />
Monday, December 3 - Friday, December 7, 2018 (travel days are Monday the 3rd & Saturday the 8th) in Orlando, FL.<br />
<br />
We are staying at [http://swandolphin.com/ Swan & Dolphin]. <br />
<br />
''*For those countries where rest time is required on weekends (vs. work travel), Mozilla will cover a return on the next available work day, if you choose. This needs to pre-approved and pre-arranged.''<br />
<br />
* National Weather Service forecast: [https://forecast.weather.gov/MapClick.php?smap=1&lat=28.367&lon=-81.560&unit=1&mp=1 in °C] / [https://forecast.weather.gov/MapClick.php?smap=1&lat=28.367&lon=-81.560&mp=1 in °F]<br />
* weather.com Forecast: [https://weather.com/en-GB/weather/tenday/l/USFL0372:1:US in °C] [https://weather.com/weather/tenday/l/USFL0372:1:US in °F]<br />
<br />
=='''Registration'''==<br />
This is an invite-only event. All full time and Upwork employees are expected to attend this all company event. Contractors, Vendors and seasonal employees are included on a case by case evaluation based upon team needs. If you have not received information about the All Hands, please contact your manager. <br />
<br />
Advance registration is required. Attendees will need to wear their event badge at all times, including to evening events. We will have security at our events who will be ensuring everyone in our space should be there. <br />
<br />
=====New Hires=====<br />
We have a process to identify new hires each Monday and will invite them to book travel. No action necessary from managers other than to let them know about the event. Please work closely with your recruiting manager as they are aware of all deadlines.<br />
<br />
All new hires must have a start date of November 16 and able to register/book travel by November 1.<br />
<br />
==== Volunteer contributor participation ====<br />
The process for this is [[All Hands/Orlando2018/Contributor_nominations|outlined on this page]]. <br />
<br />
All nominations will be done by employees, with a coordinator from each of the Firefox, Emerging Technologies, Marketing, Open Innovation and Operations parts of the organization. There will be no open call for nominations from volunteer Mozillians.<br />
<br />
'''Please note: The information on this wiki primarily applies to Full time and contractor staff. If you have questions about how specifics apply to you, please email groter@mozilla.com and bmark@mozilla.com.'''<br />
<br />
=='''[https://docs.google.com/spreadsheets/d/1J0p9569m5uTT5h1otoXsSTUlq2Q3xGbY8RKExDBG9U0/edit?usp=sharing Week at a Glance]'''==<br />
<br />
====Monday====<br />
*Monday is primarily your travel day. You'll be able to pick up your registration stuff between 1:00 pm and 10:00 pm, as well as attend the <br />
*Welcome Reception from 6:00 pm - 9:00 pm.<br />
<br />
====Tuesday====<br />
*Centrally located breakfast (incl guests) & lunch (no guests)<br />
*Evening out to enjoy Orlando (or any part of Disney World should you [https://wiki.mozilla.org/All_Hands/Orlando2018#Disney_Park_Passes purchase passes]).<br />
<br />
====Wednesday====<br />
*Centrally located breakfast (incl guests) & lunch (no guests)<br />
*Demos - we'll have demos during lunch. List of who will be there soon!<br />
*All company evening event at [https://www.kennedyspacecenter.com/ Kennedy Space Center] (incl guests)<br />
<br />
====Thursday====<br />
*Centrally located breakfast (incl guests) & lunch (no guests)<br />
*Evening out to enjoy Orlando (or any part of Disney World should you [https://wiki.mozilla.org/All_Hands/Orlando2018#Disney_Park_Passes purchase passes]).<br />
<br />
====Friday====<br />
*Centrally located breakfast (incl guests) & lunch (no guests)<br />
*Closing event at [https://www.universalorlando.com/web/en/us/universal-orlando-resort/the-wizarding-world-of-harry-potter/hub/index.html The Wizarding World of Harry Potter] at Universal Studios from 8:30 pm - 12:00 am. We'll have transportation to/from the venue and hotel. ''Note: there are camera restrictions for this park. You are limited to one DSLR. Tripods and flash/light attachments are not permitted.''<br />
<br />
====Saturday====<br />
*Centrally located breakfast (incl guests)<br />
*Departure day only. No scheduled activities.<br />
<br />
==='''Mozlando All Hands Event Calendar'''===<br />
Coming soon: https://mozlandodecember2018.sched.com/<br />
<br />
Don't see stuff for your org yet? Don't fret! The schedule changes regularly as meetings and events are confirmed. Keep checking back. <br />
<br />
=====Create an account=====<br />
We don’t recommend using the same email & password as anything like bank accounts, etc. We care about your security!<br />
<br />
If you already have a Sched account from past All Hands, it still works, just log in with that.<br />
<br />
=====Add items to your calendar=====<br />
Select the circle on any agenda item to add it to your calendar (you do need to have an account & be logged in to do this)<br />
<br />
You can also share a link to meetings to invite others. Go into the meeting and copy the short link. You can email that out to anyone and they can quickly add it to their calendar.<br />
<br />
=====Subscribe to GCal Calendar Link=====<br />
Click on the mobile phone on the right hand side of the screen. All the calendar options are available here. <br />
You have the option to choose ALL meetings or YOUR meetings. Unless you have 400 items on your calendar, just select your calendar. It will add anything on your calendar to your GCal (also an option for Outlook and iCal). It syncs once per day.<br />
<br />
The "only syncs once per day" only applies to Google Calendar. With almost all other clients (like Apple Calendar, Outlook, or the calendar app on your phone) you can set the refresh interval, and Sched's instructions recommend 1 hour.<br />
<br />
Warning: This is a link that utilizes your username for the .ics file.<br />
<br />
=====From Mobile=====<br />
Visit from any mobile device - bookmark or add to your homescreen for quick access. There is a bonus icon you get by doing this. It caches the last time you opened the page offline and refreshes anytime you are connected.<br />
<br />
=====Cool things=====<br />
'''Filters'''<br />
<br />
We have filtering functionality. You can filter by:<br />
Departments (ex: Product Org)<br />
AND<br />
Functional Teams (ex: Firefox Addons)<br />
<br />
*Search by Room, Speaker/Leader<br />
<br />
'''Further Filtering'''<br />
*Audience - who should be there (ex: Team only or Invite)<br />
*Homerooms (you can quickly see what is happening in homerooms, by team) - why do you care? If you have a cross team meeting in their room, its a quick way to search<br />
*Views - Lots of view options. It defaults to the simple view, but there are quite a few options.<br />
<br />
=='''Food, Drink & Events'''==<br />
Breakfast, lunch & snacks will be provided and paid for centrally for attendees. Breakfast is provided Tuesday - Saturday and lunch is provided Tuesday - Friday. [https://docs.google.com/document/d/1OJQsBif3N-z5LOQDHCl2TX9d0iRXOm6Y0abvU-OsQPk/edit#heading=h.tga46tohg988 Menus are here]. <br />
<br />
Allergies/preferences: We will ensure that all food/environmental allergies are taken into consideration and will always have gluten-free and vegan options. If you have severe allergies that we need to know about; you can indicate in registration.<br />
<br />
===Hosted Evening Events===<br />
We have evening events on the Monday, Wednesday and Friday nights.<br />
<br />
====Monday Night Welcome Reception====<br />
6 pm - 9 pm, Palm Tree Causeway + Lake Terrace (area between 2 hotels)<br />
<br />
====Wednesday Night at Kennedy Space Center====<br />
Event at KSC - 7:30 pm - 10:30 pm<br />
'''NOTE: The only way to access the event is via our shuttles.'''<br />
A wristband + name badge is required to access transportation and the event. <br />
<br />
Getting to the event: Shuttles depart from the hotel. We'll gather near registration (lobby level, near convention entrance) and will start a line down the hall. There will be people and signs directing you. Shuttles will start loading at 6:15 pm and depart starting 6:30 pm. The last shuttle will load and leave at 6:45 pm, don't miss it. It is about an hour drive to KSC.<br />
<br />
Shuttles will return shuttles starting at 9:00 pm - they will depart from a different location than where you were dropped off, so follow signs and staff. The last departure returning will leave at 10:40 pm.<br />
<br />
Costumes are not allowed at KSC. <br />
Gift shops (2) will be open during our event.<br />
<br />
====Friday Night at Wizarding World of Harry Potter (at Universal)====<br />
'''Pre-Event Gathering''' - 6:45 pm - 7:45 pm - Dolphin Hotel, Atlantic Hall<br />
'''Event at Universal''' - 8:30 pm - 11:30 pm<br />
<br />
Universal has two sides - Universal Studios and Islands of Adventure. [https://www.universalorlando.com/web/en/us/universal-orlando-resort/the-wizarding-world-of-harry-potter/hub/index.html Wizarding World of Harry Potter] has two sides, Hogsmeade on the Islands of Adventure Side and London/Diagon Alley on the Studios side. They are connected by the Hogwarts Express. So we'll have full run of both Harry Potter theme parks for the full time + food will be available on both sides. The parks close before our event and the only way to access them is via our shuttle (because we are going in a back gate and not the main entrance). <br />
<br />
For more on the background of Harry Potter, [https://en.wikipedia.org/wiki/Harry_Potter go here]. <br />
<br />
=====Getting to the event=====<br />
Shuttles depart from the hotel. Lines will start in Atlantic Hall (where the pre-reception is). Shuttles will start loading at 7:30 pm and depart 7:45 pm (and go until everyone gets there). '''NOTE: The only way to access the event is via our shuttles.''' Shuttles will return shuttles starting at 9:30 pm - they will depart from a different location than where you were dropped off, so follow signs and staff. The last departure returning will leave at 11:40 pm.<br />
<br />
=====What you need=====<br />
<br />
Your Mozlando name badge, a wristband (time/date to pick up TBA) and Identification (you may be carded). <br />
<br />
=====What to wear=====<br />
<br />
Come as [https://en.wikipedia.org/wiki/Magician_(fantasy) a wizard], [https://en.wikipedia.org/wiki/Muggle a muggle] or whatever makes you the happiest.<br />
<br />
What not to wear: Masks (or anything that covers your face), fake weapons (wands okay).<br />
<br />
====Tuesday & Thursday Night Dinners====<br />
You'll be on your own for Tuesday & Thursday and will have a similar expense policy from San Francisco ($60/night - $120 total to include food, beverage, transportation, exchange fees, etc). We will not be providing [https://wiki.mozilla.org/All_Hands/Orlando2018#Disney_Park_Passes park passes] or Disney gift cards.<br />
<br />
Here is how this will work:<br />
<br />
For both of these evenings, once your meetings have concluded, you and your team, friends, new acquaintances, are free to explore and to find somewhere great to eat that suits you. Each of you can expense a total of $120 over the two days (or $60/night).<br />
<br />
This amount includes:<br />
*Meal cost, including tax & gratuity<br />
*Any beverages<br />
*Transportation to/from the restaurant<br />
*Conversion fees (for credit cards) or cash withdrawal fees<br />
<br />
Anything over the $120 for the two evenings will be your own expense. The fine print:<br />
*If your team is hosting an evening event 1 of the nights and the payment is coordinated (meaning, you don’t have to open your wallet and pay), you can expense up to $60 for the other night.<br />
*You will be asked (later) to submit an Mozlando only expense report. You can submit ONE report for Orlando only and must be submitted no later than December 31, 2018.<br />
*No expenses over $60 per night will be [https://docs.google.com/document/d/1XUD5KYotSr5SNi0q4ldgGG3bzBu-G3q4l5i-JiPE5ko/edit approved].<br />
<br />
Volunteer Contributors will have a separate process that will be communicated directly.<br />
<br />
=====Groups, Restaurants & Reservations=====<br />
*Group dinners - The only option for group dinners will be Tuesday and Thursday evenings in Orlando. All large (eight or more people) reservations must go through Lisa Carlson (email lcarlson@mozilla.com) and dinners must stay within the per diem per night ($60pp including, food, beverage, tax, gratuity and transportation), and employees attending must not also expense their per diem for that night.<br />
<br />
Teams (or individuals) can use free Disney transportation included in our hotel package to Disney Springs to access restaurants there or eat at any of the restaurants around the hotel and Disney Boardwalk (within walking distance). If teams decide to eat dinner at a non-theme park restaurant in Orlando, travel to the city must be included as part of the $60pp per diem budget allocation (as opposed to an additional allowable expense).<br />
<br />
In no case should employees expense or use MoCo corporate cards to cover purchases of alcohol outside of team dinners or the $60pp individual per diem.<br />
<br />
*All restaurants in Orlando recommend advance reservations. <br />
The hotel has several onsite [https://www.swandolphin.com/feedback/dining.html restaurants]. <br />
<br />
*[https://disneyworld.disney.go.com/dining/ DisneyWorld] has a searchable database of all of their restaurants - by park (ticketed or not) + cuisine, dining type, price range and rating. <br />
<br />
*[https://www.timeout.com/orlando/restaurants/best-restaurants-in-orlando 26 of the best restaurants in Orlando] because Orlando is about more than theme parks and chain eateries—as proven by these overall best local restaurants.<br />
<br />
=====Disney Park Passes=====<br />
We will not be providing Disney Park Passes for evenings. Purchase discounted passes [https://www.mydisneygroup.com/mozilla here] and for more information, see [https://wiki.mozilla.org/All_Hands/Orlando2018#Discounted_Disney_Park_Passes here].<br />
<br />
=='''Safety & Security'''==<br />
=====Alcohol at Events=====<br />
To better support and sustain an environment (and workplace culture) where people feel safe and included, we have made a set of changes regarding alcohol at our events. In all cases, our approach aligns with our [https://www.mozilla.org/en-US/about/governance/policies/participation/ Community Participation Guidelines] (“CPG”).<br />
*All participants are '''required to read and acknowledge our new Community Participation Guidelines as a condition of participation'''.<br />
*We will '''limit bar-servings to beer and wine''' and ensure an equal number and quality (i.e. not just Coke) of non-alcoholic drink options are available and displayed.<br />
*Team dinners should be '''thoughtful about the potential exclusionary nature of alcohol when planning'''.<br />
*Clearly outlined, communicated (to event teams, HR and managers) and understood '''escalation process''' for behavior that might be deemed counter to the spirit of our CPG.<br />
<br />
=====Device Security=====<br />
If you are traveling to the Mozlando All Hands with a device that has Mozilla data (laptop, personal cell phone/tablet with @mozilla gmail, etc) on it and your device has been retained for further inspection by border agents, or if your device has been inspected outside your immediate presence - and you believe your credentials have been compromised - you must notify the Enterprise Information Security team as soon as possible at infosec@mozilla.com or by calling Mozilla End User Services at +1 650-963-8811. (This number will be staffed 24x7)<br />
<br />
We will work with you to reset your credentials and help you get your device back to a known good state either by getting you a new one (if it’s been taken), or by resetting it back to a verifiable Mozilla-approved installation.<br />
<br />
=====Physical Security=====<br />
Badges are required to access all meeting spaces and evening events. <br />
<br />
=='''Hotel'''==<br />
Hotels are reserved during registration. Mozilla will pay for your hotel room with a check in date of Monday, December 3 and a check-out of Saturday, December 8. A link to self-book any pre/post stays at your hotel will be available, should that be part of your plan. Please do not book your hotel through Egencia. <br />
<br />
====Payment on Check-in====<br />
Everyone will be required to present a form of payment on check-in for incidentals. This is a US hotel standard and we aren't able to waive it (we tried). Upon check-in, the hotel will place a $100 pre-authorization hold on your credit card for any incidentals you may incur during your stay. Upon departure, the hold on your credit card will be removed.<br />
<br />
We recommend providing a credit card. You can provide a debit card, but they do put a hold of funds on your card and has been problematic for some international travelers in the past. If you are not able to provide a credit or debit card, email mozilla@shworldwide.com and we'll work with the hotel on accommodating.<br />
<br />
====Early Check-in or Late Check Out====<br />
Check in begins at 4:00pm. If you arrive before this time, you may preregister at the Front Desk. Should your room not be available, the Bellstand can assist you in storing your luggage while you begin to enjoy the amenities of the Resort. For Guests in need of a place to freshen up, the health studios offer shower and locker facilities. '''Please note that the hotel is unable to guarantee early check-in.''' <br />
<br />
On the day of your departure you can continue to enjoy our world class amenities. Checkout time is at 11:00am. Should you require storage for your luggage, our Bellstand will be more than happy to assistance. For Guests in need of a place to freshen up, the health studios offer shower and locker facilities. To request a departure time later than 11am, please contact our Guest Services department at 0 on your in room telephone the day before your departure. '''Please note that the hotel is unable to guarantee late check-out in advance.'''<br />
<br />
====Early Departure====<br />
Early departure is available for a fee. The fee is equal to one night's room rate plus applicable taxes. Please inform the front desk of changes to your departure information by midnight on day of arrival and notify us at mozilla@shworldwide.com. If you have booked your stay through an outside vendor (for pre/post), please consult the company with their cancellation policies as they may differ from the resort. <br />
<br />
====Pre/post====<br />
Links to self-book any pre/post stays - pre (Nov 30, Dec 1-2) & post nights (Dec 8-10) - were emailed in August, or as part of your invitation to book travel. If you did not receive the links, or lost the email with them, email bmark@mozilla.com<br />
<br />
=='''Travel'''==<br />
The Mozlando 2018 Egencia portal opened in late August and booking instructions were be emailed to anyone approved to attend. The deadline to book travel was September 14. New hires will have individual deadlines based upon hire/start date. <br />
<br />
Specific instructions were emailed to you about how to book, as we have a new process for anyone based outside the US, Canada & Central/South America. You will '''NOT''' be booking your All Hands travel in the new country based site. <br />
<br />
Should you need to reach someone for special circumstances or changes that can't be done online:<br />
*Call: +1 (877) 264-1622 or +1 (417) 521-0273; Hours of operations are Monday – Friday (except holidays) 5:00 AM– 5:30 PM PST or 8:00 AM – 8:30 PM EST (2 pm - 11 pm UTC). If you call outside these hours, you will get an after hours agent, who may not be as helpful.<br />
*Email: groupagents@customercare.egencia.com. The email is monitored Monday - Friday.<br />
<br />
'''Important Details:'''<br />
Everyone should plan to arrive in Orlando on Monday, December 3rd and leave on Saturday, December 8th. Anyone who plans to arrive ahead of that or to stay longer, regardless of the reason, must follow the "arriving early/departing late guidelines." These guidelines also apply if you want to fly in or out of airports other than your home airport and Orlando (anything custom). A few notes:<br />
*If you are a vendor (paid by a company other than Mozilla or Upwork), contractor, or seasonal staff, your manager must confirm your participation before you will be able to book travel. You will receive a separate email shortly if you have already been approved.<br />
*Volunteers will be handled separate from this process.<br />
*We work closely with Recruiting to ensure new hires are invited after their start date. No need to let us know about these.<br />
*If you would like to invite someone who is a business partner, facilitator or some other category that isn't an employee or volunteer (not a personal guestfamily), email bmark@mozilla.com.<br />
*Change fees will be covered by Mozilla for business reasons only.<br />
<br />
====Arriving Early/Departing Late Guidelines====<br />
<br />
Our standard travel guidelines apply (pre-populated in Egencia) when booking with a few additional budget constraints. Anything booked outside of them will require approval. Most people will arrive on Monday, December 3 and leave on Saturday, December 8. Here are some exceptions: <br />
* If you live in a country where work travel is prohibited on weekends, you may travel on Friday, November 30 and Monday, December 10, if you’d prefer (not required). For hotel, you will book and pay on your own, and expense the manager approved amount (which is coded to your cost center).<br />
* If you live in a country where work travel is prohibited on Sunday, you may travel on Saturday, December 1 and Saturday, December 8, if you’d prefer (not required). You will get your Monday, December 3 and 10 off. For hotel, you will book and pay on your own, and expense the manager approved amount (which is coded to your cost center).<br />
* If you plan to spend some extra personal time in Orlando or nearby (choosing to arrive before Monday, December 3 or depart after Saturday, December 8), you'll need to create an itinerary in Egencia for standard dates/locations within the Mozlando 2018 Portal and compare to the custom dates/locations you'd like. Please share the difference via email to bmark@mozilla.com or through the approval comment box when you submit the flight. '''You can sway up to +$100 over and Mozilla will cover it. Otherwise you'll need to come with an alternate itinerary that fits within the pricing (like a round trip in and out of MCO w/ longer dates, and you personally book & cover the rest). We do not have the ability for employees to reimburse Mozilla for any overage.''' This scenario also applies for routing through different airports to/from Orlando than your home airport (ex. a layover in Chicago for a few days, or flying out of MIA instead of MCO). In all cases, flights in and out of Orlando should be booked via Egencia. <br />
* If you are attending the Sunday/Monday CI event (by invite), you can arrive on Sunday, December 2.<br />
* If you would like to arrive early to recover from jetlag, you will need manager approval for any additional costs associated with the extension. There is '''no unilateral''' "All Hands" approval based upon timezone to arrive early. For hotel, you will book and pay on your own, and expense the manager approved amount (which is coded to your cost center). This policy does not apply to volunteer contributors, any jetlag recovery costs must be self funded.<br />
<br />
====Booking Family Travel====<br />
Whether your family will accompany you on your flight or join us later; and you have two options: direct with the airline (recommended) or through Egencia.<br />
<br />
'''Direct (recommended):''' <br />
<br />
First, figure out which flights you want to be on as an employee in Egencia. Hold them in Egencia. Find the flights you want for your family on the airline site and book them. Go back to Egencia and book your flights. Once you have both sets of confirmation numbers, call the airline and ask them to LINK your two reservations. This shows that you are traveling together and shouldn't be moved. When you call, you can also ask the airline agent to assign seats together. By booking your family direct on the airline, it gives them "priority" with the airline over people who book via a third party (expedia, booking.com, kayak, etc). These aren't guarantees, but they do help.<br />
<br />
'''Via Egencia:'''<br />
<br />
We do not recommend booking family through Egencia. If you'd like details about how to do it, please email bmark@mozilla.com<br />
<br />
'''Notes:''' <br />
<br />
* If your family is arriving on a different flights than you but would like to take advantage of the airport shuttles on Sunday/Monday and/or Saturday, please email their itinerary to mozilla@shworldwide.com.<br />
* No matter how you book, give yourself a lot of time at MCO on departure. This airport can chaotic (almost everyone leaving is a family with young kids) so not being in a hurry helps stress-levels.<br />
* We are unable to accommodate volunteer contributor families/guests.<br />
<br />
====Not Flying====<br />
Self-parking overnight is $23 plus tax per day. Valet parking overnight is $33 plus tax per day. Mozilla will not reimburse for valet parking. <br />
<br />
====Travel Insurance====<br />
Mozilla provides emergency medical accident and illness cover for all global MoCo & MoFo employees/interns and their dependents. You can view more information on [https://mana.mozilla.org/wiki/display/PR/Travel+Insurance+-+Business Mana]. This coverage begins at the time the you leave home to start your business trip. It also has a provision for a 14 day extension for leisure travel outside of the business travel. If you have additional questions, please email benefits@mozilla.com. <br />
<br />
Mozilla does not cover travel insurance for elancers, upworkers, contractors, vendors, or volunteers/community members.<br />
<br />
=====''Air Travel Fine Print''=====<br />
Change fees will be covered by Mozilla for business reasons only. If you need a change and have manager approval, email bmark@mozilla.com prior to requesting the change with Egencia. Once you have approval, call Egencia to make the change at +1 (702) 939-2530 or +1-877-264-1622 (note this will not be possible without prior approval so be sure to get that by way of an email from your manager to Brianna Mark). If you are changing for personal reasons, the change in airfare, change fee and Egencia fee is your responsibility.<br />
<br />
Mozilla will '''not''' reimburse for Business/First class upgrades or tickets. ''Mozilla Frequent Flyer perks do not apply for All Hands''. <br />
<br />
Any submitted expenses needs to have an itinerary attached to ensure it is employee expenses only and within policy.<br />
<br />
=='''Ground Transportation'''==<br />
====Airport Shuttle====<br />
'''All Mozillians and guests who have flights arriving between 15:00 and 22:00 on Sunday, December 2 and anytime 00:00 - 23:59 on Monday, December 3rd in Orlando International Airport (MCO) and out on Saturday, December 8th, will be transferred to/from the hotel.''' If you arrive into another airport; or on a different date - ground transportation is on your own. If your family is arriving on different flights than you but would like to take advantage of the shuttles on Monday & Saturday, email their itinerary to mozilla@shworldwide.com.<br />
<br />
=====Arrivals to Orlando Int’l Airport (MCO)=====<br />
Everyone will be greeted in Baggage Claim (regardless if you check a bag). At the bottom of the escalator in the baggage claim level, look for a greeter holding up a Mozilla/Mozlando sign. Please identify yourself to the greeter and they will direct you to the shuttles. Transfer time from the airport to the hotel is approximately 20 minutes.<br />
<br />
''For Domestic Arrivals''<br />
<br />
Upon arrival, proceed to the baggage claim area of your respective airline. There are two separate baggage claims – A or B. Please listen for the announcements from your airline flight attendants or while you are on the shuttle from the gates to the main terminal, for your baggage claim. Once you exit past Security, look to the left and right to see the large A or B to find your respective baggage claim.<br />
<br />
''For International Arrivals''<br />
<br />
Upon arrival, you will proceed thru Customs. Some International flights allow you to take your luggage directly from Customs to the main terminal and some require you to put it on the luggage carousel and re-collect it in the main baggage claim. Regardless if you collect your luggage at Customs or not, you have to take the shuttle to the main terminal. Once there, please proceed down the escalator to the Baggage Claim, Level 2.<br />
(Do not go directly to Level 1.)<br />
<br />
=====Departures from Dolphin Hotel to Orlando Int’l Airport (MCO)=====<br />
Everyone departing on Saturday, December 8th, will receive shuttle transportation to MCO. You will be met by transportation staff in the hotel lobbies and assisted onto the shuttles. More details about departures will be sent via email. <br />
<br />
Regardless of international or domeestic, plan to depart the hotel 3 hours prior to your flight time.<br />
<br />
=====Bringing family?=====<br />
If you are bringing family and are all arriving on Monday, December 3rd and departing Saturday, December 8th, you may all use our company-arranged transportation provided you request it ahead of time (for your guests). You will do this during registration.<br />
<br />
=====Arriving early and/or leaving late (w/ or w/out family)?=====<br />
If you arrive other than December 2 (15:00 - 22:00) or December 3rd (00:00 - 23:59) or depart other than December 8th (00:00 - 23:59), with or without guests, you will have to cover and arrange your own ground transportation, to and from MCO, including rental cars and parking. <br />
<br />
'''Recommended Airport Shuttle:'''<br />
Mears Transportation http://www.mearstransportation.com/global/orlando/<br />
Loading is on Level One at the airport, clearly marked, and the shuttle makes 1-3 stops at hotels in the same proximity. <br />
<br />
Additional help is here: <br />
*Transportation Information (airport and parks) http://swananddolphin.com/aboutus/transportation.html<br />
*Transportation FAQ: http://swananddolphin.com/feedback/transportation.html<br />
*Transportation booking (via Swan & Dolphin): https://swandolphinconcierge.com/<br />
<br />
=='''Accessibility'''==<br />
====Evenings====<br />
The Monday Night reception is at the Swan & Dolphin hotel, accessible by elevators and escalators. <br />
<br />
Details on accessibility at Kennedy Space Center (Wednesday Night) can be found here: https://www.kennedyspacecenter.com/info/accessibility. Rentals and equipment are not be available during our event. All parts of the venue are accessible by elevator or ramp. <br />
<br />
Details on accessibility at Universal Studios (Friday Night) can be found here: https://www.universalorlando.com/web/en/us/plan-your-visit/accessibility-information/index.html, as well as additional information for motorized scooters here: https://www.universalorlando.com/webdata/k2/en/us/files/Documents/universal-orlando-riders-guide.pdf. Hogwarts Express is wheelchair and scooter accessible.<br />
<br />
====Listen Systems====<br />
We will have Listen Systems available for the Plenary on Tuesday. Visit the AV booth at the back of the room to pick one up. <br />
<br />
=='''Immigration'''==<br />
'''Any''' questions on immigration should be sent to immigration@mozilla.com.<br />
<br />
If you are from a country that requires a B-1/B-2 business visitor visa to enter the US, please plan for it early as government processing times constantly change.<br />
<br />
Please visit the following website to learn more about the visa application process and timing for your country: http://travel.state.gov/content/visas/english/visit/visitor.html#overview. Current estimated processing times at the US Embassies and Consulates abroad can be found at: https://travel.state.gov/content/visas/en/general/wait-times.html/<br />
<br />
Some travelers may be eligible to travel to the United States without first applying for a B-1/B-2 visa, if they are eligible for the Visa Waiver Program (VWP or "ESTA"). You are eligible to apply for admission under the Visa Waiver Program (VWP) if you:<br />
<br />
*Intend to enter the United States for 90 days or less for business, pleasure or transit<br />
*Have a valid passport lawfully issued to you by a Visa Waiver Program country: http://www.esta.us/visa_waiver_countries.html<br />
*Have authorization to travel via the Electronic System for Travel Authorization: https://esta.cbp.dhs.gov/<br />
*Arrive via a Visa Waiver Program signatory carrier (all commercial airlines meet this requirement)<br />
*Have a return or onward ticket<br />
*Travel may not terminate in contiguous territory or adjacent islands unless the traveler is a resident of one of those areas<br />
<br />
=====Employee Travel FAQ=====<br />
This [https://mana.mozilla.org/wiki/display/PR/Travel+FAQ FAQ] addresses questions about how to handle security concerns and electronic devices at the border and how to engage with US Customs & Border Protection (CBP). While it specifically focuses on concerns related to travel to the United States, much of this guidance is applicable to travel elsewhere. Mana access required.<br />
<br />
=====Pocket Letter=====<br />
A pocket letter is recommended to keep on hand for those who are entering the United States. It should accompany you whether or not you are required to have a visa to enter. '''You may request a copy of that letter when you register.''' Please contact immigration@mozilla.com if you require a specific letter for your visa application or if you have any questions regarding your citizenship, visa capabilities or travel related questions.<br />
<br />
=====ESTA Point of Contact=====<br />
In the ESTA application you need to give a "U.S. Point of Contact Information". <br />
<br />
Please list Casey McGill as your US Point of Contact.<br />
Address: 331 East Evelyn Avenue, Mountain View, CA 94041 Phone: 918.812.0971<br />
<br />
=='''Mozlando 2018 All Hands Expense Policy'''==<br />
1. All "All Hands" Expenses must be submitted on 1 (and only 1) Expense report (e.g. Mozlando All Hands Expense Report). Each expense must be tagged with "Orlando 2018"<br />
<br />
2. It must contain only those expenses relative to the All Hands Event in Orlando.<br />
<br />
3. If your submitted expense report for All Hands is submitted outside these guidelines, it will be rejected and you will be asked to re-submit with only All Hands Expenses<br />
<br />
4. The deadline to submit the Orlando All Hands Expense Report is '''December 31, 2018'''.<br />
<br />
5. Expenses related to team events, parking, room service, mini-bar charges, and food/drink costs above the vouched amounts, will not be approved. <br />
<br />
'''The intention of our all hands are to centrally organize a structure that includes:'''<br />
*Meals (two/day + snacks)<br />
*Transportation<br />
*Accommodations<br />
*Some number of social events<br />
<br />
Expenses submitted can not exceed the approved amounts. Any social events that are not part of our central plan will generally be self-organized and funded by participants. <br />
<br />
=====Cell phone reimbursement policy=====<br />
Cell phone reimbursement must be approved by your manager prior to submitting the expense. Teams will decide for their staff what is appropriate to expense. <br />
<br />
=====Internet reimbursement policy=====<br />
Internet will be provided in all guestrooms and meeting space in all hotels. If you opt to upgrade/add service, those costs are not reimbursable, unless previously approved by your manager and are for business reasons. <br />
<br />
If you have questions about any of this, please reach out to bmark@mozilla.com<br />
<br />
=='''Families/Guests in Orlando'''==<br />
Of course our focus, for the majority of the week, will be on Mozilla. Everyone is expected to be present and engaged each day, during work hours (as your schedule dictates). Please do what you can to make sure your loved ones understand the kind of commitment you’ve made.<br />
<br />
Please note that what are able to do for families varies by each location. <br />
<br />
Please note: we are unable to accommodate volunteer contributor families/guests. <br />
<br />
====Quick summary logistics====<br />
<br />
=====Air Travel=====<br />
<br />
Employees do need to book via Egencia regardless of how families are booked. See Air Travel above for specifics and recommendations. <br />
<br />
=====Hotel=====<br />
<br />
They are welcome to stay with you, however, any additional room expenses will be yours to cover. All room rates are based upon single occupancy and costs to add guests vary by hotel. Breakfast is not included in any of the guest room rates. <br />
<br />
=====Breakfast=====<br />
<br />
Family members who are registered for the event and registered with the hotel are invited to join us for breakfast each morning. Breakfast will be provided on Tuesday, December 4th - Saturday, December 8th.<br />
<br />
=====Lunch & Dinner=====<br />
<br />
Family will be on their own for lunch daily and dinner on Tuesday & Thursday. <br />
<br />
=====Monday, Wednesday & Friday Night Events=====<br />
<br />
Family members who are registered for the event and registered with the hotel, are invited to join us for our three evening events.<br />
<br />
=====Family Friendly Activities=====<br />
<br />
The [https://www.swandolphin.com/activities/index.html hotel] offers several options and [https://www.swandolphin.com/kids/index.html child specific] options. <br />
<br />
=====Daytime Childcare Services=====<br />
We have limited availability for childcare in Orlando Tuesday Dec 4 - Friday Dec 7 from 8:30 am - 5:00 pm. It is $10 an hour per child. Registration deadline is Nov 26, but additional space may be available depending on staffing. Additional information, resources and contact here: https://www.jotform.com/KiddieCorp/mozillawinterkids<br />
<br />
=====Evening Childcare Services=====<br />
<br />
[https://www.swandolphin.com/kids/campdolphin.html Camp Dolphin] is available nightly from 5:00 pm - 12:00 am. Reservations are required for Camp Dolphin's evening program. The cost is $12 per hour, per child. A kids meal from Picabu can be included for an additional $10. Here is the [https://www.swandolphin.com/feedback/child.html FAQ].<br />
<br />
===Discounted Disney Park Passes===<br />
https://www.mydisneygroup.com/mozilla<br />
<br />
This site will EXPIRE for Advance Purchase Sales on December 2, 2018.<br />
<br />
These "Meeting and Convention" tickets offer advance purchase savings of 10% on our Full-Multi-Day (2 days or longer) Tickets and include one (1) complimentary +1 FUN visit to an additional Disney Experience at any one (1) of the following (additional details are listed on the website):<br />
*Disney’s Typhoon Lagoon Water Park<br />
*Disney’s Winter Summerland or Disney’s Fantasia Gardens Miniature Golf Courses (before 4 p.m.)<br />
*Greens Fees for one round of golf at Disney’s Oak Trail Golf Course, our 9-hole walking course <br />
<br />
The site also contains our partial-day tickets, which are discounted off of our full 1-Day tickets. "Meeting and Convention" Tickets purchased here will be valid from November 27 - December 14, 2018. <br />
<br />
Please note, the ticket prices on the ticket store reflect any applicable discounts and include tax. These tickets are not available for purchase to the general public and are not sold at our theme park ticket windows. Since these Meeting & Convention partial-day and multi-day tickets are not available for purchase at our Theme Park Ticket Windows, you are only able to purchase them here: https://www.mydisneygroup.com/mozilla<br />
<br />
Discounts do not apply for Mickey's Very Merry Christmas Party at Magic Kingdom (each Sun, Tue, Thur, Fri in December).<br />
<br />
=====Disney FastPasses=====<br />
All of the Meeting & Convention tickets include the ability to pre-select up to three FastPasses per theme park visit day. Details on how to create a My Disney Experience Account and pre-select FastPasses can be found here: https://www.mydisneygroup.com/mozilla under PLAN YOUR VISIT tab.<br />
<br />
=='''Extracurricular Activities'''==<br />
Costs for these activities are self-funded and can not be expensed. Feel free to add activities and invite others.<br />
<br />
*[https://wiki.mozilla.org/All_Hands/Orlando2018#Discounted_Disney_Park_Passes Disney Park Passes]<br />
* [https://disneyworld.disney.go.com/en_CA/special-offers/multi-day-tickets/details/ Disney gives 20% off 4+ Day Passes for Canadian Residents (may be a better deal than the corporate portal)]<br />
*[https://docs.google.com/spreadsheets/d/1Wi_BZxCtsRAXH0bEzpA880m8OhpnGk73-y1P0aqQyrg/edit#gid=225771109 Spreadsheet with lots of Disney info]</div>Dbaronhttps://wiki.mozilla.org/index.php?title=Paris&diff=1203157Paris2018-10-31T07:31:43Z<p>Dbaron: /* Finding the Space */ pret is now imago</p>
<hr />
<div>= Welcome to Paris! = <br />
<span style="float:right;padding:0 0 1em 1em">[http://standblog.org/blog/post/2013/03/27/Les-nouveaux-bureaux-de-Mozilla-a-Paris http://farm9.staticflickr.com/8511/8595089145_ef224353b7_b.jpg]</span><br />
We're glad to have you here! This page is meant to help visitors find their way to the Paris office and around Paris. If you have any additional questions, please feel free to ask in #paris on irc.mozilla.org, or if you happen to be around the space come talk to us. If there is anything missing that you think might help future visitors, please add it / let us know :-).<br />
= Details =<br />
'''Email:'''<br /><br />
To be added<br />
<br />
'''Address:'''<br /><br />
16bis Boulevard Montmartre <br /><br />
75009 Paris, France <br /><br />
[https://maps.google.com/maps?q=16+Boulevard+Montmartre,+75009+Paris,+%C3%8Ele-de-France,+France&hl=en&ie=UTF8&ll=48.871871,2.341332&spn=0.003507,0.009645&oe=utf-8&client=firefox-beta&geocode=FcK56QId2rkjAA&hnear=16+Boulevard+Montmartre,+75009+Paris,+%C3%8Ele-de-France,+France&t=m&z=17 Map]<br />
<br />
<div style="float:right;clear:right;padding:0 0 1em 1em">__TOC__</div><br />
= About the Space =<br />
Our new Mozilla Paris space combines working areas for up to 50 people and a vibrant community space designed to host up to 150 people for our Mozilla community events, meetups, and work weeks. We’ve incorporated the same leading technologies, amenities and designs as our other unique Mozilla Spaces around the world, all with a unique Paris feel. After all, it is Paris!<br />
<br />
[https://blog.mozilla.org/places/2013/03/27/mozilla-paris-finally-united/ Announcement blog post] (March 27, 2013)<br />
<br />
= Traveling to Paris =<br />
See [http://en.wikivoyage.org/wiki/Paris#Get_in Wikivoyages on getting to Paris].<br />
<br />
Note that Gare du Nord (French for "North Station"; outside of Paris it may be called "Paris - Nord") is about a 20-25 minute walk from the Mozilla office, so depending on the weather and what you're carrying, you might choose to walk from Gare du Nord to the office (alternatives: Metro with transfer, taxi). But if you do, you should definitely consult a map first and probably have the map with you.<br />
<br />
= Finding the Space =<br />
<br />
From the metro, use one of the following two stations:<br />
* '''Grands Boulevards''': Follow the signs to exit 2 (boulevard Montmartre). After you reach the top of the stairs, continue straight ahead (without crossing any streets) until you reach a large doorway with the number 16<sup><u>BIS</u></sup> over it, just after the Imago.<br />
* '''Richelieu-Drouot''': Follow the signs to exit 3 (bd. Montmartre). At the top of these stairs, continue straight ahead and immediately cross Rue Drouot (the smaller of the two streets at the intersection), and continue straight ahead (without crossing any other streets) until you find a large doorway with the number 16<sup><u>BIS</u></sup> over it, just before the Imago.<br />
<br />
There is no Mozilla sign on the door or building. <br />
<br />
Once you're at this large door, you'll need to go through ''three'' doors to enter the Mozilla space:<br />
* First, the large door to the street with the number 16<sup><u>BIS</u></sup> over it. It has a keypad to the right of it. On this keypad you can use the arrows to select "MOZILLA" and then press the button with a bell symbol to call to be let in. Once you are let in, you need to push on the ''left'' half of the door. Push on the bar rather than the doorway, since there is a smaller door (hard to see) that does not take up the full doorway. (Note that both halves of the door have a bar to push on, but you need to push on the bar on the left half.) This door is '''quite heavy''', and you will have to push '''hard'''.<br />
* Second, you need to cross a metal gate just inside this doorway. Follow exactly the same procedure on the freestanding keypad before the gate. Then pull on the right half of the gate to enter. (Note that with both the first and second doors, the part of the door that moves is the half ''further'' from the keypad.)<br />
* Then, walk forward about 10 meters, and on your right you will see a doorway with the word "Mozilla" on the glass. This door has a simple doorbell button on it you can use to be let in. On this door, pull on the left half of the door (which is the only half with a handle).<br />
<br />
Then walk up the stairs into the Mozilla space.<br />
<br />
== Leaving the Space ==<br />
<br />
When leaving the space, please use the small button in the final pair of doors to exit, and do not open the large doors themselves.<br />
<br />
= Traveling around in Paris =<br />
[http://en.parisinfo.com/paris-map/getting-around/public-transport/ Public transit] in the city offers a few options - metro, bus, RER (suburban express railway), and suburban trains (Transilien).<br />
<br />
= Hotels =<br />
<br />
There are many hotels near the office. Some (across varying price/quality ranges) that Mozillians have had good experiences staying at include:<br />
<br />
* [http://www.ihg.com/holidayinn/hotels/us/en/paris/parpp/hoteldetail Holiday Inn Paris Opera - Grands Boulevards] (****)<br />
* [https://en.astotel.com/hotel/34b-en/overview Hotel 34B] (***)<br />
* [http://www.hotel-vivienne.com/en/ Hôtel Vivienne] (**)<br />
* [http://www.millenniumhotels.com/millenniumparis/ Millenium Opera] Very nice, is wheelchair accessible too!<br />
<br />
== Laundry ==<br />
<br />
There is a laundry nearby at 37, rue de Trévise ([https://maps.google.com/maps?saddr=16+Boulevard+Montmartre,+75009+Paris,+France&daddr=37+Rue+de+Tr%C3%A9vise,+75009+Paris,+France&ie=UTF8&dirflg=w directions from office]). It's mostly self-explanatory (and has good english signage). The one thing that is unlabeled is the detergent/softener dispensing machine. In France, laundry detergent is generally (as it is at this laundromat) in small foil-covered bricks. The packets are something else (probably softener, maybe bleach). The money input for all the machines the laundromat takes either coins or bills.<br />
<br />
= Car hire =<br />
<br />
= Paid staff =<br />
<br />
= Good things nearby =<br />
<br />
== Coffee ==<br />
<br />
== Bars ==<br />
<br />
== Cafes ==<br />
<br />
== Bread ==<br />
There is a good bakery at 26 r. du Faubourg Montmartre. [https://www.google.com/maps/dir/16+Boulevard+Montmartre,+Paris,+France/Denis+Alain,+26+Rue+du+Faubourg+Montmartre,+75009+Paris,+France/@48.8725303,2.3405219,18z/data=!3m1!4b1!4m14!4m13!1m5!1m1!1s0x47e66e3ebb6fbb61:0xe8752d6580b17b64!2m2!1d2.3411542!2d48.8721388!1m5!1m1!1s0x47e66e3ef92b004f:0x9c79ff2801016cbb!2m2!1d2.3430229!2d48.8735729!3e2 directions from office]<br />
<br />
== Chain restaurants ==<br />
<br />
== Other notables ==</div>Dbaronhttps://wiki.mozilla.org/index.php?title=Standards/Participating_in_a_W3C_Working_Group&diff=1202558Standards/Participating in a W3C Working Group2018-10-17T15:44:10Z<p>Dbaron: email address advice revision</p>
<hr />
<div>== Ways to participate (to join or not to join) ==<br />
<br />
W3C working groups have a defined membership: people can become a member of a working group or community group by being nominated by a W3C member company, by being invited by the chairs of the group (an invited expert), or by being a W3C staff member placed on the group by the W3C. However, most W3C working groups have most of their technical discussion on public mailing lists, which means that non-members can participate in many of the activities of the group. So, when you approach a W3C working group, you could decide to do so by becoming a member of the group or just by joining the public mailing list and participating in the discussion.<br />
<br />
How should one choose between these alternatives? While there's a good bit of variation between groups depending on the [http://www.w3.org/Consortium/activities charter] of the group, its chair(s), and the other participants in the group, I suggest considering the following factors:<br />
* being a member of the group signals Mozilla's support for a group to others (e.g., W3C staff, others in the industry). (This means that if the group is working on something we don't like, being a member may confuse other companies into thinking that Mozilla supports or is contributing to the work of the group).<br />
* members of the group may (depending on the charter of the group) have more ability to influence the decisions and the output of the group<br />
* if you want to attend face-to-face meetings or teleconferences of the group, you should be a member of the group<br />
* the group may have expectations that members participate (e.g., by attending phone or face-to-face meetings, by keeping up with certain aspects of the discussion). These vary by group and are described in the "Participation" section of the group's charter.<br />
* some mailing lists may require being a member of the group to subscribe (although this is rare), even when the archives are publicly viewable<br />
* becoming a member of the working group involves making some patent commitments, which may make other participants more comfortable accepting your contributions<br />
* other members of the group may expect somebody representing Mozilla is responsible for implementation work / decisions in Gecko; if you're not, you may wish to consider being extra clear about what your role is<br />
<br />
When you decide you want to participate:<br />
* If you want to just join the [http://lists.w3.org/Archives/Public/ public mailing list]:<br />
*# Send an email to "list-name-request@w3.org" with the subject "subscribe". (Don't forget to add the "-request" to the end of the list name.)<br />
*# Reply to the automated reply.<br />
* If you want to become a member of the working group, and you work for Mozilla:<br />
*# Make sure you have a W3C member access account associated with Mozilla:<br />
*#* if you don't already have a W3C user account, [https://www.w3.org/accounts/request create one], and choose '''Mozilla Foundation''' as the affiliation. Using a @mozilla.com email will lead to the account being created automatically; other email addresses will require human intervention but often (but not always) should be created within a day.<br />
*#* if you have an W3C user account associated with a previous employer or as an invited expert, [https://www.w3.org/Systems/db/userInfo#affiliation change the affiliation of that account] to '''Mozilla Foundation'''<br />
*# Contact Mozilla's Advisory Committee Representative, [[User:Dbaron|David Baron]], and ask him to add you to the group.<br />
<br />
== Suggestions for participation ==<br />
<br />
* Avoid making promises you can't keep, even if pressured to do so.<br />
* Try to avoid speaking on behalf of Mozilla. If the process or other participants in the working group want you to speak on behalf of Mozilla, question such process or participants. However, rather than staying silent in such a situation, it's probably a good idea to both state your position and clearly state how much Mozilla consensus there is behind that position. Though it's not an ideal situation, it's ok for Mozilla's employees to disagree with each other on the best way to move the Web forward and implement Mozilla's mission.<br />
<br />
== Technical tips ==<br />
<br />
* You should connect your github account to your W3C account at https://www.w3.org/users/myprofile/connectedaccounts in order to make IPR-checking bots (which some working groups use) happy.<br />
<br />
== Suggestions for chairing ==<br />
<br />
If you end up as the chair of a group, you should become more familiar with the process, since you'll sometimes be responsible for enforcing them (along with a team contact, if the group is a working group). Some documents that are helpful are:<br />
* [https://www.w3.org/Consortium/Process/ W3C Process] (for working groups)<br />
* [https://www.w3.org/community/about/agreements/#cgroups community group process] (for community groups)<br />
* [https://www.w3.org/Guide/ The Art of Consensus: A Guidebook for W3C Group Chairs and Participants]<br />
* [https://www.w3.org/Consortium/cepc/ W3C Code of Ethics and Professional Conduct]</div>Dbaronhttps://wiki.mozilla.org/index.php?title=Travel_Guide&diff=1202214Travel Guide2018-10-11T03:02:36Z<p>Dbaron: /* General advice */ carry a pen</p>
<hr />
<div>----<br />
:: This page was originally created on Mozilla's internal intranet. However, it contains lots of information that could be useful to Mozillians who travel to Mozilla events, or really, anyone who travels, period. The original page (and its history) disappeared when the intranet site was retired.<br />
----<br />
<br />
Travel doesn’t have to suck. In fact, there are probably relatively few parts of your life where optimizations can make such a difference. We (the authors) have millions of miles travelled between us.<br />
<br />
* We never lose our luggage.<br />
* We can get from the airport entrance to our gate in 7 minutes.<br />
* We get free booze at the airport, upgraded flights, nicer rooms in hotels.<br />
* We don’t eat crap on the road, indeed we often discover great restaurants.<br />
* We have secrets.<br />
<br />
Let us show you them.<br />
<br />
But first, '''the 3 simplest things you can do to make travel a lot better''':<br />
<br />
# Don’t check luggage<br />
# Check in online<br />
# Pick a Frequent Flyer program<br />
<br />
Do those three and you’re already in the 80th percentile for travel success. What follows below is travel brilliance.<br />
<br />
= Planning =<br />
<br />
== Quick Tips ==<br />
* Scan a copy of your passport and any other travel documents, and put them somewhere web accessible but password protected (like Dropbox or Google Drive). This is helpful for getting replacements, and for getting consular help in the meantime.<br />
* Let your credit card company know that you travel. Anti-fraud measures might lock your card the first time you use it on foreign soil, but they can flag your account so that doesn’t happen. This is no fun to discover after the fact.<br />
<br />
== Pick a Frequent Flyer Program ==<br />
<br />
Prices are generally going to be competitive, so figure out your most common trip(s) and figure out which airline/alliance is best for those. Use that group for everything. You can easily sign up for FF programs online, and add it to your travel agency profile (Egencia for Mozilla employees).<br />
<br />
Even if you travel rarely, you'll eventually accrue enough mileage for free travel, and having a FF number makes online check-in easier.<br />
<br />
If you travel often enough, though, (25k+/year on most airlines) you start earning preferred status. This is the difference between "scum" and "How can I help you?" You have shorter lines for agents, shorter lines for security, you board first. You get access to elite lounges while you wait, and free upgrades to business class to make the trip more pleasant. These are little niceties, but they add up, and make travel much nicer. You can often share status with someone less privileged, which means your spouse likes traveling with you more, too.<br />
<br />
== Check In Online ==<br />
<br />
Every airline will let you check in online, usually 24 hours before your flight leaves. I know this will feel weird the first time, but it is an absolute necessity. With online check-in and no checked luggage, you can skip all the lines at the airport except security (and possibly customs/immigration).<br />
<br />
Checking in early may put you into a lower "group" for boarding (or at least not the suckiest, all-the-overhead-bins-are-full group). Check in as early as possible, even if you don't know how many bags you will check (correct answer: 0). You can always add (and pay for) checked bags when you get to the airport.<br />
<br />
The one '''exception''' to this guideline is that if you think your flight might be delayed or cancelled due to weather, ''don't'' check in online ahead of time. If you have to re-book, and you are already checked-in, the agent will have to "uncheck" you, which may slow down the re-booking process and cause you to miss out on alternate flight options. Keep in mind that weather problems cause ripple effects even in locations where weather is good. For example, your flight out of sunny Phoenix might be cancelled because the aircraft is grounded by a snowstorm in Chicago. (See this Egencia blog post for [http://info.egencia.com/wintertraveltips2014.html tips for avoiding weather delays].)<br />
<br />
Online check-in also lets you choose your seats, which brings us to...<br />
<br />
== Choose Your Seats ==<br />
<br />
* Take a window seat for very short flights or very long flights. Window seats have more shoulder room, less hassle from other passengers, and a window. The only downside is bladder management, but on short flights you can stick it out and on long ones you can get up when your fellow passengers do.<br />
* ''Every'' plane has some seats that suck. No recline, noisy, cold, lack of floor storage or slightly narrower than most, [http://www.seatguru.com SeatGuru] will tell you what to avoid. It'll also tell you which seats are great (extra legroom, etc) that you should take given half a chance. Usually, exit-row seats have extra legroom (good for tall people), and the last row and the row in front of the exit row do not recline (bad in general). The first row in a section (where you have a bulkhead in front of you instead of another seat) typically does not have under-seat storage, so everything must go in overhead bins, but it typically does have more legroom. (Seatguru will tell you whether or not this is the case on a particular plane.)<br />
* ''The Middle Seat Gambit'' - If you’re traveling with someone else, check in online together and look for an empty 3-person row. Take the aisle and window. Middle seats fill up last, there’s a decent chance the seat stays empty. If so, you have a lot more space to dump things during the flight, and more legroom since you can use that space instead of putting things under the seat in front of you.<br />
* If you’re traveling alone, you can still use the middle seat gambit by checking in online and looking at the seat map for someone acting as a de facto accomplice.<br />
* If there is only one (worst possible) seat left when you go to select seats, ''don't take it''. It will be claimed by someone else, and the gate agent will assign you a different seat. A flight that full might mean that someone gets bumped, but lack of a seat assignment doesn't guarantee it will be you.<br />
<br />
== Manage Layovers ==<br />
<br />
Flying nonstop to your destination is always easiest, but if that’s not a possibility for whatever reason, here are some other things to keep in mind:<br />
<br />
* Major metropolitan centers are often served by multiple airports, and each airline will have a preference. If you can’t get the flight you want with the airline you like, look to see whether you’re just pointing at the wrong airport.<br />
* If you can’t fly nonstop, you probably at least have your choice of connection airports, and the choice matters there. What’s more, a given airline will have certain preferred connection cities, so a couple trips should get you a reasonably complete list. (For example, connecting from Toronto to San Francisco on Star Alliance, it is much preferable to connect in Denver or Vancouver than it is to connect in Chicago O’Hare.) Consider the immigration/customs procedures of the country you're connecting in if it's separate from the origin or destination (e.g., prefer Vancouver over a US airport for connecting between Toronto and Auckland, since the US requires internationally-connecting passengers to go through immigration and customs).<br />
* If you have to have a connection, you might also have the opportunity to fly to a better airport (e.g., if you have to connect to Washington, DC, you are likely to be able to fly to DCA instead of IAD).<br />
* Take the season and likely weather into account when picking connecting airports; avoid snowy airports in winter, thunderstorm-y airports in summer.<br />
* If you have to layover overnight, prefer airports that have on-site hotels (and for god’s sake prefer Munich over Frankfurt).<br />
* If you’re crossing a border during your flight, it’s often preferable to layover in-country before crossing over. It means your first flight is domestic, so you can arrive later at the airport since there’s no immigration headache there. <br />
* Another reason not to check a bag is that when you have a connection after arriving in some countries (e.g., the USA, but not EU countries), you have to claim your bag, take it through customs (even though they rarely look at it), and then check it again for your connecting flight. More time and hassle.<br />
* Remember to account for boarding time when calculating layovers. If flight A arrives at 12:00 and flight B leaves at 1:00, you do not have an hour, you have about 20 minutes (because you need to get OFF of flight A once it arrives, transit to whichever gate/terminal flight B is in, and then be there for flight B '''boarding''', not flight B '''departure''').<br />
<br />
= Immigration and Customs =<br />
<br />
== General advice ==<br />
* Make sure you know what the requirements are for crossing all immigration and customs barriers before you do so. If you don't know what those requirements are, embassy or consulate websites are often useful, as are the US government's [http://travel.state.gov/content/passports/english/country.html country specific information] (though somewhat tending towards information useful to Americans).<br />
* Make sure you have any documentation needed in your carry-on luggage. When entering a country where you're not a citizen or resident, you should carry proof of onward travel, particularly if the reservation on which you're flying doesn't return you to your home country (e.g., because you're traveling on separate reservations).<br />
* If you're ''transferring'' in a country (or multi-country immigration zone) that's different from your origin or destination, figure out whether you'll need to deal with immigration there, and if so, what the rules are. This might vary depending on the airport, or in some cases even on which terminal you arrive at and depart from. (In the latter case, airport websites are often helpful.)<br />
* always carry a pen (blue or black) somewhere in your checked luggage for filling out the immigration and customs forms<br />
<br />
== Country-specific notes ==<br />
<br />
=== USA ===<br />
* visitors under the [https://travel.state.gov/content/travel/en/us-visas/tourism-visit/visa-waiver-program.html visa waiver program] (those who don't need a visa) must apply online for an [http://www.cbp.gov/travel/international-visitors/esta ESTA].<br />
<br />
=== Canada ===<br />
* visitors who do not need a visa, are entering Canada by air, and are not US citizens or Canadian citizens or Canadian permanent residents, must apply online for an [http://www.cic.gc.ca/english/visit/eta.asp eTA].<br />
<br />
=== Schengen Area (Europe) ===<br />
* The [http://en.wikipedia.org/wiki/Schengen_Area Schengen Area] is an immigration-barrier-free zone covering most of the European Union and some additional non-EU countries, but not the UK or Ireland.<br />
* If you need a visa to visit the Schengen Area, it is easier to get such a visa if your point of arrival in the Schengen Area is the same country as your destination. (For example, if you're traveling to Spain, it is easier to arrive in Madrid after connecting in the UK or US than connecting via Amsterdam, since in the latter case getting the visa requires dealing with both the Spanish and Dutch authorities.)<br />
* If your nationality requires a visa to visit the Schengen Area and your trip does not terminate in Schengen, avoid making more than one connection in Schengen; in such a case you must get a Schengen visa, even though that's not your destination. Schengen immigration authorities look at your ''next'' point of travel (not your final one) to decide whether you need a visa; if it is Schengen, they will ask for one.<br />
<br />
=== New Zealand ===<br />
* Make sure to declare any shoes in your checked luggage. The authorities just want to look at them and maybe clean the dirt off for you, but they'll be upset if you don't declare them.<br />
* Don't even think about [http://www.nzherald.co.nz/nz/news/article.cfm?c_id=1&objectid=11404025 bringing fresh fruit] into New Zealand or you will get an instant fine.<br />
<br />
=== Australia ===<br />
* Visitors who can can enter without a visa must apply online for an [https://www.eta.immi.gov.au/ ETA].<br />
<br />
= Packing =<br />
<br />
'''Quick Tips'''<br />
* Have a toiletry bag that you keep stocked, rather than trying to remember to pack toothbrushes &c the day of. It doesn’t cost much to buy the duplicates once, and saves hassle/forgetting.<br />
* Put your favourite head, stomach, and sleep meds in the toiletry bag. You can buy most things on the road, but meds are sometimes an exception.<br />
* Throw a couple of large ziploc bags in there, too. They are immensely useful for storing wet clothing or leaking bottles or, by contrast, for putting things like passports in when you need them to stay dry. They weigh nothing and disappear into a pocket until needed.<br />
* Layers. You can adapt to a wide range of climates, even multi-city travel, by packing layers. Shirt, Sweater, Hoodie, Jacket is plenty warm, packs much more compactly than a parka, and gives you middle ground for an overwarm restaurant or an overcool office.<br />
* While you're packing, make a text list on your phone of everything you pack. Towards the end of your trip (such as waiting for your flight home), put a '+' next to every item you actually used. Next time, don't pack the things you didn't use. Also, if your bag goes missing, you have a list of what was in it.<br />
<br />
== Don’t Check Luggage ==<br />
<br />
:: Repeat after me: Checked luggage is for chumps.<br />
<br />
:: Again. Checked luggage is for chumps.<br />
<br />
:: -- George Clooney, ''Up in the Air''<br />
<br />
Every time you give your bag to the airlines, you're inviting them to lose it, abuse it, leave it in your departure city, forget about it on the tarmac during a rain delay, etc. North American airlines will allow you one carry on suitcase and one “personal bag” which usually means a purse or laptop. This is easily enough for a week of travel, and can be extended indefinitely with laundry service. Invest in a good carry-on and bring it with you.<br />
<br />
Put everything you need during the flight in your laptop bag, in case you have to gate-check your carry-on suitcase (common on short flights with smaller planes).<br />
<br />
== Choose the Right Luggage ==<br />
Checked luggage will inevitably be destroyed over time, regardless of quality. If you stick to carry on, though, good luggage will last forever; be willing to pay once for something that gets it right. Your happiness while traveling is worth it.<br />
<br />
His bias for non-rolling luggage notwithstanding, [http://www.onebag.com/bags.html this is the single best guide out there] for evaluating luggage. The highlights:<br />
<br />
* Lighter is better<br />
* Curvy designs rob you of packing volume, prefer right angles<br />
* Chain zippers are stronger than coil zippers (look for YKK as the brand of zipper)<br />
* Pocket design and positioning matters<br />
* So do tie-downs<br />
<br />
In truth, the best way to maximize quality while minimizing weight is to let go of the dependence on rolling bags. Soft-sided, non-wheeled bags are exceptionally light and versatile. [http://www.tombihn.com Tom Bihn] and [http://www.redoxx.com/ Red Oxx] are your best plays. Tom Bihn’s Aeronaut is is a full-sized carry-on that converts to a backpack for long walks across cobblestones/sprints to catch a connection/etc. The Red Oxx Air Boss was designed by the same guy who wrote the luggage-choosing guide above.<br />
<br />
If you're not ready to let go of wheeled bags, any manufacturer with a lifetime warranty is probably worth considering. These include:<br />
<br />
* [http://www.briggs-riley.com/ Briggs & Riley]<br />
* [http://www.travelpro.com Travelpro] ("the best" carry-on according to [http://thewirecutter.com/reviews/best-carry-on-luggage/ The Wirecutter])<br />
* Certain models of [http://shop.eaglecreek.com/lightweight-carry-on/l/111 Eagle Creek] (not all models have a lifetime warranty)<br />
<br />
Pay attention to the bag’s extensible arm: is it well constructed? What does it do to your interior space? 2 segments of extension or 3? Moving parts make everything more fragile -- if you are choosing moving parts in your luggage, they need to be brilliant.<br />
<br />
== Buy It There (BIT) ==<br />
<br />
Don’t try to anticipate every contingency and pack for it. You will bog yourself down with unnecessary cruft. Pack for what you ''know'' you’ll need, or at most what you reasonably expect to need the majority of the time. You can find contact solution, toothpaste, aspirin, and dental floss at almost any convenience store. For the rest, shove an extra $50 into a pocket somewhere and buy whatever you need there, if it comes up. <br />
<br />
(Good news: It comes up less often than you’d think.)<br />
<br />
BIT exceptions: <br />
There are some things you don't want to source while traveling - if you only use one specific brand of shampoo, conditioner, etc, transfer it to a small, travel-friendly bottle. Depending on where you're traveling BIT can be tough if you don't speak the language and are looking for something very specific (like Cipro in India or a flat iron in China). Goes without saying, but BIT does *not* apply to medications (remember that what requires a prescription varies by country, but you can apply it if you know that something can be bought without a prescription at your destination).<br />
<br />
=== Corollary: Wash It There ===<br />
If you’re gone for longer than a carry-on can reasonably contain (which is longer than you think), don’t fail over to multiple suitcases; just get things laundered partway through. Your hotel will offer laundry service, though it will be overpriced. Most of the time you’ll find a wash and fold place within walking distance or a service that does pick up and next day drop off.<br />
<br />
Also keep in mind that at most Mozilla or other geek events, you will probably acquire at least one or two t-shirts. You can bring one or two fewer shirts; if this guideline fails, wash one of the ones you brought.<br />
<br />
If you bring quick-drying underwear and socks, you can wash them in the sink or bathtub and dry them overnight on the towel rack (except in humid climates). You can skip bringing detergent by using the hotel's shampoo (as long as you don't mind your underwear smelling like "ginger lemongrass" or whatever); shampoo is just mild detergent. Check the plumbing before you fill the sink; some hotels don't install the lever for raising the plug. Before hanging items to dry, roll them in a towel and squeeze out excess moisture.<br />
<br />
== Counterpoint: The case for checking a suitcase ==<br />
A few heavy-traveling Mozillians are in the "checked bag" camp. Add your reasons for using this strategy here:<br />
* Problems with checked luggage are actually quite rare.<br />
* You don't have to schlep a roll-aboard through the airport with you, including squeezing it into tiny toilet stalls.<br />
* You can pack a few extra things that help you be more comfortable on an extended trip.<br />
* At least one airline (American) gives early boarding privileges (after Elite and Priority but before Zone 1) to passengers with no overhead baggage.<br />
* You aren't limited to 100ml bottles of liquid/gel/cream, and can bring home ''properly packed'' wine, booze, perfume, etc. (Wrap the bottle in at least two plastic bags and nestle it in the groove left by the extending handle, surrounded tightly by clothes.)<br />
* Having airline status often helps your bag appear on the belt faster. Also, if the final segment of your trip is an international arrival in the United States, you're unlikely to have to wait long for your bag, since all baggage goes to the same belt, so it gets there quickly.<br />
* TIP: Get a suitcase with four wheels. Baggage handlers can slide it across the floor of the cargo hold instead of tossing it, subjecting the suitcase and its contents to much less abuse. Anything that protrudes, like carry straps or zipper pulls, can get snagged and chewed up in baggage-handling equipment; go for streamlined.<br />
* TIP: Ask for your checked luggage to be marked "Fragile". It will be loaded on top of other bags, and usually be unloaded first.<br />
* TIP: If you check luggage, don't let your eyes off the bag until there's a tag on it, and if you can, check that the tag is correct (with your name and correct destination airport on it). One of the common reasons for lost/delayed luggage is getting the wrong tag on it right at the check-in desk.<br />
* TIP: Things to make sure are '''not''' in your checked bag: everything you need to get through customs and immigration and get to your final destination. Any electronics that might be stolen. Lithium-ion batteries (prohibited).<br />
<br />
Some airlines (particularly non-North American ones) have much lower limits for what you're allowed to carry on, so you'll have to check luggage anyway.<br />
<br />
Some airlines (e.g., Air France, KLM) will even want to weigh your carry-on bag (often although not reliably), and want it to be a weight that's lower than what it is with your laptop in it (e.g., 6kg, 8kg). Remember that your laptop often counts as a separate personal item and you can take it out of the bag before weighing.<br />
<br />
==Packing Techniques and Tools==<br />
Your strategy for how to put your stuff in your suitcase is very much a matter of personal preference, along with the type of travel you're doing (destination vs. touring) and the type of clothes you bring. Here are some ideas that may be helpful.<br />
<br />
* The [http://www.onebag.com/pack.html bundle method] is great for avoiding wrinkles, but it tends to require that you unbundle ''everything'' to get out any single thing.<br />
* It's extremely helpful to have some kind of containers to organize your stuff. Purpose-made packing "cubes" are great, but are absurdly expensive. You can get by with zip-top plastic bags if you don't travel often, or while you're waiting to find ready-made cubes on sale. <br />
* If you buy only one packing accessory, consider getting a [http://www.amazon.com/Eagle-Creek-Travel-Pack-It-Folder/dp/B002YIRC3O/ packing folder], which helps you fold larger items (shirts, pants, skirts) to a uniform footprint, and then encloses them like an envelope.<br />
* Compression bags, which let you squeeze all the air out of your clothes, are good only for clothes that don't easily wrinkle. However, a compression bag can be great as a laundry bag to minimize the volume of dirty clothes on your way home.<br />
<br />
= Airport Hacking =<br />
'''Quick Tips'''<br />
* ABC: Always Be Charging. Wherever you come to rest, be charging. Maybe your flight has power plugs, that's swell, but maybe they stop working, or your seatmate gets to it first, or you need it to charge your phone. If you're at rest for more than 10 minutes, find a plug. If you bring a power strip so others can plug in, too, you can make friends anywhere :-)<br />
* Watch where uniformed crew members go. They know the best eateries in any given airport, and even where to stand on the tram platform in order to get off quickly at the other end.<br />
* The internet knows about delays before your gate agents do. Bookmark [http://flightaware.com/live/ flightaware] right now, and use it from your phone at the airport to keep tabs. Caveat: Flightaware may show your flight as delayed because the inbound plane you're getting on is delayed; if the airline substitutes another aircraft, your flight could be on time or only a little delayed.<br />
* If you do see signs of a significant delay, particularly at night when it's likely you'll be put off until morning, act swiftly before the lines form. Talk to gate agents about rebooking onto other flights and if the line there is long, be on the phone with your airline as well. First to rebook means first to call hotels and taxis and all the rest. Being last to rebook means sleeping in the airport. If you have elite status, call the customer service number for elite members, not the general customer service number.<br />
* When you get off the plane, the restroom closest to your gate will be crowded with other people from your flight. Keep going to the next one further away.<br />
* No one wants to sleep in an airport, but flight delays or cancellations, or just poor planning, may require it. There is actually a whole website devoted to [http://www.sleepinginairports.net/tips.htm sleeping in airports].<br />
<br />
<br />
== Being prepared for security ==<br />
* Bring identification. [http://www.tsa.gov/traveler-information/acceptable-ids Here's a list of acceptable IDs] in the US. If you forget your ID, all is not lost. It's possible, with some extra hassle, to travel within the US even if you don't have your identification. [http://blog.tsa.gov/2013/04/tsa-travel-tips-tuesday-can-you-fly.html Here's what the TSA says to do if you don't have ID.]<br />
* Avoid getting into a screening line behind people who look like they don't travel often (families with kids, retirement-age folks, large groups).<br />
* Wear slip-on shoes (and wear socks if you don't want your feet getting dirty).<br />
* Consider not wearing a belt, or wear one with no metal, so you don't have to take it off.<br />
* Avoid clothes with extra pockets, like cargo pants. They can be flagged by the nudie-scan, and cause you to get a pat-down. Same for "travel" clothes with hidden pockets; these can be handy while touring, but not while flying. Even a hoodie can win you a pat-down for the hood and kangaroo pocket. <br />
* On the other hand, a jacket with lots of pockets is like an extra carry-on; you have to remove it for security anyway, and you can keep your in-flight necessities (gadgets, etc.) close to hand during your flight.<br />
* Know the drill with liquids, gels, and creams: containers at most 100ml/3oz, in a clear zip-top bag, 1 liter/1 quart size. Have this in an external pocket of your carry-on, ready to pull out and put in a bin. (If you travel often, you might want to get a sturdier bag than the grocery store kind. It must still be clear and zip-top.)<br />
* Avoid large metal jewelry.<br />
* Take everything, but especially metal (keys, coins, etc.), out of your pockets.<br />
* Leave your pocket knives and multitools at home.<br />
* If you're wearing an activity monitor, such as a FitBit, take it off for screening.<br />
* You should hang onto your ID and boarding pass as you go through the line, but you can't carry them through screening; put them in your bin.<br />
* Put the bin with your shoes, jacket, and liquids onto the conveyor belt first. You can be getting dressed while the rest of your stuff comes through.<br />
* Take your laptop out of your bag and put it in a separate bin. You can usually leave it in a sleeve, as long as there's nothing else in the sleeve. <br />
* Consider getting a checkpoint-friendly laptop bag, with a laptop-only section that folds out without taking out the computer. The less you handle your laptop, the less likely you are to drop it. (US TSA allows you leave the computer in this type of bag; other countries often do not.)<br />
* Don't go through the screening machine until your stuff is on the conveyor belt.<br />
<br />
== US Trusted Traveler Programs ==<br />
If you frequently cross US borders, you can save time and hassle in the long run by enrolling in one of the programs that provide expedited entry for pre-approved travelers. Enrolling involves an application fee and form, and an in-person interview at an entry point, so there is a start-up cost in time and money. Which program you should enroll in depends on the type of crossing you do most; you can enroll in more than one. <br />
<br />
* When entering the US, if you're not in a "trusted traveler" program, try to get into the immigration queue that is ''next to'' the Global Entry lane. If no one is in the Global Entry lane, the officer there will often take people from the nearby queue, making it move faster. Do likewise for NEXUS when entering Canada.<br />
* Wear Firefox gear when going through immigration, anywhere. It creates goodwill and starts pleasant conversations.<br />
<br />
===Automated Passport Control===<br />
Automated Passport Control kiosks are available to citizens of the US, Canada, and [http://www.cbp.gov/travel/international-visitors/frequently-asked-questions-about-visa-waiver-program-vwp-and-electronic-system-travel Visa Waiver Program] countries, for entry into the US, in an expanding number of North American cities. Unlike Global Entry or Nexus, these kiosks require no pre-registration. You swipe your passport, let the kiosk take a photo, answer some questions, and then get a receipt that you show to a Customs and Border Patrol officer. The kiosk replaces filling out a customs card by hand.<br />
<br />
See the [http://www.cbp.gov/travel/us-citizens/Automated%20Passport%20Control Automated Passport Control] webpage for a list of cities with APC kiosks.<br />
<br />
=== Global Entry ===<br />
[http://globalentry.gov/about.html Global Entry] provides expedited screening for entry ''into'' the US at certain airports. Once in the program, you can go to an automated kiosk instead of an immigration agent (skipping the enormous lines that result from multiple international flights arriving at about the same time), and you can answer the customs questions at the kiosk instead of filling out a paper form. Unless there is an issue with your kiosk interaction (such as it couldn't read your fingerprints), you don't need to talk to a CBP agent. Global Entry is open to U.S. citizens, lawful permanent residents of the U.S., Dutch citizens, South Korean citizens and Mexican nationals.<br />
<br />
=== NEXUS ===<br />
[http://www.globalentry.gov/nexus.html NEXUS] provides expedited screening for crossing the US-Canada border in both directions. It can be used at land and sea entry points as well as at airports. You can use the NEXUS-only lanes at land crossings only if every person in the vehicle (including children) has a NEXUS card. Using NEXUS at an airport requires scanning your irises. If you wear contact lenses, you must remove them for the initial iris scan that is taken after your enrollment interview.<br />
<br />
=== Other US programs ===<br />
* [http://www.globalentry.gov/netherlands.html FLUX] expedites passage between the US and '''the Netherlands''', and is open to US and Dutch citizens.<br />
* Global Entry members can receive expedited entry into '''[http://www.globalentry.gov/newzealand.html New Zealand]'''.<br />
* [http://www.globalentry.gov/sentri.html SENTRI] provides expedited entry into the US from '''Mexico''' at specific land crossings.<br />
* [http://www.globalentry.gov/korea.html Smart Entry Service] provides expedited entry into the Republic of '''Korea'''. It is open to US and Korean citizens.<br />
* [http://www.globalentry.gov/smartgate.html SmartGate] provides streamlined entry into '''Australia''' for US Global Entry members. Visa requirements still apply.<br />
* [http://www.globalentry.gov/tsa.html TSA PreCheck] enables US Global Entry and Canadian NEXUS members to use designated TSA airport screening lanes, without removing liquids, laptops, shoes, jackets, or belts. You must provide your membership number when booking flights with participating airlines. TSA is expanding the PreCheck program to include more people, including US military members and those invited by their airline's frequent flyer program. You must still apply, pay a fee, and go through an interview. See the [http://www.tsa.gov/tsa-precheck TSA PreCheck] website for details.<br />
<br />
== Other countries' traveler programs ==<br />
* The UK's [https://www.gov.uk/registered-traveller Registered Traveller service] enables certain citizens of Australia, Canada, Japan, New Zealand and the USA to get faster entry to the UK, without filling out a landing card. <br />
<br />
<br />
Still to write:<br />
* priority security lanes<br />
* being nice to security<br />
* priority boarding (travel with a colleague who has priority status as their guest if you don't have it yourself)<br />
* lounges<br />
* watch your crew<br />
<br />
= Flying =<br />
<br />
'''Quick Tips'''<br />
* Hydrate, hydrate, hydrate. Air in an airplane at altitude is incredibly dry and dries you out. Drink water whenever you can. Bring an empty water bottle (even better: collapsible) and fill it from a water fountain inside security. (Some airports, like SFO, have water bottle filling spots that make this a little easier.) Don't drink the water that comes out of the water tanks onboard an airplane, including coffee and tea; you don't want to know how disgusting those tanks are. If you get water in the beverage service, ask for fizzy water (club soda) to ensure it came out of a bottle or can. If you need to brush your teeth in-flight, use water from your water bottle, not the tap in the toilet.<br />
* Request an alternate meal (kosher, indian, vegan, whatever) - they tend to be tastier, and often come first. (However, the downside to the meal coming first is that the tray is going to be in your way substantially longer.)<br />
* If you're in an aisle seat, you’ll find that the aisle-side armrest won’t lift. This is annoying, because it is much easier to deplane with that thing out of the way. Reach back to where the armrest joins the back of the chair -- there may be a release latch or button. (This works on some Boeing 777s; most smaller craft do not have this feature. See [http://brokensecrets.com/2011/01/17/raising-the-airplane-aisle-armrest/ this article] for a photo.)<br />
* Always wear shoes before going to the airplane lavatories; never go barefoot or wearing socks only. <br />
<br />
== Headphones ==<br />
Enjoying music or movies during travel is much better with headphones designed for travel use. You need to consider three types: <br />
* active noise-cancelling headphones<br />
* those without noise-cancellation<br />
* in-ear monitors. <br />
Generally speaking, on airplanes, active noise-cancellation will be better on the plane but worse when you're not on the plane (in the hotel room, for instance.) A quality headphone without noise cancellation will almost always sound better when not on an airplane. In-ear monitors allow for excellent sound quality and also allow one to rest your head on a pillow without the headphone pushing against one's ear, but some are uncomfortable with putting anything in one's ear. In-ear monitors are also much more compact. For those who want the sound quality of in-ear monitors and the compactness, but find that fit is a problem, consider Comply foam tip replacements which can be selected to fit your ear size.<br />
<br />
* For active noise cancellation headphones, the Bose Quiet Comfort 15 is the most popular model sold and for good reason. However if you want the headphone to be good when the noise-cancellation is turned off, you may want to consider the [http://www.psbspeakers.com/products/headphones/M4U-2-Headphones Psb m4u 2], which is more expensive but also more versatile.<br />
* For headphones without active noise cancellation, consider rugged models that have reputations burnished by decades of use by audio professionals such as the Sennheiser HD-25 1-ii. Another popular option is the V-Moda M-80 which has similar sound quality, has a good reputation for build quality, and also comes with a nice travel case.<br />
* For in ear monitors, there are too many to list but one line that is very popular is the Shure SE series which have models from $99 on up. These are very rugged models which allow for replaceable cables, replaceable tips and have very good sound quality.<br />
Additional resources for headphones include [http://www.innerfidelity.com/content/innerfidelitys-wall-fame Innerfidelity's Wall of Fame] and Head-fi.org's [http://www.head-fi.org/t/618255/check-out-the-head-fi-summer-2012-buying-guide 2012 Summer Buying Guide].<br />
<br />
== Make friends with TSA and your flight crew ==<br />
<br />
Airplanes are a sea of grumpy, tired, unhappy people. A little friendliness goes a long way -- especially if you're regularly flying the same route with the same flight crew.<br />
<br />
== Seat etiquette ==<br />
The following tips are about showing consideration to your fellow passengers, who unfortunately may not even notice it. But violating these norms is likely to cause annoyance. You don't want to be "that guy", do you?<br />
<br />
* The person in the middle seats gets to use both armrests. The people in the window and aisle seats get a little extra space, so yielding one armrest each is the least they can do. In any case, try to keep your elbows in your own space.<br />
* Consider the person behind you before reclining your seat into their space, especially if they are trying to eat or use a laptop. Avoid reclining abruptly (though it's not always possible to control this). Raise your seat back during meals.<br />
* If you need to leave your seat during the flight, try to avoid hoisting yourself up by yanking on the seat in front of you. This may be difficult to avoid if the seat is reclined (see above).<br />
* If you have an individual touchscreen in the seat back in front of you, jabbing it forcefully doesn't make the touchscreen work any better. If it's really not responding to touch input, try controlling it from the armrest controls.<br />
<br />
* [http://www.independenttraveler.com/travel-tips/travelers-ed/the-etiquette-of-seat-backs-and-elbow-room The Independent Traveler: The etiquette of seat backs and elbow room]<br />
<br />
<br />
<br />
Still to write:<br />
* how to sleep (Needs to be written by someone who is actually able to sleep on planes)<br />
** [http://gizmodo.com/how-to-get-the-best-sleep-of-your-life-on-an-airplane-1598708044 Gizmodo: How to get the best sleep of your life on an airplane]<br />
** [http://www.independenttraveler.com/travel-tips/travelers-ed/sleeping-on-planes Independent Traveler: Sleeping on Planes]<br />
* move on long flights<br />
<br />
= Tips for specific airports =<br />
As a general rule of thumb, in any airport, the terminal or concourse that serves international flights has nicer shops and restaurants than the areas for domestic flights. So, if you're traveling domestically, have time to kill, and can get into the international terminal without going through passport control, you might want to go hang out there.<br />
<br />
== AMS Amsterdam ==<br />
* in the international section (only?), there are nice quiet places to sit on the upper level outside the lounges (even if you don't have lounge access)<br />
* if you want to take the train to/from the airport, hoard coins (€4 to Amsterdam-Centraal, less to Amsterdam-Lelylaan or Amsterdam Zuid), since the ticket machines don't take bills or American credit cards. (The city trams/buses in Amsterdam do take bills, but this is a national train.)<br />
* note that the entirety of the outside-[https://en.wikipedia.org/wiki/Schengen_Area Schengen]-immigration part of the airport does security at the gate, per flight<br />
<br />
== AUS Austin, Texas ==<br />
The food available in the airport is actually pretty good, since most of the food concessions offer menus from local restaurants. Get to the airport early enough to have a last plate of barbecue or breakfast tacos. <br />
<br />
Another reason to get to the airport early is the "Knot Anymore" chair massages available near gates 13 and 7. Austin is awash in good massage therapists, so the ones working in the airport are far better than most airport massage services.<br />
<br />
== CDG Paris / Charles de Gaulle ==<br />
* CDG airport has multiple airport hotels on premises (on the around-the-airport CDGVal shuttle train); typically at least one of the fancy ones has good prices because it isn't hosting a conference that week, but there's also an Ibis. <br />
* CDG airport has four disconnected parts:<br />
** Terminal 1 (the cylinder with pods) (United is here)<br />
** Terminal 3 (the discount airlines)<br />
** Terminal 2A-2B-2C-2D-2E-2F (the bulk of the airport) (Air France is here)<br />
*** note that there are two satellite piers attached by train (outside immigration but not inside security) attached to Terminal 2E (the attached part of terminal 2E is called K, the satellites are called L and M)<br />
** Terminal 2G<br />
* transport<br />
** there's a train (CDGVal) connecting Terminal 1, Terminal 3 / Roissypole (where most but not all of the hotels are), and Terminal 2 (the station is between 2C/2D/2E/2F)<br />
** high speed trains stop only at the terminal 2 station (between 2C/2D/2E/2F)<br />
** RER trains (Paris's suburban rail network) stop at Terminal 2 (same station, again) and at "Terminal 1" (which is actually the Terminal 3 / Roissypole station for CDGVal)<br />
** Terminal 2G is reachable only by shuttle (I think, never done it)<br />
** If you want to take the RER to/from the airport, hoard coins in advance to pay the €9.50, since foreign cards don't work, and the machines don't take bills. <br />
** The RoissyBus is only €10.50 and runs nonstop between CDG and the Paris Opera, only a few blocks from the Mozilla Paris office. Look for signs for "RoissyBus" or "Paris by bus" within each terminal to find the bus stop.<br />
<br />
== JFK New York ==<br />
* The wifi password of the British Airways' lounge is "London" (according to Reddit). You can usually get in range of the wifi hotspot without going inside the lounge.<br />
<br />
== LHR London Heathrow ==<br />
* Terminal 5 (international) <br />
** If you need to take the train to concourse B or C, go to the far end of the platform. You'll bypass the crowds at the near end, and be closest to the escalators when you exit.<br />
** If you need to backtrack from concourses B or C to concourse A, ''don't'' take the train; you'll be routed through security again. There's a pedestrian tunnel that parallels the train, and comes out next to elevators that let out inside security in concourse A. The tunnel doors are marked "Emergency Exit", but do not have alarms, and in fact open automatically, to accommodate mobility-assistance carts. Stay to the left (remember: you're in England) to keep from being run over by them.<br />
** If you're going to the Mozilla London office, [[London#From_Heathrow_by_traincheck the directions]] and don't bother with Heathrow Express.<br />
<br />
== NCE Nice, France ==<br />
* if you have a really early flight, there are multiple decent airport hotels nearby. But do '''not''', under any circumstances, stay at the Etap.<br />
* if you want to avoid a really early flight, consider as an alternative doing an overnight layover at CDG, which has multiple airport hotels walking distance from Terminal 1 (but poorly signed). Make sure your layover is long enough, though.<br />
* if you're traveling to west of the airport (e.g., towards W3C's European offices near Antibes) and want to take public transit, it's possible to walk to the Nice - St. Augustin train station ('''not''' the main Nice - Ville train station) in about 15-20 minutes, but there's basically no signage. But definitely look at the train schedules before trying this. Buses from the bus station (gare routière) at the airport may be better.<br />
* there's a free shuttle between Terminals 1 and 2. Don't try walking between terminals.<br />
* There are bus stations at both terminals, but some bus routes stop at both terminal and some stop only at Terminal 1. You need to buy a ticket at the station before boarding.<br />
* the airport does not have water fountains behind security. But restaurants will probably be willing to fill up a water bottle for you, especially if you've bought something there.<br />
<br />
== NRT Tokyo/Narita ==<br />
* If you can do so just as easily, fly to Haneda Airport (HND) instead, which is closer to the city.<br />
* Don't even ''think'' of taking a taxi. It will take hours, and cost multiple hundreds of US dollars.<br />
* Two companies (JR and Keisei) run trains to Tokyo, and both have express and local services at different prices. Choices depend on where in Tokyo you're going. Google Maps might be helpful, or just figure it out when you get there.<br />
* Consider taking a [http://www.limousinebus.co.jp/en/ Limousine Bus] to somewhere close to your destination, and take a taxi from there.<br />
<br />
== ORD Chicago O'Hare ==<br />
* In Terminal 3, at the beginning of concourse G, there is a "Chicago Urban Garden" on the second floor, with aeroponic herbs and vegetables. This is a nice quiet place to wait if you don't have access to an airline lounge. <br />
<br />
== SFO San Francisco ==<br />
* if you're through security and looking for food, realize that some pairs of terminals are connected behind security. In particular, there are four separated behind-security zones at SFO right now: International-G/Terminal3-F/Terminal3-E, Terminal2-D/Terminal1-C, Terminal1-B, and International-A. In particular, if you're in C, you can probably find better food and better places to sit in D, and at some hours there's not much open in G, but you can head over to F.<br />
* The recently renovated terminal areas are the International Terminal (2000), Terminal 2 (gates D) (2011), and Terminal 3 gates E only (2014)<br />
* If you're taking BART to the airport, you can take the airtrain or walk to get around the airport from the airport BART station. You should definitely walk to International (G or A, which share a large central checkin hall but have separate gate areas), maybe walk to Terminal 3 (at least if you're ready to go straight to the security line), and you can walk to the other terminal if you like.<br />
<br />
== SJC San Jose CA ==<br />
<br />
== TPE Taipei Taoyuan ==<br />
* if you're coming from within Asia to Taipei, fly to Songshan Airport (TSA) instead<br />
* if you have Star Alliance gold, there are multiple EVA lounges to choose from. The main one, with all the good food, is on the same side of the open (to the floor below) space as the tropical bar one, with entrance across the hallway from it (not across the open space)<br />
<br />
== YVR Vancouver ==<br />
* As airports go this one is a pretty beautiful. If you're departing to the US from Vancouver note that you will go through US customs and immigration at YVR, so arrive 2 hours before your scheduled departure time. <br />
<br />
= Hotels =<br />
<br />
'''Quick Tips'''<br />
* Ask for upgrades. I know, this sounds trite, but it works. If you don’t know how that works, just remember, when checking in, to ask “Is there a better room available?” If they say yes, you’re set. If they say no, that’s fine. If they say “yes, for a price” then you can consider that price and make the call. We’ve gotten $2000/night rooms on a $180/night booking just by asking. This tends to work well when the hotel has a lot of open inventory (particularly effective in LAS, less effective near Moscone during a conference).<br />
* When checking in, adjust your interactions with the clerk based on whether they smile when you approach. Chit-chat with a smiling clerk, but not with an unsmiling clerk. The latter is just as much a form of establishing rapport as chit-chat, because you're not wasting the time of a transaction-oriented person. And establishing rapport can make the marginal difference in whether they decide to give you an upgrade.<br />
* Expensive hotels tend to have sensors in the minibars, but most of the rest still just have housekeeping track what’s missing each visit and bill you. If you do get the munchies, just head out to a convenience store the next day before housekeeping and buy matching replacements at the saner price. <br />
* You can avoid the minibar entirely by grabbing a granola bar or two from a Mozilla kitchen before departing. They are bound to be healthier than anything you find in the minibar late night. <br />
* Every hotel has a bucket of standard toiletry items (toothbrush, razor, &c). You should have a toiletry bag stocked and ready to go (see above) but if you find yourself missing something, just call the front desk.<br />
* Likewise, every hotel has a bucket of left-behind chargers/power cables.<br />
* Set your climate controls when you first get into the room. Forgetting until you come back after dinner ready for sleep and finding the room is hot and stale is no fun.<br />
* Some hotels won’t let the climate controls work unless your room keycard is stuck into a switch by the door. This isn’t a magstripe reader, it’s just a physical switch - use a business card or a folded up piece of paper (or your library card) and have your room the way you want it.<br />
* If the drapes that don't quite meet, and therefore let in unwanted sunlight or street light, use one or two big binder clips to keep the drapes closed.<br />
* You can usually get a later check-out time just by asking. This doesn't work indefinitely, but they can't clean every room at once, so asking for 1pm instead of 11am just means they move your room to the bottom of the list for cleaning that day.<br />
* Repack for departure before you go to sleep, except for the clothes and toiletries you'll need in the morning. That way, if you oversleep for whatever reason, you can throw on your clothes, grab those last items, and go without wasting any more time.<br />
* To avoid leaving things behind:<br />
** Bring your original packing checklist, and use it to repack.<br />
** Pull all the linens off the bed and throw all used towels into the shower, so you're sure nothing's hidden, and check every wall socket for chargers.<br />
** If you unpack into drawers, check every drawer before you leave.<br />
<br />
== Pick a hotel, get into the frequent guest program ==<br />
<br />
Same deal as airlines. At the least, it eventually adds up to free stays, but getting to status means room upgrades, easier check-in, more flexibility on check-in/check-out times, and extra points for each stay. Some hotel loyalty points can also be transferred to airline loyalty programs.<br />
<br />
It can be harder to consistently stay with the same hotel group than to consistently fly the same airline (they're sold out or not convenient, the conference hotel is elsewhere, etc.). However, it's good to join the loyalty program for any hotel you stay at, before you make your reservation. You may get a better rate or a better room. Hotel staff seem to give an extra measure of courtesy and consideration when you're in the loyalty program. (When booking by phone, I've had a "sold out" group rate suddenly become available when I gave my membership number.) If you haven't joined by the time you check in, ask the clerk to sign you up; they'll get credit for signing you up, and will be even more inclined to treat you nicely.<br />
<br />
Linked below are the programs associated with the hotels that are typically used for visiting Mozilla in Mountain View.<br />
<br />
{|<br />
|-<br />
|Holiday Inn Express<br />
|[http://www.priorityclub.com/ Priority Club]<br />
|<br />
|-<br />
|Avante/Wild Palms<br />
|[http://www.joyoflifeclub.com/ Joy of Life Club]<br />
|(Does not give points for stays that are paid through corporate billing.)<br />
|}<br />
<br />
== Choose Your Room ==<br />
<br />
It's a good practice to indicate that you have any preference on your room at all. Put this into your loyalty program profile and your travel agency profile (Egencia, for Mozilla employees), so it's transmitted with your reservation. If you have no preference, they will put you in the room for people who do not indicate a preference. You know, the one in the basement. With the leaky faucet and carpet from 1973. <br />
<br />
If you have a choice between one or two beds, choose two, even though you'll only use one for sleeping. The other one makes a great surface for spreading out your stuff. Often, hotel beds are on casters, so you can shove the extra bed against the wall, to prevent stuff falling between the bed and the wall.<br />
<br />
Generally, you'll do well to ask for a high floor and a room away from the elevator. Many hotels do renovations by floor starting from the top and working their way down. So high floors have a better chance of being recently renovated. They are also further away from street noise or the bar in the atrium. A room away from the elevator means less foot traffic and not waking up at 5am to repeated "ding!" of the elevator door opening. For motels, you want upstairs (less foot traffic) and outside (away from the courtyard with the pool).<br />
<br />
If the room is awful, don't be afraid to walk back downstairs and see if they have anything a bit more updated. If the whole hotel is awful, check your luggage at the desk and walk in a square block radius around the hotel to see if there's something less frightening. <br />
<br />
Never pick a hotel based on a picture of the lobby. Lobbies are always the first thing to get renovated.<br />
<br />
== Tipping Hotel Staff ==<br />
If you believe in tipping (which varies across cultures):<br />
* If you take a hotel shuttle from the airport, be sure to tip the shuttle driver. Don't just hand it to them and walk away; look them in the eye and express genuine appreciation for their service while you give them the tip. This is your first contact with the hotel staff, and if you make a good impression, word will spread to the other staff, and you'll get great service throughout your stay. This driver may also be the person who gets you to your outbound flight, through heavy traffic, just in the nick of time.<br />
* Similarly, leave a tip for housekeeping after the first night. This paves the way for good service when you make special requests, such as extra towels or toiletries, or to come back later because you're still in the room. Leave the money on top of a note that says at least "Thanks!" so the housekeeper knows it's for them.<br />
<br />
= Money =<br />
<br />
* Exchange: Do not change money at the airport. The rates are higher there than anywhere else. If you have a local bureau de change, use that, or order currency online for pickup at the airport. If you can find a company that does that (Travelex in the UK, at least) the rates will be much better than those posted on the wall that they charge you when you are a captive customer. The best rates are likely to be had by using an ATM. <br />
* Debit: Using an ATM card can be an easy and inexpensive way to secure some local currency. Make sure your card will work abroad before you travel. Common ATM networks that are broadly available include Pulse and Plus. Consider getting a debit card with no foreign transaction fees (Charles Schwab offers one).<br />
* Stay organized: It's helpful to keep your currency separate from your home currency, particularly if you're going to cycle through multiple currencies during your trip (usd > euro > pounds). Don't underestimate the power of a ziploc baggie if you're American and unaccustomed to coinage-heavy currencies.<br />
<br />
== Credit cards ==<br />
The US has historically had a different system (magnetic strips) for credit card security from the rest of the world (which uses the chip-and-pin system). This can cause headaches for both Americans traveling abroad, and others traveling to the US, as the systems are incompatible. Most US stores now support chip-and-signature cards, but you might run into smaller ones that don't have chip-reading equipment (e.g., a food truck using Square). <br />
<br />
* A very few US banks offer true chip-and-pin cards, including Citibank and [https://www.andrewsfcu.org/credit_cards_and_loans/credit_cards/globetrek_rewards.html Andrews Federal Credit Union]. The latter also has no annual fee and no international transaction fees. See this extensive but not exhaustive [http://thepointsguy.com/2013/05/us-credit-cards-with-smart-chips/ list of US-based chip-and-pin cards]. <br />
* You can get a pre-paid, reloadable chip-and-pin card called [http://www.cashpassport.com/1/travelex/ "Cash Passport"] from Travelex. You can buy it and reload it online or at Travelex locations in the US. You can load it in multiple currencies: GBP, EUR, CAD, AUD and JPY. The security seems a bit crappy (you can't change the PIN, and their only security question is mother's maiden name), but since it's pre-paid, you can limit your financial exposure, and reload online as needed.<br />
<br />
Another issue for travelers is transaction fees when making purchases in currencies other than your home currency; these can range from 1% up to as much as 7%. US-based credit cards that don't charge international transaction fees include CapitalOne and Andrews FCU.<br />
<br />
More and more US retailers have card readers that accept chip-based cards, so the situation is improving for visitors to the US. However, they probably don't understand the PIN system, so you will still need to sign (either on the reader, or on paper).<br />
<br />
= Preparing to be less-online than normal =<br />
<br />
If your cellphone plan doesn't have reasonable data roaming, or if you might be in areas with poor cell coverage, you should be prepared to survive without your usual data connection. This might include things like:<br />
* downloading offline maps in advance. ([http://maps.me/ maps.me] for Android and iOS lets you download offline OpenStreetMap maps by country or part-of-country.)<br />
* knowing where you're going to need to be (hotels, meeting locations) before you leave<br />
<br />
= On Foreign Soil =<br />
<br />
* Data/Voice rates<br />
** You can use Skype to call US 1-800 numbers toll free from anywhere in the world.<br />
** Before you leave your home country, add $20-40 of SkypeOut credits to your account. While Skype to Skype calls are free, SkypeOut credits will let you call any number internationally for about $.02 per minute.<br />
** International text messages are typically NOT covered under your mobile plan. For US cell plans, it's usually about $.50 per SMS. If you have a good international rate, think long and hard about when you use SMS and why. A conversation about when you landed and where to meet and what time to get there on SMS may be more than a 2 minute call that covers the same details.<br />
** [http://readwrite.com/2014/06/17/5-secrets-avoiding-hefty-international-data-roaming-charges-fees 5 secrets to avoiding hefty international data roaming fees] <br />
* Finding wifi<br />
** In airports, airlines' priority lounges often have no wifi password, and you can access their hotspots from outside the lounge. (See note above for JFK airport.)<br />
** Starbucks, McDonalds, and Burger King are sadly ubiquitous, and often have free wifi.<br />
** You can sometimes find the password for a business's wifi in the comments for that business on FourSquare.<br />
* Language barriers<br />
** Grab some business cards or stationery with your hotel's address on them before you head out. You can hand one to a cabbie whose language you do not speak, to get yourself back to home base. <br />
<br />
Still to write/update:<br />
* Language barriers<br />
** Add Line2 details...<br />
<br />
==Coping with jet lag==<br />
* Do not go to sleep. Do not nap. Stay up as long as you possibly can. Eat meals at local times and get into bed when it's dark outside. It will hurt on day one but by day three, you'll be glad you did. <br />
* If you absolutely must sleep, do a 20 minute powernap and then get up, walk around, and do not fall back to sleep. (Powernapping pro tip: drink a cup of coffee, and ''then'' take a nap; the coffee will wake you up in a short while.) <br />
* In a pinch, Benedryl (dipenhydramine) can help you reset your internal clock and it's substantially gentler on your system than the prescription sleep aids. (It's also good for nausea if you get motion sickness, and of course, allergic reactions.)<br />
* If you find yourself awake when you should be sleeping (by local time), avoid bright screens (computers, phones, e-readers), because they activate wakefulness in your brain. Try reading a paper book or magazine (radical, I know). If you must use a screen, set it to white text on a black background, to reduce the overall brightness; or get an app (such as [https://justgetflux.com/ f.lux] for Mac/iOS or [https://play.google.com/store/apps/details?id=com.urbandroid.lux Twilight] for Android) that reduces the amount of blue light emitted by your device at night.<br />
* If possible, follow the [http://www.wikihow.com/Prevent-Jet-Lag-with-a-Modified-Diet Anti-Jet Lag Diet]; this is easier to do at home than while traveling, but IME even an approximation helps. <br />
** As an abbreviated version: eat as little as possible on your day of travel, avoiding caffeine and alcohol; eat a high-protein breakfast at breakfast time in your new time zone.<br />
** Bring protein bars with you to ensure that you can get protein at the right time.<br />
<br />
= Transportation =<br />
<br />
'''Quick Tips'''<br />
* Talk to cabbies. Not only do they know their city, they are less likely to have kickbacks in place than the hotel concierge, more likely to give you good answers.<br />
* Learn the taxi rules. Las Vegas doesn’t let you hail cabs on the street (creates traffic problems). New York cabs have credit card swipes in the back seat, whereas DC cabs just started actually using their meters at all. San Francisco cabs won’t let you exit except curbside.<br />
<br />
Still to write:<br />
* public transit<br />
* hotel shuttles<br />
<br />
== Rental Cars ==<br />
<br />
=== Enterprise Rent-a-Car ===<br />
<br />
Mozilla's preferred vendor<br />
<br />
=== Hertz ===<br />
<br />
If for some reason you end up with Hertz (late evening arrivals mean Enterprise might be closed) you'll want to sign up for [[HertzBusinessAccountProgram|Hertz #1 Gold]] and use that. At most airports, you walk in, your name is on a board with a parking spot number, and the keys and contract are already in the car waiting for you. Really nice after a 5+ hour flight!<br />
<br />
= Eating =<br />
<br />
Eat like a local.<br />
<br />
Never ask the front desk at your hotel for a dinner recommendation. If possible, ask anyone else to weigh in. The bellhop, your taxi driver, the barista at Starbucks, Yelp, Chowhound, etc. The best recommendations come from people who are actually living and working in the area. (TripAdvisor tells you what people who ''don't'' live there think.) The concierge at the hotel will always orient toward broad, tourist-pacifying tastes. The food will be edible, but forgettable. They'll never tell you about the super tasty hole-in-the-wall joint three blocks away.<br />
<br />
= Staying healthy =<br />
* Wash hands frequently! <br />
* Carry and use hand-sanitizer wipes. (A bottle of hand-sanitizer gel takes up valuable room in your liquids bag.) Sanitize your hands in-flight before you eat or drink, and after washing your hands in the lavatory (on-board water, again). Also use them to wipe off [http://www.travelmath.com/feature/airline-hygiene-exposed/ tray tables, seatbelt buckles, and air vents], where germs lurk on airplanes.<br />
* Set the fan above your seat on the plane to low or medium, and position it to blow into your lap, just in front of your face. This will help knock airborne pathogens out of the air, so you'll be less likely to breathe them in. ([http://www.npr.org/blogs/goatsandsoda/2014/07/14/319194689/pathogens-on-a-plane-how-to-stay-healthy-in-flight?ft=1 (NPR) Pathogens on a plane: how to stay healthy in flight])<br />
* Keep your exercise routine as much as possible. Exercise burns calories, relieves stress, and helps reset your body clock, if you're in a different time zone.<br />
** Pick a hotel that has a fitness center. If you must use a hotel that doesn't have one (or you need specific equipment, like a stationary bike) call and ask; they may have an arrangement with a nearby gym.<br />
** If you're out of luck on the fitness center, bring an exercise DVD, and/or small lightweight equipment like a jump rope or tension bands. Or do a [http://well.blogs.nytimes.com/2013/05/09/the-scientific-7-minute-workout/ body-weight-only exercise routine].<br />
** Bring quick-drying workout clothes. Rinse them in the shower, and dry them over the shower rod, so they're ready for tomorrow.<br />
** Bring athletic shoes that double as casual street shoes, so you don't need to take up luggage space with extra shoes.<br />
** See the Quartz [http://qz.com/287800/the-complete-guide-to-staying-in-shape-on-the-road/ Complete guide to staying in shape on the road].<br />
<br />
= Redux =<br />
<br />
'''Most people travel infrequently, and aren’t very skilled at it...'''<br />
* and there are a lot of people, so despite the infrequency of their travel, the Don’t Know path is very crowded<br />
* Businesses on the Don’t Know path have no loyalty to you (since infrequent travellers have no meaningful loyalty to them) so their main goal is to extract money from you immediately, even at the cost of the relationship<br />
* People on the Don’t Know path have to deal with the same Don’t Know problems every single day, which is exhausting and saps their empathy<br />
<br />
'''BUT - If you know what you’re doing...'''<br />
* You can shortcut around the Don’t Know path everywhere. Airports, Hotels, Restaurants<br />
* The businesses you deal with will view you as a regular, and want to keep you happy<br />
* The people you deal with will view you as a breath of fresh air, and feel understood, and be grateful and human in the ways that travel never is for others.<br />
<br />
= More advice =<br />
* [http://www.jonobacon.org/2016/08/10/the-bacon-travel-survival-guide/ Travel Survival Guide] by Jono Bacon<br />
* [http://christianheilmann.com/2014/02/16/how-i-save-money-when-traveling-for-work-san-franciscovalleyus/ How I save money when traveling for work] by Christian Heilmann<br />
<br />
These podcasts have some excellent advice on business travel:<br />
* [http://www.manager-tools.com/2009/07/airline-travel-basics-1-part-1 Airline Travel Basics, part 1]<br />
* [http://www.manager-tools.com/2009/08/airline-travel-basics-1-part-2 Airline Travel Basics, part 2]<br />
* [http://www.manager-tools.com/2008/08/business-travel-packing Business Travel Packing]<br />
* [http://www.manager-tools.com/2009/07/travel-airline-seats Travel - Airline Seats]<br />
<br />
The what and how of packing only a carry-on: [http://www.onebag.com/ Onebag.com]</div>Dbaronhttps://wiki.mozilla.org/index.php?title=Travel_Guide&diff=1202212Travel Guide2018-10-10T21:52:52Z<p>Dbaron: /* General advice */ transfers and immigration</p>
<hr />
<div>----<br />
:: This page was originally created on Mozilla's internal intranet. However, it contains lots of information that could be useful to Mozillians who travel to Mozilla events, or really, anyone who travels, period. The original page (and its history) disappeared when the intranet site was retired.<br />
----<br />
<br />
Travel doesn’t have to suck. In fact, there are probably relatively few parts of your life where optimizations can make such a difference. We (the authors) have millions of miles travelled between us.<br />
<br />
* We never lose our luggage.<br />
* We can get from the airport entrance to our gate in 7 minutes.<br />
* We get free booze at the airport, upgraded flights, nicer rooms in hotels.<br />
* We don’t eat crap on the road, indeed we often discover great restaurants.<br />
* We have secrets.<br />
<br />
Let us show you them.<br />
<br />
But first, '''the 3 simplest things you can do to make travel a lot better''':<br />
<br />
# Don’t check luggage<br />
# Check in online<br />
# Pick a Frequent Flyer program<br />
<br />
Do those three and you’re already in the 80th percentile for travel success. What follows below is travel ninjitsu.<br />
<br />
= Planning =<br />
<br />
== Quick Tips ==<br />
* Scan a copy of your passport and any other travel documents, and put them somewhere web accessible but password protected (like Dropbox or Google Drive). This is helpful for getting replacements, and for getting consular help in the meantime.<br />
* Let your credit card company know that you travel. Anti-fraud measures might lock your card the first time you use it on foreign soil, but they can flag your account so that doesn’t happen. This is no fun to discover after the fact.<br />
<br />
== Pick a Frequent Flyer Program ==<br />
<br />
Prices are generally going to be competitive, so figure out your most common trip(s) and figure out which airline/alliance is best for those. Use that group for everything. You can easily sign up for FF programs online, and add it to your travel agency profile (Egencia for Mozilla employees).<br />
<br />
Even if you travel rarely, you'll eventually accrue enough mileage for free travel, and having a FF number makes online check-in easier.<br />
<br />
If you travel often enough, though, (25k+/year on most airlines) you start earning preferred status. This is the difference between "scum" and "Yes sir right away sir." You have shorter lines for agents, shorter lines for security, you board first. You get access to elite lounges while you wait, and free upgrades to business class to make the trip more pleasant. These are little niceties, but they add up, and make travel much nicer. You can often share status with someone less privileged, which means your spouse likes traveling with you more, too.<br />
<br />
== Check In Online ==<br />
<br />
Every airline will let you check in online, usually 24 hours before your flight leaves. I know this will feel weird the first time, but it is an absolute necessity. With online check-in and no checked luggage, you can skip all the lines at the airport except security (and possibly customs/immigration).<br />
<br />
Checking in early may put you into a lower "group" for boarding (or at least not the suckiest, all-the-overhead-bins-are-full group). Check in as early as possible, even if you don't know how many bags you will check (correct answer: 0). You can always add (and pay for) checked bags when you get to the airport.<br />
<br />
The one '''exception''' to this guideline is that if you think your flight might be delayed or cancelled due to weather, ''don't'' check in online ahead of time. If you have to re-book, and you are already checked-in, the agent will have to "uncheck" you, which may slow down the re-booking process and cause you to miss out on alternate flight options. Keep in mind that weather problems cause ripple effects even in locations where weather is good. For example, your flight out of sunny Phoenix might be cancelled because the aircraft is grounded by a snowstorm in Chicago. (See this Egencia blog post for [http://info.egencia.com/wintertraveltips2014.html tips for avoiding weather delays].)<br />
<br />
Online check-in also lets you choose your seats, which brings us to...<br />
<br />
== Choose Your Seats ==<br />
<br />
* Take a window seat for very short flights or very long flights. Window seats have more shoulder room, less hassle from other passengers, and a window. The only downside is bladder management, but on short flights you can stick it out and on long ones you can get up when your fellow passengers do.<br />
* ''Every'' plane has some seats that suck. No recline, noisy, cold, lack of floor storage or slightly narrower than most, [http://www.seatguru.com SeatGuru] will tell you what to avoid. It'll also tell you which seats are great (extra legroom, etc) that you should take given half a chance. Usually, exit-row seats have extra legroom (good for tall people), and the last row and the row in front of the exit row do not recline (bad in general). The first row in a section (where you have a bulkhead in front of you instead of another seat) typically does not have under-seat storage, so everything must go in overhead bins, but it typically does have more legroom. (Seatguru will tell you whether or not this is the case on a particular plane.)<br />
* ''The Middle Seat Gambit'' - If you’re traveling with someone else, check in online together and look for an empty 3-person row. Take the aisle and window. Middle seats fill up last, there’s a decent chance the seat stays empty. If so, you have a lot more space to dump things during the flight, and more legroom since you can use that space instead of putting things under the seat in front of you.<br />
* If you’re traveling alone, you can still use the middle seat gambit by checking in online and looking at the seat map for someone acting as a de facto accomplice.<br />
* If there is only one (worst possible) seat left when you go to select seats, ''don't take it''. It will be claimed by someone else, and the gate agent will assign you a different seat. A flight that full might mean that someone gets bumped, but lack of a seat assignment doesn't guarantee it will be you.<br />
<br />
== Manage Layovers ==<br />
<br />
Flying nonstop to your destination is always easiest, but if that’s not a possibility for whatever reason, here are some other things to keep in mind:<br />
<br />
* Major metropolitan centers are often served by multiple airports, and each airline will have a preference. If you can’t get the flight you want with the airline you like, look to see whether you’re just pointing at the wrong airport.<br />
* If you can’t fly nonstop, you probably at least have your choice of connection airports, and the choice matters there. What’s more, a given airline will have certain preferred connection cities, so a couple trips should get you a reasonably complete list. (For example, connecting from Toronto to San Francisco on Star Alliance, it is much preferable to connect in Denver or Vancouver than it is to connect in Chicago O’Hare.) Consider the immigration/customs procedures of the country you're connecting in if it's separate from the origin or destination (e.g., prefer Vancouver over a US airport for connecting between Toronto and Auckland, since the US requires internationally-connecting passengers to go through immigration and customs).<br />
* If you have to have a connection, you might also have the opportunity to fly to a better airport (e.g., if you have to connect to Washington, DC, you are likely to be able to fly to DCA instead of IAD).<br />
* Take the season and likely weather into account when picking connecting airports; avoid snowy airports in winter, thunderstorm-y airports in summer.<br />
* If you have to layover overnight, prefer airports that have on-site hotels (and for god’s sake prefer Munich over Frankfurt).<br />
* If you’re crossing a border during your flight, it’s often preferable to layover in-country before crossing over. It means your first flight is domestic, so you can arrive later at the airport since there’s no immigration headache there. <br />
* Another reason not to check a bag is that when you have a connection after arriving in some countries (e.g., the USA, but not EU countries), you have to claim your bag, take it through customs (even though they rarely look at it), and then check it again for your connecting flight. More time and hassle.<br />
* Remember to account for boarding time when calculating layovers. If flight A arrives at 12:00 and flight B leaves at 1:00, you do not have an hour, you have about 20 minutes (because you need to get OFF of flight A once it arrives, transit to whichever gate/terminal flight B is in, and then be there for flight B '''boarding''', not flight B '''departure''').<br />
<br />
= Immigration and Customs =<br />
<br />
== General advice ==<br />
* Make sure you know what the requirements are for crossing all immigration and customs barriers before you do so. If you don't know what those requirements are, embassy or consulate websites are often useful, as are the US government's [http://travel.state.gov/content/passports/english/country.html country specific information] (though somewhat tending towards information useful to Americans).<br />
* Make sure you have any documentation needed in your carry-on luggage. When entering a country where you're not a citizen or resident, you should carry proof of onward travel, particularly if the reservation on which you're flying doesn't return you to your home country (e.g., because you're traveling on separate reservations).<br />
* If you're ''transferring'' in a country (or multi-country immigration zone) that's different from your origin or destination, figure out whether you'll need to deal with immigration there, and if so, what the rules are. This might vary depending on the airport, or in some cases even on which terminal you arrive at and depart from. (In the latter case, airport websites are often helpful.)<br />
<br />
== Country-specific notes ==<br />
<br />
=== USA ===<br />
* visitors under the [https://travel.state.gov/content/travel/en/us-visas/tourism-visit/visa-waiver-program.html visa waiver program] (those who don't need a visa) must apply online for an [http://www.cbp.gov/travel/international-visitors/esta ESTA].<br />
<br />
=== Canada ===<br />
* visitors who do not need a visa, are entering Canada by air, and are not US citizens or Canadian citizens or Canadian permanent residents, must apply online for an [http://www.cic.gc.ca/english/visit/eta.asp eTA].<br />
<br />
=== Schengen Area (Europe) ===<br />
* The [http://en.wikipedia.org/wiki/Schengen_Area Schengen Area] is an immigration-barrier-free zone covering most of the European Union and some additional non-EU countries, but not the UK or Ireland.<br />
* If you need a visa to visit the Schengen Area, it is easier to get such a visa if your point of arrival in the Schengen Area is the same country as your destination. (For example, if you're traveling to Spain, it is easier to arrive in Madrid after connecting in the UK or US than connecting via Amsterdam, since in the latter case getting the visa requires dealing with both the Spanish and Dutch authorities.)<br />
* If your nationality requires a visa to visit the Schengen Area and your trip does not terminate in Schengen, avoid making more than one connection in Schengen; in such a case you must get a Schengen visa, even though that's not your destination. Schengen immigration authorities look at your ''next'' point of travel (not your final one) to decide whether you need a visa; if it is Schengen, they will ask for one.<br />
<br />
=== New Zealand ===<br />
* Make sure to declare any shoes in your checked luggage. The authorities just want to look at them and maybe clean the dirt off for you, but they'll be upset if you don't declare them.<br />
* Don't even think about [http://www.nzherald.co.nz/nz/news/article.cfm?c_id=1&objectid=11404025 bringing fresh fruit] into New Zealand or you will get an instant fine.<br />
<br />
=== Australia ===<br />
* Visitors who can can enter without a visa must apply online for an [https://www.eta.immi.gov.au/ ETA].<br />
<br />
= Packing =<br />
<br />
'''Quick Tips'''<br />
* Have a toiletry bag that you keep stocked, rather than trying to remember to pack toothbrushes &c the day of. It doesn’t cost much to buy the duplicates once, and saves hassle/forgetting.<br />
* Put your favourite head, stomach, and sleep meds in the toiletry bag. You can buy most things on the road, but meds are sometimes an exception.<br />
* Throw a couple of large ziploc bags in there, too. They are immensely useful for storing wet clothing or leaking bottles or, by contrast, for putting things like passports in when you need them to stay dry. They weigh nothing and disappear into a pocket until needed.<br />
* Layers. You can adapt to a wide range of climates, even multi-city travel, by packing layers. Shirt, Sweater, Hoodie, Jacket is plenty warm, packs much more compactly than a parka, and gives you middle ground for an overwarm restaurant or an overcool office.<br />
* While you're packing, make a text list on your phone of everything you pack. Towards the end of your trip (such as waiting for your flight home), put a '+' next to every item you actually used. Next time, don't pack the things you didn't use. Also, if your bag goes missing, you have a list of what was in it.<br />
<br />
== Don’t Check Luggage ==<br />
<br />
:: Repeat after me: Checked luggage is for chumps.<br />
<br />
:: Again. Checked luggage is for chumps.<br />
<br />
:: -- George Clooney, ''Up in the Air''<br />
<br />
Every time you give your bag to the airlines, you're inviting them to lose it, abuse it, leave it in your departure city, forget about it on the tarmac during a rain delay, etc. North American airlines will allow you one carry on suitcase and one “personal bag” which usually means a purse or laptop. This is easily enough for a week of travel, and can be extended indefinitely with laundry service. Invest in a good carry-on and bring it with you.<br />
<br />
Put everything you need during the flight in your laptop bag, in case you have to gate-check your carry-on suitcase (common on short flights with smaller planes).<br />
<br />
== Choose the Right Luggage ==<br />
Checked luggage will inevitably be destroyed over time, regardless of quality. If you stick to carry on, though, good luggage will last forever; be willing to pay once for something that gets it right. Your happiness while traveling is worth it.<br />
<br />
His bias for non-rolling luggage notwithstanding, [http://www.onebag.com/bags.html this is the single best guide out there] for evaluating luggage. The highlights:<br />
<br />
* Lighter is better<br />
* Curvy designs rob you of packing volume, prefer right angles<br />
* Chain zippers are stronger than coil zippers (look for YKK as the brand of zipper)<br />
* Pocket design and positioning matters<br />
* So do tie-downs<br />
<br />
In truth, the best way to maximize quality while minimizing weight is to let go of the dependence on rolling bags. Soft-sided, non-wheeled bags are exceptionally light and versatile. [http://www.tombihn.com Tom Bihn] and [http://www.redoxx.com/ Red Oxx] are your best plays. Tom Bihn’s Aeronaut is is a full-sized carry-on that converts to a backpack for long walks across cobblestones/sprints to catch a connection/etc. The Red Oxx Air Boss was designed by the same guy who wrote the luggage-choosing guide above.<br />
<br />
If you're not ready to let go of wheeled bags, any manufacturer with a lifetime warranty is probably worth considering. These include:<br />
<br />
* [http://www.briggs-riley.com/ Briggs & Riley]<br />
* [http://www.travelpro.com Travelpro] ("the best" carry-on according to [http://thewirecutter.com/reviews/best-carry-on-luggage/ The Wirecutter])<br />
* Certain models of [http://shop.eaglecreek.com/lightweight-carry-on/l/111 Eagle Creek] (not all models have a lifetime warranty)<br />
<br />
Pay attention to the bag’s extensible arm: is it well constructed? What does it do to your interior space? 2 segments of extension or 3? Moving parts make everything more fragile -- if you are choosing moving parts in your luggage, they need to be brilliant.<br />
<br />
== Buy It There (BIT) ==<br />
<br />
Don’t try to anticipate every contingency and pack for it. You will bog yourself down with unnecessary cruft. Pack for what you ''know'' you’ll need, or at most what you reasonably expect to need the majority of the time. You can find contact solution, toothpaste, aspirin, and dental floss at almost any convenience store. For the rest, shove an extra $50 into a pocket somewhere and buy whatever you need there, if it comes up. <br />
<br />
(Good news: It comes up less often than you’d think.)<br />
<br />
BIT exceptions: <br />
There are some things you don't want to source while traveling - if you only use one specific brand of shampoo, conditioner, etc, transfer it to a small, travel-friendly bottle. Depending on where you're traveling BIT can be tough if you don't speak the language and are looking for something very specific (like Cipro in India or a flat iron in China). Goes without saying, but BIT does *not* apply to medications (remember that what requires a prescription varies by country, but you can apply it if you know that something can be bought without a prescription at your destination).<br />
<br />
=== Corollary: Wash It There ===<br />
If you’re gone for longer than a carry-on can reasonably contain (which is longer than you think), don’t fail over to multiple suitcases; just get things laundered partway through. Your hotel will offer laundry service, though it will be overpriced. Most of the time you’ll find a wash and fold place within walking distance or a service that does pick up and next day drop off.<br />
<br />
Also keep in mind that at most Mozilla or other geek events, you will probably acquire at least one or two t-shirts. You can bring one or two fewer shirts; if this guideline fails, wash one of the ones you brought.<br />
<br />
If you bring quick-drying underwear and socks, you can wash them in the sink or bathtub and dry them overnight on the towel rack (except in humid climates). You can skip bringing detergent by using the hotel's shampoo (as long as you don't mind your underwear smelling like "ginger lemongrass" or whatever); shampoo is just mild detergent. Check the plumbing before you fill the sink; some hotels don't install the lever for raising the plug. Before hanging items to dry, roll them in a towel and squeeze out excess moisture.<br />
<br />
== Counterpoint: The case for checking a suitcase ==<br />
A few heavy-traveling Mozillians are in the "checked bag" camp. Add your reasons for using this strategy here:<br />
* Problems with checked luggage are actually quite rare.<br />
* You don't have to schlep a roll-aboard through the airport with you, including squeezing it into tiny toilet stalls.<br />
* You can pack a few extra things that help you be more comfortable on an extended trip.<br />
* At least one airline (American) gives early boarding privileges (after Elite and Priority but before Zone 1) to passengers with no overhead baggage.<br />
* You aren't limited to 100ml bottles of liquid/gel/cream, and can bring home ''properly packed'' wine, booze, perfume, etc. (Wrap the bottle in at least two plastic bags and nestle it in the groove left by the extending handle, surrounded tightly by clothes.)<br />
* Having airline status often helps your bag appear on the belt faster. Also, if the final segment of your trip is an international arrival in the United States, you're unlikely to have to wait long for your bag, since all baggage goes to the same belt, so it gets there quickly.<br />
* TIP: Get a suitcase with four wheels. Baggage handlers can slide it across the floor of the cargo hold instead of tossing it, subjecting the suitcase and its contents to much less abuse. Anything that protrudes, like carry straps or zipper pulls, can get snagged and chewed up in baggage-handling equipment; go for streamlined.<br />
* TIP: Ask for your checked luggage to be marked "Fragile". It will be loaded on top of other bags, and usually be unloaded first.<br />
* TIP: If you check luggage, don't let your eyes off the bag until there's a tag on it, and if you can, check that the tag is correct (with your name and correct destination airport on it). One of the common reasons for lost/delayed luggage is getting the wrong tag on it right at the check-in desk.<br />
* TIP: Things to make sure are '''not''' in your checked bag: everything you need to get through customs and immigration and get to your final destination. Any electronics that might be stolen. Lithium-ion batteries (prohibited).<br />
<br />
Some airlines (particularly non-North American ones) have much lower limits for what you're allowed to carry on, so you'll have to check luggage anyway.<br />
<br />
Some airlines (e.g., Air France, KLM) will even want to weigh your carry-on bag (often although not reliably), and want it to be a weight that's lower than what it is with your laptop in it (e.g., 6kg, 8kg). Remember that your laptop often counts as a separate personal item and you can take it out of the bag before weighing.<br />
<br />
==Packing Techniques and Tools==<br />
Your strategy for how to put your stuff in your suitcase is very much a matter of personal preference, along with the type of travel you're doing (destination vs. touring) and the type of clothes you bring. Here are some ideas that may be helpful.<br />
<br />
* The [http://www.onebag.com/pack.html bundle method] is great for avoiding wrinkles, but it tends to require that you unbundle ''everything'' to get out any single thing.<br />
* It's extremely helpful to have some kind of containers to organize your stuff. Purpose-made packing "cubes" are great, but are absurdly expensive. You can get by with zip-top plastic bags if you don't travel often, or while you're waiting to find ready-made cubes on sale. <br />
* If you buy only one packing accessory, consider getting a [http://www.amazon.com/Eagle-Creek-Travel-Pack-It-Folder/dp/B002YIRC3O/ packing folder], which helps you fold larger items (shirts, pants, skirts) to a uniform footprint, and then encloses them like an envelope.<br />
* Compression bags, which let you squeeze all the air out of your clothes, are good only for clothes that don't easily wrinkle. However, a compression bag can be great as a laundry bag to minimize the volume of dirty clothes on your way home.<br />
<br />
= Airport Hacking =<br />
'''Quick Tips'''<br />
* ABC: Always Be Charging. Wherever you come to rest, be charging. Maybe your flight has power plugs, that's swell, but maybe they stop working, or your seatmate gets to it first, or you need it to charge your phone. If you're at rest for more than 10 minutes, find a plug. If you bring a power strip so others can plug in, too, you can make friends anywhere :-)<br />
* Watch where uniformed crew members go. They know the best eateries in any given airport, and even where to stand on the tram platform in order to get off quickly at the other end.<br />
* The internet knows about delays before your gate agents do. Bookmark [http://flightaware.com/live/ flightaware] right now, and use it from your phone at the airport to keep tabs. Caveat: Flightaware may show your flight as delayed because the inbound plane you're getting on is delayed; if the airline substitutes another aircraft, your flight could be on time or only a little delayed.<br />
* If you do see signs of a significant delay, particularly at night when it's likely you'll be put off until morning, act swiftly before the lines form. Talk to gate agents about rebooking onto other flights and if the line there is long, be on the phone with your airline as well. First to rebook means first to call hotels and taxis and all the rest. Being last to rebook means sleeping in the airport. If you have elite status, call the customer service number for elite members, not the general customer service number.<br />
* When you get off the plane, the restroom closest to your gate will be crowded with other people from your flight. Keep going to the next one further away.<br />
* No one wants to sleep in an airport, but flight delays or cancellations, or just poor planning, may require it. There is actually a whole website devoted to [http://www.sleepinginairports.net/tips.htm sleeping in airports].<br />
<br />
<br />
== Being prepared for security ==<br />
* Bring identification. [http://www.tsa.gov/traveler-information/acceptable-ids Here's a list of acceptable IDs] in the US. If you forget your ID, all is not lost. It's possible, with some extra hassle, to travel within the US even if you don't have your identification. [http://blog.tsa.gov/2013/04/tsa-travel-tips-tuesday-can-you-fly.html Here's what the TSA says to do if you don't have ID.]<br />
* Avoid getting into a screening line behind people who look like they don't travel often (families with kids, retirement-age folks, large groups).<br />
* Wear slip-on shoes (and wear socks if you don't want your feet getting dirty).<br />
* Consider not wearing a belt, or wear one with no metal, so you don't have to take it off.<br />
* Avoid clothes with extra pockets, like cargo pants. They can be flagged by the nudie-scan, and cause you to get a pat-down. Same for "travel" clothes with hidden pockets; these can be handy while touring, but not while flying. Even a hoodie can win you a pat-down for the hood and kangaroo pocket. <br />
* On the other hand, a jacket with lots of pockets is like an extra carry-on; you have to remove it for security anyway, and you can keep your in-flight necessities (gadgets, etc.) close to hand during your flight.<br />
* Know the drill with liquids, gels, and creams: containers at most 100ml/3oz, in a clear zip-top bag, 1 liter/1 quart size. Have this in an external pocket of your carry-on, ready to pull out and put in a bin. (If you travel often, you might want to get a sturdier bag than the grocery store kind. It must still be clear and zip-top.)<br />
* Avoid large metal jewelry.<br />
* Take everything, but especially metal (keys, coins, etc.), out of your pockets.<br />
* Leave your pocket knives and multitools at home.<br />
* If you're wearing an activity monitor, such as a FitBit, take it off for screening.<br />
* You should hang onto your ID and boarding pass as you go through the line, but you can't carry them through screening; put them in your bin.<br />
* Put the bin with your shoes, jacket, and liquids onto the conveyor belt first. You can be getting dressed while the rest of your stuff comes through.<br />
* Take your laptop out of your bag and put it in a separate bin. You can usually leave it in a sleeve, as long as there's nothing else in the sleeve. <br />
* Consider getting a checkpoint-friendly laptop bag, with a laptop-only section that folds out without taking out the computer. The less you handle your laptop, the less likely you are to drop it. (US TSA allows you leave the computer in this type of bag; other countries often do not.)<br />
* Don't go through the screening machine until your stuff is on the conveyor belt.<br />
<br />
== US Trusted Traveler Programs ==<br />
If you frequently cross US borders, you can save time and hassle in the long run by enrolling in one of the programs that provide expedited entry for pre-approved travelers. Enrolling involves an application fee and form, and an in-person interview at an entry point, so there is a start-up cost in time and money. Which program you should enroll in depends on the type of crossing you do most; you can enroll in more than one. <br />
<br />
* When entering the US, if you're not in a "trusted traveler" program, try to get into the immigration queue that is ''next to'' the Global Entry lane. If no one is in the Global Entry lane, the officer there will often take people from the nearby queue, making it move faster. Do likewise for NEXUS when entering Canada.<br />
* Wear Firefox gear when going through immigration, anywhere. It creates goodwill and starts pleasant conversations.<br />
<br />
===Automated Passport Control===<br />
Automated Passport Control kiosks are available to citizens of the US, Canada, and [http://www.cbp.gov/travel/international-visitors/frequently-asked-questions-about-visa-waiver-program-vwp-and-electronic-system-travel Visa Waiver Program] countries, for entry into the US, in an expanding number of North American cities. Unlike Global Entry or Nexus, these kiosks require no pre-registration. You swipe your passport, let the kiosk take a photo, answer some questions, and then get a receipt that you show to a Customs and Border Patrol officer. The kiosk replaces filling out a customs card by hand.<br />
<br />
See the [http://www.cbp.gov/travel/us-citizens/Automated%20Passport%20Control Automated Passport Control] webpage for a list of cities with APC kiosks.<br />
<br />
=== Global Entry ===<br />
[http://globalentry.gov/about.html Global Entry] provides expedited screening for entry ''into'' the US at certain airports. Once in the program, you can go to an automated kiosk instead of an immigration agent (skipping the enormous lines that result from multiple international flights arriving at about the same time), and you can answer the customs questions at the kiosk instead of filling out a paper form. Unless there is an issue with your kiosk interaction (such as it couldn't read your fingerprints), you don't need to talk to a CBP agent. Global Entry is open to U.S. citizens, lawful permanent residents of the U.S., Dutch citizens, South Korean citizens and Mexican nationals.<br />
<br />
=== NEXUS ===<br />
[http://www.globalentry.gov/nexus.html NEXUS] provides expedited screening for crossing the US-Canada border in both directions. It can be used at land and sea entry points as well as at airports. You can use the NEXUS-only lanes at land crossings only if every person in the vehicle (including children) has a NEXUS card. Using NEXUS at an airport requires scanning your irises. If you wear contact lenses, you must remove them for the initial iris scan that is taken after your enrollment interview.<br />
<br />
=== Other US programs ===<br />
* [http://www.globalentry.gov/netherlands.html FLUX] expedites passage between the US and '''the Netherlands''', and is open to US and Dutch citizens.<br />
* Global Entry members can receive expedited entry into '''[http://www.globalentry.gov/newzealand.html New Zealand]'''.<br />
* [http://www.globalentry.gov/sentri.html SENTRI] provides expedited entry into the US from '''Mexico''' at specific land crossings.<br />
* [http://www.globalentry.gov/korea.html Smart Entry Service] provides expedited entry into the Republic of '''Korea'''. It is open to US and Korean citizens.<br />
* [http://www.globalentry.gov/smartgate.html SmartGate] provides streamlined entry into '''Australia''' for US Global Entry members. Visa requirements still apply.<br />
* [http://www.globalentry.gov/tsa.html TSA PreCheck] enables US Global Entry and Canadian NEXUS members to use designated TSA airport screening lanes, without removing liquids, laptops, shoes, jackets, or belts. You must provide your membership number when booking flights with participating airlines. TSA is expanding the PreCheck program to include more people, including US military members and those invited by their airline's frequent flyer program. You must still apply, pay a fee, and go through an interview. See the [http://www.tsa.gov/tsa-precheck TSA PreCheck] website for details.<br />
<br />
== Other countries' traveler programs ==<br />
* The UK's [https://www.gov.uk/registered-traveller Registered Traveller service] enables certain citizens of Australia, Canada, Japan, New Zealand and the USA to get faster entry to the UK, without filling out a landing card. <br />
<br />
<br />
Still to write:<br />
* priority security lanes<br />
* being nice to security<br />
* priority boarding (travel with a colleague who has priority status as their guest if you don't have it yourself)<br />
* lounges<br />
* watch your crew<br />
<br />
= Flying =<br />
<br />
'''Quick Tips'''<br />
* Hydrate, hydrate, hydrate. Air in an airplane at altitude is incredibly dry and dries you out. Drink water whenever you can. Bring an empty water bottle (even better: collapsible) and fill it from a water fountain inside security. (Some airports, like SFO, have water bottle filling spots that make this a little easier.) Don't drink the water that comes out of the water tanks onboard an airplane, including coffee and tea; you don't want to know how disgusting those tanks are. If you get water in the beverage service, ask for fizzy water (club soda) to ensure it came out of a bottle or can. If you need to brush your teeth in-flight, use water from your water bottle, not the tap in the toilet.<br />
* Request an alternate meal (kosher, indian, vegan, whatever) - they tend to be tastier, and often come first. (However, the downside to the meal coming first is that the tray is going to be in your way substantially longer.)<br />
* If you're in an aisle seat, you’ll find that the aisle-side armrest won’t lift. This is annoying, because it is much easier to deplane with that thing out of the way. Reach back to where the armrest joins the back of the chair -- there may be a release latch or button. (This works on some Boeing 777s; most smaller craft do not have this feature. See [http://brokensecrets.com/2011/01/17/raising-the-airplane-aisle-armrest/ this article] for a photo.)<br />
* Always wear shoes before going to the airplane lavatories; never go barefoot or wearing socks only. <br />
<br />
== Headphones ==<br />
Enjoying music or movies during travel is much better with headphones designed for travel use. You need to consider three types: <br />
* active noise-cancelling headphones<br />
* those without noise-cancellation<br />
* in-ear monitors. <br />
Generally speaking, on airplanes, active noise-cancellation will be better on the plane but worse when you're not on the plane (in the hotel room, for instance.) A quality headphone without noise cancellation will almost always sound better when not on an airplane. In-ear monitors allow for excellent sound quality and also allow one to rest your head on a pillow without the headphone pushing against one's ear, but some are uncomfortable with putting anything in one's ear. In-ear monitors are also much more compact. For those who want the sound quality of in-ear monitors and the compactness, but find that fit is a problem, consider Comply foam tip replacements which can be selected to fit your ear size.<br />
<br />
* For active noise cancellation headphones, the Bose Quiet Comfort 15 is the most popular model sold and for good reason. However if you want the headphone to be good when the noise-cancellation is turned off, you may want to consider the [http://www.psbspeakers.com/products/headphones/M4U-2-Headphones Psb m4u 2], which is more expensive but also more versatile.<br />
* For headphones without active noise cancellation, consider rugged models that have reputations burnished by decades of use by audio professionals such as the Sennheiser HD-25 1-ii. Another popular option is the V-Moda M-80 which has similar sound quality, has a good reputation for build quality, and also comes with a nice travel case.<br />
* For in ear monitors, there are too many to list but one line that is very popular is the Shure SE series which have models from $99 on up. These are very rugged models which allow for replaceable cables, replaceable tips and have very good sound quality.<br />
Additional resources for headphones include [http://www.innerfidelity.com/content/innerfidelitys-wall-fame Innerfidelity's Wall of Fame] and Head-fi.org's [http://www.head-fi.org/t/618255/check-out-the-head-fi-summer-2012-buying-guide 2012 Summer Buying Guide].<br />
<br />
== Make friends with TSA and your flight crew ==<br />
<br />
Airplanes are a sea of grumpy, tired, unhappy people. A little friendliness goes a long way -- especially if you're regularly flying the same route with the same flight crew.<br />
<br />
== Seat etiquette ==<br />
The following tips are about showing consideration to your fellow passengers, who unfortunately may not even notice it. But violating these norms is likely to cause annoyance. You don't want to be "that guy", do you?<br />
<br />
* The person in the middle seats gets to use both armrests. The people in the window and aisle seats get a little extra space, so yielding one armrest each is the least they can do. In any case, try to keep your elbows in your own space.<br />
* Consider the person behind you before reclining your seat into their space, especially if they are trying to eat or use a laptop. Avoid reclining abruptly (though it's not always possible to control this). Raise your seat back during meals.<br />
* If you need to leave your seat during the flight, try to avoid hoisting yourself up by yanking on the seat in front of you. This may be difficult to avoid if the seat is reclined (see above).<br />
* If you have an individual touchscreen in the seat back in front of you, jabbing it forcefully doesn't make the touchscreen work any better. If it's really not responding to touch input, try controlling it from the armrest controls.<br />
<br />
* [http://www.independenttraveler.com/travel-tips/travelers-ed/the-etiquette-of-seat-backs-and-elbow-room The Independent Traveler: The etiquette of seat backs and elbow room]<br />
<br />
<br />
<br />
Still to write:<br />
* how to sleep (Needs to be written by someone who is actually able to sleep on planes)<br />
** [http://gizmodo.com/how-to-get-the-best-sleep-of-your-life-on-an-airplane-1598708044 Gizmodo: How to get the best sleep of your life on an airplane]<br />
** [http://www.independenttraveler.com/travel-tips/travelers-ed/sleeping-on-planes Independent Traveler: Sleeping on Planes]<br />
* move on long flights<br />
<br />
= Tips for specific airports =<br />
As a general rule of thumb, in any airport, the terminal or concourse that serves international flights has nicer shops and restaurants than the areas for domestic flights. So, if you're traveling domestically, have time to kill, and can get into the international terminal without going through passport control, you might want to go hang out there.<br />
<br />
== AMS Amsterdam ==<br />
* in the international section (only?), there are nice quiet places to sit on the upper level outside the lounges (even if you don't have lounge access)<br />
* if you want to take the train to/from the airport, hoard coins (€4 to Amsterdam-Centraal, less to Amsterdam-Lelylaan or Amsterdam Zuid), since the ticket machines don't take bills or American credit cards. (The city trams/buses in Amsterdam do take bills, but this is a national train.)<br />
* note that the entirety of the outside-[https://en.wikipedia.org/wiki/Schengen_Area Schengen]-immigration part of the airport does security at the gate, per flight<br />
<br />
== AUS Austin, Texas ==<br />
The food available in the airport is actually pretty good, since most of the food concessions offer menus from local restaurants. Get to the airport early enough to have a last plate of barbecue or breakfast tacos. <br />
<br />
Another reason to get to the airport early is the "Knot Anymore" chair massages available near gates 13 and 7. Austin is awash in good massage therapists, so the ones working in the airport are far better than most airport massage services.<br />
<br />
== CDG Paris / Charles de Gaulle ==<br />
* CDG airport has multiple airport hotels on premises (on the around-the-airport CDGVal shuttle train); typically at least one of the fancy ones has good prices because it isn't hosting a conference that week, but there's also an Ibis. <br />
* CDG airport has four disconnected parts:<br />
** Terminal 1 (the cylinder with pods) (United is here)<br />
** Terminal 3 (the discount airlines)<br />
** Terminal 2A-2B-2C-2D-2E-2F (the bulk of the airport) (Air France is here)<br />
*** note that there are two satellite piers attached by train (outside immigration but not inside security) attached to Terminal 2E (the attached part of terminal 2E is called K, the satellites are called L and M)<br />
** Terminal 2G<br />
* transport<br />
** there's a train (CDGVal) connecting Terminal 1, Terminal 3 / Roissypole (where most but not all of the hotels are), and Terminal 2 (the station is between 2C/2D/2E/2F)<br />
** high speed trains stop only at the terminal 2 station (between 2C/2D/2E/2F)<br />
** RER trains (Paris's suburban rail network) stop at Terminal 2 (same station, again) and at "Terminal 1" (which is actually the Terminal 3 / Roissypole station for CDGVal)<br />
** Terminal 2G is reachable only by shuttle (I think, never done it)<br />
** If you want to take the RER to/from the airport, hoard coins in advance to pay the €9.50, since foreign cards don't work, and the machines don't take bills. <br />
** The RoissyBus is only €10.50 and runs nonstop between CDG and the Paris Opera, only a few blocks from the Mozilla Paris office. Look for signs for "RoissyBus" or "Paris by bus" within each terminal to find the bus stop.<br />
<br />
== JFK New York ==<br />
* The wifi password of the British Airways' lounge is "London" (according to Reddit). You can usually get in range of the wifi hotspot without going inside the lounge.<br />
<br />
== LHR London Heathrow ==<br />
* Terminal 5 (international) <br />
** If you need to take the train to concourse B or C, go to the far end of the platform. You'll bypass the crowds at the near end, and be closest to the escalators when you exit.<br />
** If you need to backtrack from concourses B or C to concourse A, ''don't'' take the train; you'll be routed through security again. There's a pedestrian tunnel that parallels the train, and comes out next to elevators that let out inside security in concourse A. The tunnel doors are marked "Emergency Exit", but do not have alarms, and in fact open automatically, to accommodate mobility-assistance carts. Stay to the left (remember: you're in England) to keep from being run over by them.<br />
** If you're going to the Mozilla London office, [[London#From_Heathrow_by_traincheck the directions]] and don't bother with Heathrow Express.<br />
<br />
== NCE Nice, France ==<br />
* if you have a really early flight, there are multiple decent airport hotels nearby. But do '''not''', under any circumstances, stay at the Etap.<br />
* if you want to avoid a really early flight, consider as an alternative doing an overnight layover at CDG, which has multiple airport hotels walking distance from Terminal 1 (but poorly signed). Make sure your layover is long enough, though.<br />
* if you're traveling to west of the airport (e.g., towards W3C's European offices near Antibes) and want to take public transit, it's possible to walk to the Nice - St. Augustin train station ('''not''' the main Nice - Ville train station) in about 15-20 minutes, but there's basically no signage. But definitely look at the train schedules before trying this. Buses from the bus station (gare routière) at the airport may be better.<br />
* there's a free shuttle between Terminals 1 and 2. Don't try walking between terminals.<br />
* There are bus stations at both terminals, but some bus routes stop at both terminal and some stop only at Terminal 1. You need to buy a ticket at the station before boarding.<br />
* the airport does not have water fountains behind security. But restaurants will probably be willing to fill up a water bottle for you, especially if you've bought something there.<br />
<br />
== NRT Tokyo/Narita ==<br />
* If you can do so just as easily, fly to Haneda Airport (HND) instead, which is closer to the city.<br />
* Don't even ''think'' of taking a taxi. It will take hours, and cost multiple hundreds of US dollars.<br />
* Two companies (JR and Keisei) run trains to Tokyo, and both have express and local services at different prices. Choices depend on where in Tokyo you're going. Google Maps might be helpful, or just figure it out when you get there.<br />
* Consider taking a [http://www.limousinebus.co.jp/en/ Limousine Bus] to somewhere close to your destination, and take a taxi from there.<br />
<br />
== ORD Chicago O'Hare ==<br />
* In Terminal 3, at the beginning of concourse G, there is a "Chicago Urban Garden" on the second floor, with aeroponic herbs and vegetables. This is a nice quiet place to wait if you don't have access to an airline lounge. <br />
<br />
== SFO San Francisco ==<br />
* if you're through security and looking for food, realize that some pairs of terminals are connected behind security. In particular, there are four separated behind-security zones at SFO right now: International-G/Terminal3-F/Terminal3-E, Terminal2-D/Terminal1-C, Terminal1-B, and International-A. In particular, if you're in C, you can probably find better food and better places to sit in D, and at some hours there's not much open in G, but you can head over to F.<br />
* The recently renovated terminal areas are the International Terminal (2000), Terminal 2 (gates D) (2011), and Terminal 3 gates E only (2014)<br />
* If you're taking BART to the airport, you can take the airtrain or walk to get around the airport from the airport BART station. You should definitely walk to International (G or A, which share a large central checkin hall but have separate gate areas), maybe walk to Terminal 3 (at least if you're ready to go straight to the security line), and you can walk to the other terminal if you like.<br />
<br />
== SJC San Jose CA ==<br />
<br />
== TPE Taipei Taoyuan ==<br />
* if you're coming from within Asia to Taipei, fly to Songshan Airport (TSA) instead<br />
* if you have Star Alliance gold, there are multiple EVA lounges to choose from. The main one, with all the good food, is on the same side of the open (to the floor below) space as the tropical bar one, with entrance across the hallway from it (not across the open space)<br />
<br />
= Hotels =<br />
<br />
'''Quick Tips'''<br />
* Ask for upgrades. I know, this sounds trite, but it works. If you don’t know how that works, just remember, when checking in, to ask “Is there a better room available?” If they say yes, you’re set. If they say no, that’s fine. If they say “yes, for a price” then you can consider that price and make the call. We’ve gotten $2000/night rooms on a $180/night booking just by asking. This tends to work well when the hotel has a lot of open inventory (particularly effective in LAS, less effective near Moscone during a conference).<br />
* When checking in, adjust your interactions with the clerk based on whether they smile when you approach. Chit-chat with a smiling clerk, but not with an unsmiling clerk. The latter is just as much a form of establishing rapport as chit-chat, because you're not wasting the time of a transaction-oriented person. And establishing rapport can make the marginal difference in whether they decide to give you an upgrade.<br />
* Expensive hotels tend to have sensors in the minibars, but most of the rest still just have housekeeping track what’s missing each visit and bill you. If you do get the munchies, just head out to a convenience store the next day before housekeeping and buy matching replacements at the saner price. <br />
* You can avoid the minibar entirely by grabbing a granola bar or two from a Mozilla kitchen before departing. They are bound to be healthier than anything you find in the minibar late night. <br />
* Every hotel has a bucket of standard toiletry items (toothbrush, razor, &c). You should have a toiletry bag stocked and ready to go (see above) but if you find yourself missing something, just call the front desk.<br />
* Likewise, every hotel has a bucket of left-behind chargers/power cables.<br />
* Set your climate controls when you first get into the room. Forgetting until you come back after dinner ready for sleep and finding the room is hot and stale is no fun.<br />
* Some hotels won’t let the climate controls work unless your room keycard is stuck into a switch by the door. This isn’t a magstripe reader, it’s just a physical switch - use a business card or a folded up piece of paper (or your library card) and have your room the way you want it.<br />
* If the drapes that don't quite meet, and therefore let in unwanted sunlight or street light, use one or two big binder clips to keep the drapes closed.<br />
* You can usually get a later check-out time just by asking. This doesn't work indefinitely, but they can't clean every room at once, so asking for 1pm instead of 11am just means they move your room to the bottom of the list for cleaning that day.<br />
* Repack for departure before you go to sleep, except for the clothes and toiletries you'll need in the morning. That way, if you oversleep for whatever reason, you can throw on your clothes, grab those last items, and go without wasting any more time.<br />
* To avoid leaving things behind:<br />
** Bring your original packing checklist, and use it to repack.<br />
** Pull all the linens off the bed and throw all used towels into the shower, so you're sure nothing's hidden, and check every wall socket for chargers.<br />
** If you unpack into drawers, check every drawer before you leave.<br />
<br />
== Pick a hotel, get into the frequent guest program ==<br />
<br />
Same deal as airlines. At the least, it eventually adds up to free stays, but getting to status means room upgrades, easier check-in, more flexibility on check-in/check-out times, and extra points for each stay. Some hotel loyalty points can also be transferred to airline loyalty programs.<br />
<br />
It can be harder to consistently stay with the same hotel group than to consistently fly the same airline (they're sold out or not convenient, the conference hotel is elsewhere, etc.). However, it's good to join the loyalty program for any hotel you stay at, before you make your reservation. You may get a better rate or a better room. Hotel staff seem to give an extra measure of courtesy and consideration when you're in the loyalty program. (When booking by phone, I've had a "sold out" group rate suddenly become available when I gave my membership number.) If you haven't joined by the time you check in, ask the clerk to sign you up; they'll get credit for signing you up, and will be even more inclined to treat you nicely.<br />
<br />
Linked below are the programs associated with the hotels that are typically used for visiting Mozilla in Mountain View.<br />
<br />
{|<br />
|-<br />
|Holiday Inn Express<br />
|[http://www.priorityclub.com/ Priority Club]<br />
|<br />
|-<br />
|Avante/Wild Palms<br />
|[http://www.joyoflifeclub.com/ Joy of Life Club]<br />
|(Does not give points for stays that are paid through corporate billing.)<br />
|}<br />
<br />
== Choose Your Room ==<br />
<br />
It's a good practice to indicate that you have any preference on your room at all. Put this into your loyalty program profile and your travel agency profile (Egencia, for Mozilla employees), so it's transmitted with your reservation. If you have no preference, they will put you in the room for people who do not indicate a preference. You know, the one in the basement. With the leaky faucet and carpet from 1973. <br />
<br />
If you have a choice between one or two beds, choose two, even though you'll only use one for sleeping. The other one makes a great surface for spreading out your stuff. Often, hotel beds are on casters, so you can shove the extra bed against the wall, to prevent stuff falling between the bed and the wall.<br />
<br />
Generally, you'll do well to ask for a high floor and a room away from the elevator. Many hotels do renovations by floor starting from the top and working their way down. So high floors have a better chance of being recently renovated. They are also further away from street noise or the bar in the atrium. A room away from the elevator means less foot traffic and not waking up at 5am to repeated "ding!" of the elevator door opening. For motels, you want upstairs (less foot traffic) and outside (away from the courtyard with the pool).<br />
<br />
If the room is awful, don't be afraid to walk back downstairs and see if they have anything a bit more updated. If the whole hotel is awful, check your luggage at the desk and walk in a square block radius around the hotel to see if there's something less frightening. <br />
<br />
Never pick a hotel based on a picture of the lobby. Lobbies are always the first thing to get renovated.<br />
<br />
== Tipping Hotel Staff ==<br />
If you believe in tipping (which varies across cultures):<br />
* If you take a hotel shuttle from the airport, be sure to tip the shuttle driver. Don't just hand it to them and walk away; look them in the eye and express genuine appreciation for their service while you give them the tip. This is your first contact with the hotel staff, and if you make a good impression, word will spread to the other staff, and you'll get great service throughout your stay. This driver may also be the person who gets you to your outbound flight, through heavy traffic, just in the nick of time.<br />
* Similarly, leave a tip for housekeeping after the first night. This paves the way for good service when you make special requests, such as extra towels or toiletries, or to come back later because you're still in the room. Leave the money on top of a note that says at least "Thanks!" so the housekeeper knows it's for them.<br />
<br />
= Money =<br />
<br />
* Exchange: Do not change money at the airport. The rates are higher there than anywhere else. If you have a local bureau de change, use that, or order currency online for pickup at the airport. If you can find a company that does that (Travelex in the UK, at least) the rates will be much better than those posted on the wall that they charge you when you are a captive customer. The best rates are likely to be had by using an ATM. <br />
* Debit: Using an ATM card can be an easy and inexpensive way to secure some local currency. Make sure your card will work abroad before you travel. Common ATM networks that are broadly available include Pulse and Plus. Consider getting a debit card with no foreign transaction fees (Charles Schwab offers one).<br />
* Stay organized: It's helpful to keep your currency separate from your home currency, particularly if you're going to cycle through multiple currencies during your trip (usd > euro > pounds). Don't underestimate the power of a ziploc baggie if you're American and unaccustomed to coinage-heavy currencies.<br />
<br />
== Credit cards ==<br />
The US has historically had a different system (magnetic strips) for credit card security from the rest of the world (which uses the chip-and-pin system). This can cause headaches for both Americans traveling abroad, and others traveling to the US, as the systems are incompatible. Most US stores now support chip-and-signature cards, but you might run into smaller ones that don't have chip-reading equipment (e.g., a food truck using Square). <br />
<br />
* A very few US banks offer true chip-and-pin cards, including Citibank and [https://www.andrewsfcu.org/credit_cards_and_loans/credit_cards/globetrek_rewards.html Andrews Federal Credit Union]. The latter also has no annual fee and no international transaction fees. See this extensive but not exhaustive [http://thepointsguy.com/2013/05/us-credit-cards-with-smart-chips/ list of US-based chip-and-pin cards]. <br />
* You can get a pre-paid, reloadable chip-and-pin card called [http://www.cashpassport.com/1/travelex/ "Cash Passport"] from Travelex. You can buy it and reload it online or at Travelex locations in the US. You can load it in multiple currencies: GBP, EUR, CAD, AUD and JPY. The security seems a bit crappy (you can't change the PIN, and their only security question is mother's maiden name), but since it's pre-paid, you can limit your financial exposure, and reload online as needed.<br />
<br />
Another issue for travelers is transaction fees when making purchases in currencies other than your home currency; these can range from 1% up to as much as 7%. US-based credit cards that don't charge international transaction fees include CapitalOne and Andrews FCU.<br />
<br />
More and more US retailers have card readers that accept chip-based cards, so the situation is improving for visitors to the US. However, they probably don't understand the PIN system, so you will still need to sign (either on the reader, or on paper).<br />
<br />
= Preparing to be less-online than normal =<br />
<br />
If your cellphone plan doesn't have reasonable data roaming, or if you might be in areas with poor cell coverage, you should be prepared to survive without your usual data connection. This might include things like:<br />
* downloading offline maps in advance. ([http://maps.me/ maps.me] for Android and iOS lets you download offline OpenStreetMap maps by country or part-of-country.)<br />
* knowing where you're going to need to be (hotels, meeting locations) before you leave<br />
<br />
= On Foreign Soil =<br />
<br />
* Data/Voice rates<br />
** You can use Skype to call US 1-800 numbers toll free from anywhere in the world.<br />
** Before you leave your home country, add $20-40 of SkypeOut credits to your account. While Skype to Skype calls are free, SkypeOut credits will let you call any number internationally for about $.02 per minute.<br />
** International text messages are typically NOT covered under your mobile plan. For US cell plans, it's usually about $.50 per SMS. If you have a good international rate, think long and hard about when you use SMS and why. A conversation about when you landed and where to meet and what time to get there on SMS may be more than a 2 minute call that covers the same details.<br />
** [http://readwrite.com/2014/06/17/5-secrets-avoiding-hefty-international-data-roaming-charges-fees 5 secrets to avoiding hefty international data roaming fees] <br />
* Finding wifi<br />
** In airports, airlines' priority lounges often have no wifi password, and you can access their hotspots from outside the lounge. (See note above for JFK airport.)<br />
** Starbucks, McDonalds, and Burger King are sadly ubiquitous, and often have free wifi.<br />
** You can sometimes find the password for a business's wifi in the comments for that business on FourSquare.<br />
* Language barriers<br />
** Grab some business cards or stationery with your hotel's address on them before you head out. You can hand one to a cabbie whose language you do not speak, to get yourself back to home base. <br />
<br />
Still to write/update:<br />
* Language barriers<br />
** Add Line2 details...<br />
<br />
==Coping with jet lag==<br />
* Do not go to sleep. Do not nap. Stay up as long as you possibly can. Eat meals at local times and get into bed when it's dark outside. It will hurt on day one but by day three, you'll be glad you did. <br />
* If you absolutely must sleep, do a 20 minute powernap and then get up, walk around, and do not fall back to sleep. (Powernapping pro tip: drink a cup of coffee, and ''then'' take a nap; the coffee will wake you up in a short while.) <br />
* In a pinch, Benedryl (dipenhydramine) can help you reset your internal clock and it's substantially gentler on your system than the prescription sleep aids. (It's also good for nausea if you get motion sickness, and of course, allergic reactions.)<br />
* If you find yourself awake when you should be sleeping (by local time), avoid bright screens (computers, phones, e-readers), because they activate wakefulness in your brain. Try reading a paper book or magazine (radical, I know). If you must use a screen, set it to white text on a black background, to reduce the overall brightness; or get an app (such as [https://justgetflux.com/ f.lux] for Mac/iOS or [https://play.google.com/store/apps/details?id=com.urbandroid.lux Twilight] for Android) that reduces the amount of blue light emitted by your device at night.<br />
* If possible, follow the [http://www.wikihow.com/Prevent-Jet-Lag-with-a-Modified-Diet Anti-Jet Lag Diet]; this is easier to do at home than while traveling, but IME even an approximation helps. <br />
** As an abbreviated version: eat as little as possible on your day of travel, avoiding caffeine and alcohol; eat a high-protein breakfast at breakfast time in your new time zone.<br />
** Bring protein bars with you to ensure that you can get protein at the right time.<br />
<br />
= Transportation =<br />
<br />
'''Quick Tips'''<br />
* Talk to cabbies. Not only do they know their city, they are less likely to have kickbacks in place than the hotel concierge, more likely to give you good answers.<br />
* Learn the taxi rules. Las Vegas doesn’t let you hail cabs on the street (creates traffic problems). New York cabs have credit card swipes in the back seat, whereas DC cabs just started actually using their meters at all. San Francisco cabs won’t let you exit except curbside.<br />
<br />
Still to write:<br />
* public transit<br />
* hotel shuttles<br />
<br />
== Rental Cars ==<br />
<br />
=== Enterprise Rent-a-Car ===<br />
<br />
Mozilla's preferred vendor<br />
<br />
=== Hertz ===<br />
<br />
If for some reason you end up with Hertz (late evening arrivals mean Enterprise might be closed) you'll want to sign up for [[HertzBusinessAccountProgram|Hertz #1 Gold]] and use that. At most airports, you walk in, your name is on a board with a parking spot number, and the keys and contract are already in the car waiting for you. Really nice after a 5+ hour flight!<br />
<br />
= Eating =<br />
<br />
Eat like a local.<br />
<br />
Never ask the front desk at your hotel for a dinner recommendation. If possible, ask anyone else to weigh in. The bellhop, your taxi driver, the barista at Starbucks, Yelp, Chowhound, etc. The best recommendations come from people who are actually living and working in the area. (TripAdvisor tells you what people who ''don't'' live there think.) The concierge at the hotel will always orient toward broad, tourist-pacifying tastes. The food will be edible, but forgettable. They'll never tell you about the super tasty hole-in-the-wall joint three blocks away.<br />
<br />
= Staying healthy =<br />
* Wash hands frequently! <br />
* Carry and use hand-sanitizer wipes. (A bottle of hand-sanitizer gel takes up valuable room in your liquids bag.) Sanitize your hands in-flight before you eat or drink, and after washing your hands in the lavatory (on-board water, again). Also use them to wipe off [http://www.travelmath.com/feature/airline-hygiene-exposed/ tray tables, seatbelt buckles, and air vents], where germs lurk on airplanes.<br />
* Set the fan above your seat on the plane to low or medium, and position it to blow into your lap, just in front of your face. This will help knock airborne pathogens out of the air, so you'll be less likely to breathe them in. ([http://www.npr.org/blogs/goatsandsoda/2014/07/14/319194689/pathogens-on-a-plane-how-to-stay-healthy-in-flight?ft=1 (NPR) Pathogens on a plane: how to stay healthy in flight])<br />
* Keep your exercise routine as much as possible. Exercise burns calories, relieves stress, and helps reset your body clock, if you're in a different time zone.<br />
** Pick a hotel that has a fitness center. If you must use a hotel that doesn't have one (or you need specific equipment, like a stationary bike) call and ask; they may have an arrangement with a nearby gym.<br />
** If you're out of luck on the fitness center, bring an exercise DVD, and/or small lightweight equipment like a jump rope or tension bands. Or do a [http://well.blogs.nytimes.com/2013/05/09/the-scientific-7-minute-workout/ body-weight-only exercise routine].<br />
** Bring quick-drying workout clothes. Rinse them in the shower, and dry them over the shower rod, so they're ready for tomorrow.<br />
** Bring athletic shoes that double as casual street shoes, so you don't need to take up luggage space with extra shoes.<br />
** See the Quartz [http://qz.com/287800/the-complete-guide-to-staying-in-shape-on-the-road/ Complete guide to staying in shape on the road].<br />
<br />
= Redux =<br />
<br />
'''Most people travel infrequently, and aren’t very skilled at it...'''<br />
* and there are a lot of people, so despite the infrequency of their travel, the Don’t Know path is very crowded<br />
* Businesses on the Don’t Know path have no loyalty to you (since infrequent travellers have no meaningful loyalty to them) so their main goal is to extract money from you immediately, even at the cost of the relationship<br />
* People on the Don’t Know path have to deal with the same Don’t Know problems every single day, which is exhausting and saps their empathy<br />
<br />
'''BUT - If you know what you’re doing...'''<br />
* You can shortcut around the Don’t Know path everywhere. Airports, Hotels, Restaurants<br />
* The businesses you deal with will view you as a regular, and want to keep you happy<br />
* The people you deal with will view you as a breath of fresh air, and feel understood, and be grateful and human in the ways that travel never is for others.<br />
<br />
= More advice =<br />
* [http://www.jonobacon.org/2016/08/10/the-bacon-travel-survival-guide/ Travel Survival Guide] by Jono Bacon<br />
* [http://christianheilmann.com/2014/02/16/how-i-save-money-when-traveling-for-work-san-franciscovalleyus/ How I save money when traveling for work] by Christian Heilmann<br />
<br />
These podcasts have some excellent advice on business travel:<br />
* [http://www.manager-tools.com/2009/07/airline-travel-basics-1-part-1 Airline Travel Basics, part 1]<br />
* [http://www.manager-tools.com/2009/08/airline-travel-basics-1-part-2 Airline Travel Basics, part 2]<br />
* [http://www.manager-tools.com/2008/08/business-travel-packing Business Travel Packing]<br />
* [http://www.manager-tools.com/2009/07/travel-airline-seats Travel - Airline Seats]<br />
<br />
The what and how of packing only a carry-on: [http://www.onebag.com/ Onebag.com]</div>Dbaronhttps://wiki.mozilla.org/index.php?title=Paris&diff=1200814Paris2018-09-10T18:41:01Z<p>Dbaron: /* Hotels */ Hotel Bergere Opera is now Hotel 34B</p>
<hr />
<div>= Welcome to Paris! = <br />
<span style="float:right;padding:0 0 1em 1em">[http://standblog.org/blog/post/2013/03/27/Les-nouveaux-bureaux-de-Mozilla-a-Paris http://farm9.staticflickr.com/8511/8595089145_ef224353b7_b.jpg]</span><br />
We're glad to have you here! This page is meant to help visitors find their way to the Paris office and around Paris. If you have any additional questions, please feel free to ask in #paris on irc.mozilla.org, or if you happen to be around the space come talk to us. If there is anything missing that you think might help future visitors, please add it / let us know :-).<br />
= Details =<br />
'''Email:'''<br /><br />
To be added<br />
<br />
'''Address:'''<br /><br />
16bis Boulevard Montmartre <br /><br />
75009 Paris, France <br /><br />
[https://maps.google.com/maps?q=16+Boulevard+Montmartre,+75009+Paris,+%C3%8Ele-de-France,+France&hl=en&ie=UTF8&ll=48.871871,2.341332&spn=0.003507,0.009645&oe=utf-8&client=firefox-beta&geocode=FcK56QId2rkjAA&hnear=16+Boulevard+Montmartre,+75009+Paris,+%C3%8Ele-de-France,+France&t=m&z=17 Map]<br />
<br />
<div style="float:right;clear:right;padding:0 0 1em 1em">__TOC__</div><br />
= About the Space =<br />
Our new Mozilla Paris space combines working areas for up to 50 people and a vibrant community space designed to host up to 150 people for our Mozilla community events, meetups, and work weeks. We’ve incorporated the same leading technologies, amenities and designs as our other unique Mozilla Spaces around the world, all with a unique Paris feel. After all, it is Paris!<br />
<br />
[https://blog.mozilla.org/places/2013/03/27/mozilla-paris-finally-united/ Announcement blog post] (March 27, 2013)<br />
<br />
= Traveling to Paris =<br />
See [http://en.wikivoyage.org/wiki/Paris#Get_in Wikivoyages on getting to Paris].<br />
<br />
Note that Gare du Nord (French for "North Station"; outside of Paris it may be called "Paris - Nord") is about a 20-25 minute walk from the Mozilla office, so depending on the weather and what you're carrying, you might choose to walk from Gare du Nord to the office (alternatives: Metro with transfer, taxi). But if you do, you should definitely consult a map first and probably have the map with you.<br />
<br />
= Finding the Space =<br />
<br />
From the metro, use one of the following two stations:<br />
* '''Grands Boulevards''': Follow the signs to exit 2 (boulevard Montmartre). After you reach the top of the stairs, continue straight ahead (without crossing any streets) until you reach a large doorway with the number 16<sup><u>BIS</u></sup> over it, just after the Pret a Manger.<br />
* '''Richelieu-Drouot''': Follow the signs to exit 3 (bd. Montmartre). At the top of these stairs, continue straight ahead and immediately cross Rue Drouot (the smaller of the two streets at the intersection), and continue straight ahead (without crossing any other streets) until you find a large doorway with the number 16<sup><u>BIS</u></sup> over it, just before the Pret a Manger.<br />
<br />
There is no Mozilla sign on the door or building. <br />
<br />
Once you're at this large door, you'll need to go through ''three'' doors to enter the Mozilla space:<br />
* First, the large door to the street with the number 16<sup><u>BIS</u></sup> over it. It has a keypad to the right of it. On this keypad you can use the arrows to select "MOZILLA" and then press the button with a bell symbol to call to be let in. Once you are let in, you need to push on the ''left'' half of the door. Push on the bar rather than the doorway, since there is a smaller door (hard to see) that does not take up the full doorway. (Note that both halves of the door have a bar to push on, but you need to push on the bar on the left half.) This door is '''quite heavy''', and you will have to push '''hard'''.<br />
* Second, you need to cross a metal gate just inside this doorway. Follow exactly the same procedure on the freestanding keypad before the gate. Then pull on the right half of the gate to enter. (Note that with both the first and second doors, the part of the door that moves is the half ''further'' from the keypad.)<br />
* Then, walk forward about 10 meters, and on your right you will see a doorway with the word "Mozilla" on the glass. This door has a simple doorbell button on it you can use to be let in. On this door, pull on the left half of the door (which is the only half with a handle).<br />
<br />
Then walk up the stairs into the Mozilla space.<br />
<br />
== Leaving the Space ==<br />
<br />
When leaving the space, please use the small button in the final pair of doors to exit, and do not open the large doors themselves.<br />
<br />
= Traveling around in Paris =<br />
[http://en.parisinfo.com/paris-map/getting-around/public-transport/ Public transit] in the city offers a few options - metro, bus, RER (suburban express railway), and suburban trains (Transilien).<br />
<br />
= Hotels =<br />
<br />
There are many hotels near the office. Some (across varying price/quality ranges) that Mozillians have had good experiences staying at include:<br />
<br />
* [http://www.ihg.com/holidayinn/hotels/us/en/paris/parpp/hoteldetail Holiday Inn Paris Opera - Grands Boulevards] (****)<br />
* [https://en.astotel.com/hotel/34b-en/overview Hotel 34B] (***)<br />
* [http://www.hotel-vivienne.com/en/ Hôtel Vivienne] (**)<br />
* [http://www.millenniumhotels.com/millenniumparis/ Millenium Opera] Very nice, is wheelchair accessible too!<br />
<br />
== Laundry ==<br />
<br />
There is a laundry nearby at 37, rue de Trévise ([https://maps.google.com/maps?saddr=16+Boulevard+Montmartre,+75009+Paris,+France&daddr=37+Rue+de+Tr%C3%A9vise,+75009+Paris,+France&ie=UTF8&dirflg=w directions from office]). It's mostly self-explanatory (and has good english signage). The one thing that is unlabeled is the detergent/softener dispensing machine. In France, laundry detergent is generally (as it is at this laundromat) in small foil-covered bricks. The packets are something else (probably softener, maybe bleach). The money input for all the machines the laundromat takes either coins or bills.<br />
<br />
= Car hire =<br />
<br />
= Paid staff =<br />
<br />
= Good things nearby =<br />
<br />
== Coffee ==<br />
<br />
== Bars ==<br />
<br />
== Cafes ==<br />
<br />
== Bread ==<br />
There is a good bakery at 26 r. du Faubourg Montmartre. [https://www.google.com/maps/dir/16+Boulevard+Montmartre,+Paris,+France/Denis+Alain,+26+Rue+du+Faubourg+Montmartre,+75009+Paris,+France/@48.8725303,2.3405219,18z/data=!3m1!4b1!4m14!4m13!1m5!1m1!1s0x47e66e3ebb6fbb61:0xe8752d6580b17b64!2m2!1d2.3411542!2d48.8721388!1m5!1m1!1s0x47e66e3ef92b004f:0x9c79ff2801016cbb!2m2!1d2.3430229!2d48.8735729!3e2 directions from office]<br />
<br />
== Chain restaurants ==<br />
<br />
== Other notables ==</div>Dbaronhttps://wiki.mozilla.org/index.php?title=All_Hands/SanFrancisco2018&diff=1195332All Hands/SanFrancisco20182018-06-07T18:58:54Z<p>Dbaron: /* Dates, Location and Weather */ mention possible warm/hot spell</p>
<hr />
<div>'''What is it?''' -- Multiple team meetings, happening in the same city, at the same time + some opportunity to get together as one big group as well as with other teams as it makes sense. Then, on the last day, we have a fun social event for all, Mozilla-style! <br />
<br />
'''''The information on this wiki primarily applies to Full time and contractor staff. If you are a volunteer contributor or intern, please inquire to your coordinator. '''''<br />
<br />
=='''Dates, Location and Weather'''==<br />
Monday, June 11 - Friday, June 15, 2018 (travel days are Monday the 11th & Saturday the 16th) in San Francisco, CA.<br />
<br />
We are staying at [http://www.marriott.com/hotels/travel/sfodt-san-francisco-marriott-marquis/ San Francisco Marriott Marquis].<br />
<br />
''*For those countries where rest time is required on weekends (vs. work travel), Mozilla will cover a return on the next available work day, if you choose. This needs to be pre-approved and pre-arranged.''<br />
<br />
Weather:<br />
* National Weather Service: [http://forecast.weather.gov/MapClick.php?smap=1&lat=37.785&lon=-122.410&unit=1&mp=1 forecast in ⁰C], [http://forecast.weather.gov/MapClick.php?smap=1&lat=37.785&lon=-122.410&mp=1 forecast in ⁰F]<br />
* Temperatures ''in downtown San Francisco'' in late June are likely to have nighttime lows around 10-13 ⁰C / 50-56 ⁰F and daytime highs around 16-24 ⁰C / 61-75 ⁰F. But the weather is very occasionally warmer with highs around 27⁰C / 81⁰F. (Update June 7: It looks *possible* that at least part of the week will be at the warm end of this range, or possibly warmer.)<br />
* Weather in San Francisco in the summer is variable; it can become substantially cooler and foggier in the late afternoon; be prepared for temperatures to fall to 13⁰C / 56⁰F and the winds to pick up in the afternoon. Be prepared by carrying a warmer layer with you.<br />
* Weather in other parts of the Bay Area can be much warmer than in San Francisco, even if you're only traveling 15km away. Look at the weather forecasts for where you're going. It's entirely possible for it to be 19⁰C / 66⁰F in San Francisco and simultaneously be 32⁰C / 90⁰F in Orinda. But if you're right on the ocean, the air temperature is likely to match the water temperature, which is probably around 12⁰C / 54⁰F.<br />
<br />
=='''Registration & Badge Pick Up'''==<br />
This is an invitation-only event.<br />
<br />
Advance registration is required. Attendees, guests and local guests will need to wear their event badge at all times, including to evening events.<br />
<br />
====Badge Pick up====<br />
Badges can be picked up at the following days/times:<br />
*Monday, 12:00 pm - 6:00 pm, Golden Gate Registration, B2 Level; or 6:00 pm - 9:00 pm at City View at Meteron (our welcome reception location)<br />
*Tuesday, 7:00 am - 1:00 pm, Golden Gate Registration, B2 Level; or 10:30 am - 5:00 pm 2nd Floor, Atrium<br />
*Wednesday, 7:00 am - 1:00 pm, Golden Gate Registration, B2 Level; or 7 am - 5 pm 2nd floor Atrium<br />
*Thursday, 7:00 am - 1:00 pm, Golden Gate Registration, B2 Level; or 7 am - 5 pm 2nd floor Atrium<br />
*Friday, 7:00 am - 1:00 pm, Golden Gate Registration, B2 Level; or 7 am - 4 pm 2nd floor Atrium<br />
<br />
====Day Pass Attendees====<br />
Day pass attendees must be pre-registered and on an approved list to attend. Please email bmark@mozilla.com for details on how to get them registered. See [https://wiki.mozilla.org/All_Hands/SanFrancisco2018#Day_Pass_Attendee_Logistics below] for more details on logistics.<br />
<br />
====New Hires====<br />
We have a process to identify new hires each Monday and will invite them to book travel. No action necessary from managers other than to let them know about the event. Please work closely with your recruiting manager as they are aware of all deadlines.<br />
<br />
Monday, May 7 was the deadline for hiring. Friday, May 11 was the deadline that all new hires who must travel to the all hands but be registered and have travel booked. Friday, May 18 was the deadline for Bay Area/local new hires who do not need hotel or to travel need to be registered. All new hires must start on or before May 29.<br />
<br />
====Contributors participation====<br />
The process for this is [[All Hands/SanFrancisco2018/Contributor_nominations|outlined on this page]]. <br />
<br />
All nominations will be done by employees, with a coordinator from each of the Firefox/Product, Emerging Technologies, Marketing, Open Innovation and People parts of the organization. There will be no open call for nominations from contributors or volunteer Mozillians.<br />
<br />
Please note: The information on this wiki primarily applies to fulltime and contractor staff. If you have questions about how specifics apply to you, please email groter@mozilla.com and bmark@mozilla.com.<br />
<br />
====Mozilla Foundation====<br />
The Foundation has decided to host their own All Hands from June 12-14 in Toronto. Information about their All Hands is available on the mana.<br />
<br />
=='''Week at a Glance'''==<br />
<br />
[https://docs.google.com/spreadsheets/d/1CEA1bnC5A4RrGirqojSEtGjv-LgR2RQz6Sm4j8XA8qo/edit?usp=sharing Here] is what the week looks like (subject to change)<br />
<br />
=====Monday=====<br />
Monday is primarily your travel day. You'll be able to pick up your registration stuff between 12:00 pm and 9:00 pm, as well as attend the Welcome Reception at the City View at Metreon from 6:00 pm - 9:00 pm. <br />
<br />
https://sanfranciscoallhandsjune2018.sched.com/2018-06-11/overview/<br />
<br />
=====Tuesday=====<br />
We'll start Tuesday with a Plenary session, followed by various team meetings and Product/Tech Lightning Talk Sessions. The evening is open for dinner on your own or team dinners. <br />
<br />
https://sanfranciscoallhandsjune2018.sched.com/2018-06-12/overview/<br />
<br />
=====Wednesday=====<br />
Wednesday is split between team time and Product/Tech Conference Sessions. The evening is open for dinner on your own or team dinners. <br />
<br />
https://sanfranciscoallhandsjune2018.sched.com/2018-06-13/overview/<br />
<br />
=====Thursday=====<br />
Thursday is team time. The evening is open for dinner on your own or team dinners.<br />
<br />
https://sanfranciscoallhandsjune2018.sched.com/2018-06-14/overview/<br />
<br />
=====Friday=====<br />
Friday is team time. Our closing party with be at the Exploratorium from 7:00 pm- 11:00 pm. We'll provide transportation to/from the hotel & venue + if the weather is nice, you could walk (about 1.5 miles / 2.4 km, 30 minutes).<br />
<br />
https://sanfranciscoallhandsjune2018.sched.com/2018-06-15/overview/<br />
<br />
=====Saturday=====<br />
Departure day only. No scheduled activities, except optional breakfast.<br />
https://sanfranciscoallhandsjune2018.sched.com/2018-06-16/overview/<br />
<br />
==='''San Francisco All Hands Event Calendar'''===<br />
Now live! https://sanfranciscoallhandsjune2018.sched.com/<br />
<br />
Don't see stuff for your org yet? Don't fret! The schedule changes regularly as meetings and events are confirmed. Keep checking back. <br />
<br />
=====Create an account=====<br />
We don’t recommend using the same email & password as anything like bank accounts, etc. We care about your security!<br />
<br />
If you already have a Sched account from past All Hands, it still works, just log in with that.<br />
<br />
=====Add items to your calendar=====<br />
Select the circle on any agenda item to add it to your calendar (you do need to have an account & be logged in to do this)<br />
<br />
You can also share a link to meetings to invite others. Go into the meeting and copy the short link. You can email that out to anyone and they can quickly add it to their calendar.<br />
<br />
=====Subscribe to GCal Calendar Link=====<br />
Click on the mobile phone on the right hand side of the screen. All the calendar options are available here. <br />
You have the option to choose ALL meetings or YOUR meetings. Unless you have 400 items on your calendar, just select your calendar. It will add anything on your calendar to your GCal (also an option for Outlook and iCal). It syncs once per day.<br />
<br />
The "only syncs once per day" only applies to Google Calendar. With almost all other clients (like Apple Calendar, Outlook, or the calendar app on your phone) you can set the refresh interval, and Sched's instructions recommend 1 hour.<br />
<br />
Warning: This is a link that utilizes your username for the .ics file.<br />
<br />
=====From Mobile=====<br />
Visit from any mobile device - bookmark or add to your homescreen for quick access. There is a bonus icon you get by doing this. It caches the last time you opened the page offline and refreshes anytime you are connected.<br />
<br />
=====Cool things=====<br />
'''Filters'''<br />
<br />
We have filtering functionality. You can filter by:<br />
Departments (ex: Product Org)<br />
AND<br />
Functional Teams (ex: Firefox Addons)<br />
<br />
*Search by Room, Speaker/Leader<br />
<br />
'''Further Filtering'''<br />
*Audience - who should be there (ex: Team only or Invite)<br />
*Homerooms (you can quickly see what is happening in homerooms, by team) - why do you care? If you have a cross team meeting in their room, its a quick way to search<br />
*Views - Lots of view options. It defaults to the simple view, but there are quite a few options.<br />
<br />
=='''Meeting Space'''==<br />
Mozilla has all of the meeting space in the hotel. Overview map can be found [http://www.sfmarquis.com/maps-1/ here]<br />
<br />
=='''Wi-Fi'''==<br />
'''Guestroom:'''<br />
Marriott and Starwood rewards members have free Wi-Fi. Sign up for Marriott rewards online ahead of time or on-site when you check in. Anyone who isn’t a rewards member will be charged $1 per day, unlimited devices. Choose normal network and accept $14.95 per day charges and they will be reduced. More expensive connections will not be reduced and will be guest responsibility. The lobby has a free network as well, available prior to check in. <br />
<br />
'''Meeting:'''<br />
SSID & PWD provided by email. <br />
<br />
Note: Lower B2 Level has NO cell service except AT&T. Connectivity available by Wi-Fi only. <br />
<br />
=='''Presentation templates'''==<br />
Here are the All Hands themed templates in [https://docs.google.com/presentation/d/1KksyVe64EhGDYPW_rqCrthccOt3xLCrXZ9uiHFfpxjQ/edit?usp=sharing Google Slides] + [https://www.dropbox.com/s/k8pgg4czutmax0b/Moz_AHSF2018_Master.key?dl=0 Keynote]<br />
<br />
=='''Food & Drink'''==<br />
Breakfast, lunch & snacks will be provided and paid for centrally for attendees. Breakfast is provided Tuesday - Saturday and lunch is provided Tuesday - Friday. <br />
<br />
Allergies/preferences: We will ensure that all food/environmental allergies are taken into consideration and will always have gluten-free and vegan options. If you have severe allergies that we need to know about; you can indicate in registration.<br />
<br />
The menus can be found [https://docs.google.com/document/d/1rS-Ln4w80CmN9CVQUpX9iViY7KE7Z6w799jkOLaP6yU/edit?usp=sharing here].<br />
<br />
===Monday Night===<br />
Since most of Monday is a travel day, you'll be on your own for meals except dinner. We will provide dinner at the Welcome Reception from 6:00 pm - 9:00 pm at City View by Meteron.<br />
<br />
Watch for greeters in the hotel lobby and on the street to get you in the right place. This is our first time leaving the hotel on the first night. <br />
<br />
We'll have badge pick up available for the duration of the reception right outside the entrance, if you miss picking it up at the hotel until 6:00 pm.<br />
<br />
===Tuesday, Wednesday & Thursday Nights===<br />
Tuesday, Wednesday and Thursday evenings will be of your own to structure as you wish. Given how much you all seemed to like a more flexible dining experience, these three evenings will be of your own to structure as you wish.<br />
<br />
Here is how this will work:<br />
<br />
For each of these three evenings, once your meetings have concluded, you and your team, friends, new acquaintances, are free to explore San Francisco and to find somewhere great to eat that suits you. Each of you can expense a total of $180 over the three days (or $60/night).<br />
<br />
This amount includes:<br />
* Meal cost, including tax & gratuity<br />
* Any beverages<br />
* Transportation to/from the restaurant<br />
* Conversion fees (for credit cards) or cash withdrawal fees<br />
<br />
Anything over the $180 for the three evenings will be your own expense. The fine print:<br />
* If your team is hosting an evening event 1 of the 3 nights and the payment is coordinated (meaning, you don’t have to open your wallet and pay), you can expense up to $120 for the other 2 nights ($60 for each of the 2 nights you did have to open your wallet and pay).<br />
* You will be asked (later) to submit a San Francisco only expense report. You can submit ONE report for San Francisco only and must be submitted no later than August 31, 2018.<br />
* If your manager approves expenses above the $60 per night, that expense will go directly to your travel budget in your cost center.<br />
<br />
Volunteer Contributors & Interns will have a separate process that will be communicated directly.<br />
<br />
===Friday Night===<br />
We will provide dinner at the Closing Party from 7:00 pm - 11:00 pm at The Exploratorium.<br />
<br />
*Shuttles - 6:45 pm - 11:05 pm, Marriott & Exploratorium<br />
*Dinner - 7:00 pm - 9:00 pm, East, West & Central Galleries<br />
*Dessert & some snacks - 7:00 pm - 10:30pm, East, West & Central Galleries<br />
*Drinks - 7:00 pm - 10:45 pm, All galleries<br />
*Exhibits & Tactile Dome - 7:00 pm - 11:00 pm, All galleries<br />
*Photobooths - 7:00 pm - 11:00 pm, West & Central galleries<br />
*DJ & Dancing on an LED floor - 7:00 pm - 11:00 pm, Central Gallery<br />
*Quiet(er) space + Bay views - 7:00 pm - 11:00 pm, Fisher Bay Observatory<br />
<br />
====='''Getting there (and back)'''=====<br />
Shuttles will pick up from the Marriott starting at 6:45 pm. Shuttles will loop between the Marriott and Exploratorium all evening, with the last departure back to the hotel at 11:05 pm. You can come and go as it works for you.<br />
<br />
====='''What to Wear'''=====<br />
Whatever makes you comfortable + your event badge will be required to board the transportation and enter the venue + photo ID.<br />
<br />
====='''Guests'''=====<br />
Guests will require a guest badge. Please make sure to pick up badges for pre-registered guests at the desk by 3:00 pm on Friday.Not sure you pre-registered your guest(s)? Email mozilla@shworldwide.com and they can confirm for you. We can add guests until Friday, June 8.<br />
<br />
====='''Coat Check'''=====<br />
We will not have a coat check. Do not bring anything you do not want to carry.<br />
<br />
====='''Parking'''=====<br />
If you plan to go there directly on your own, self- parking options are:<br />
*1010 Front is across the street from the Exploratorium – 195 spots<br />
* 50 Broadway is a block away – 200 spots<br />
* 90 Broadway is 2 blocks away – 150 spots <br />
* Pier 19.5 is a block away from the Exploratorium and is only open until 10pm<br />
<br />
=='''Photos'''==<br />
==== Red Lanyards ====<br />
If you see someone with a red lanyard, please don't take photos of them. They have opted out of being in photography. We'll have these available at the registration desk.<br />
<br />
=='''Safety & Security'''==<br />
<br />
=====Personal Security=====<br />
While in the Mozilla meeting spaces and meal spaces, a name badge is required. <br />
<br />
When you leave the hotel, you should remove your badge. Pickpocketers have been known to target people wear conference badges in the neighborhood we are in.<br />
<br />
=====Alcohol at Events=====<br />
To better support and sustain an environment (and workplace culture) where people feel safe and included, we plan make a set of changes regarding alcohol at our events. In all cases, our approach will align with our [https://www.mozilla.org/en-US/about/governance/policies/participation/ Community Participation Guidelines] (“CPG”).<br />
*All participants were/are '''required to read and acknowledge our new Community Participation Guidelines as a condition of participation'''.<br />
*We will '''limit bar-servings to beer and wine''' and ensure an equal number and quality (i.e. not just Coke) of non-alcoholic drink options are available and displayed.<br />
*When teams undertake smaller, “off campus” adventures (team dinners or events), leaders will be asked (and reminded) to be '''thoughtful about the potential exclusionary nature of alcohol when planning'''.<br />
*Clearly outlined, communicated (to event teams, HR and managers) and understood '''escalation process''' for behavior that might be deemed counter to the spirit of our CPG.<br />
<br />
=====Meeting Security=====<br />
You'll need to have your badge on at all times in the hotel, as will your partners, vendors and family members anytime they are in the spaces.<br />
<br />
=====Device Security=====<br />
If you are traveling to the San Francisco All Hands with a device that has Mozilla data (laptop, personal cell phone/tablet with @mozilla gmail, etc) on it and your device has been retained for further inspection by border agents, or if your device has been inspected outside your immediate presence - and you believe your credentials have been compromised - you must notify the Enterprise Information Security team as soon as possible at infosec@mozilla.com or by calling Mozilla End User Services at +1 650-963-8811. (This number will be staffed 24x7)<br />
<br />
We will work with you to reset your credentials and help you get your device back to a known good state either by getting you a new one (if it’s been taken), or by resetting it back to a verifiable Mozilla-approved installation.<br />
<br />
=====Safety Tips=====<br />
SF Travel team also has some [https://sftravel.ent.box.com/s/p2ve63e1ctn74e0ai2x48mmgr9fdlvul tips about safety] in the city, including safety numbers and local hospitals.<br />
<br />
=='''Hotel'''==<br />
Hotel rooms are reserved for all employees & volunteers to stay all week, including employees based in San Francisco (just as if we were somewhere you don't live). We are hopeful Mozilla-locals will stay with the rest of us in the hotel - it's really part of what makes these events great. You will have the option to opt out of hotel in registration if you are local to the Bay Area and wish to commute. <br />
<br />
====Conservation Efforts====<br />
*Marriott offers "Make a Green Choice" program and you can be rewarded 500 Marriott Rewards points or $5 Food and Beverage voucher for every night that you choose not to have your room cleaned. Should you wish to sign up for this Green Initiative, you may do so when you check in. <br />
*In an effort to become a Zero waste hotel by 2020, The Marriott does not offer any bottled water inside the guest rooms or meeting rooms. Flowater stations offering electrolyte infused and alkaline water are available in the Lobby and 2nd Floor (near the elevators) + water stations are available in each of the meeting rooms. <br />
<br />
====Hotel Confirmations====<br />
The Marriott has processed reservations for staff, contractors and interns. Confirmation emails were sent from: Marriott Hotels & Resorts Reservations <reservations@marriott-res.com>. <br />
<br />
If you do not receive a hotel confirmation email by May 18th, please email mozilla@shworldwide.com (after checking your spam collector). If you registered after April 27, your confirmation may arrive later. <br />
<br />
''Reservations for volunteers are still pending and confirmation emails have not been sent.''<br />
<br />
A few things to note:<br />
*If you have any changes or questions about your reservation, email mozilla@shworldwide.com. The hotel cannot make changes to All Hands reservations (other than to add your guests - see #3) so we’d like very much if you didn’t try (it complicates things).<br />
*If you have guests joining you for all or part of the week, you will be responsible for adding them to your reservation (and covering any additional fees). <br />
*Volunteers, summer interns and outreachy interns will be sharing rooms.<br />
<br />
====Payment on Check-in====<br />
Everyone will be required to present a form of payment on check-in for incidentals at $50 per day. This is a US hotel standard and we aren't able to waive it (we tried).<br />
<br />
We recommend providing a credit card. You can provide a debit card, but they do put a hold of funds on your card and has been problematic for some international travelers in the past. If you are not able to provide a credit or debit card, email mozilla@shworldwide.com and we'll work with the hotel on accommodating. <br />
<br />
====Pre/post====<br />
Links were provided when you are invited to register in April to book hotel 3 days pre and 3 days post at our negotiated rate. The pre/post reservations require the use of an LDAP email so we can link them to your All Hands reservation. Rooms booked by any method except this link will not be linked to your main reservation. Reservations via those links are no longer available, as of May 18, 2018.<br />
<br />
====Parking====<br />
Self-Parking is available at several lots nearby. [ http://www.fifthandmission.com/map.htm 5th & Mission Garage] is the closest option, reccomended by the hotel. It is $34/night. The Marriott Marquis offers valet only for $80/night - please do not park valet. <br />
<br />
Mozilla will not reimburse for parking, plan to commute the way you normally would in the city. If you have questions about parking, email bmark@mozilla.com.<br />
<br />
=='''Travel'''==<br />
====Arriving into San Francisco====<br />
'''Travel Delays, Cancellations, etc.'''<br />
<br />
If your flight is delayed or cancelled, work with the airline in the airport to get re-booked. If you’re cancellation or delay will impact your arrive time by >6 hours, you must email mozilla@shworldwide.com so we can adjust your hotel reservation. If you don’t do this, the hotel will cancel it.<br />
<br />
'''Device Security'''<br />
<br />
In the unlikely event you are asked to surrender a device to border agents (anything with Mozilla data on it), notify the Enterprise Information Security team as soon as possible at infosec@mozilla.com or by calling Mozilla End User Services at +1 650-963-8811. (This number will be staffed 24x7)<br />
<br />
====Arriving Early/Departing Late Guidelines====<br />
<br />
Our standard travel guidelines apply (pre-populated in Egencia) when booking with a few additional budget constraints. Anything booked outside of them will require approval. Most people will arrive on Monday, June 11 and leave on Saturday, June 16. Here are some exceptions: <br />
* If you live in a country where work travel is prohibited on weekends, you may travel on Friday, June 8 and Monday, June 18, if you’d prefer (not required). For hotel, you will book and pay on your own, and expense the manager approved amount (which is coded to your cost center).<br />
* If you plan to spend some extra personal time in San Francisco (choosing to arrive before Monday, June 11 or depart after Saturday, June 16), you'll need to create an itinerary in Egencia for standard dates/locations within the San Francisco June 2018 Portal and compare to the custom dates you'd like. Please share the difference via email to bmark@mozilla.com before submitting the flight. You can sway up to +$100 over and Mozilla will cover it. Otherwise you'll need to come with an alternate itinerary that fits within the pricing (like a round trip in and out of SFO w/ longer dates, and you personally book & cover the rest). We do not have the ability for employees to reimburse Mozilla for any overage.<br />
* If you are attending the Monday Core Influencer's event (by invite).<br />
* If you would like to arrive early to recover from jetlag, you will need manager approval for any additional costs associated with the extension. There is no unilateral "All Hands" approval based upon timezone to arrive early. For hotel, you will book and pay on your own, and expense the manager approved amount (which is coded to your cost center).<br />
<br />
====Booking Family Travel====<br />
Once travel has opened to staff, you may book family, whether they will accompany you on your flight or join us later; and you have two options: Direct or through Egencia. <br />
<br />
If you choose to book family through Egencia, please first book your own flight and then call Egencia with your airline confirmation number (staff do have to go through Egencia). Otherwise, you can book family direct (either through the airline or through another third party) and call the ticketing airline(s) with both confirmation numbers and ask them to link your reservations, so they know you are traveling together. They should also be able to assign seats together. You will avoid the limited hours Egencia offers and avoid paying their ticketing fee. <br />
<br />
If you prefer to book your family through Egencia, you can pay (including the Egencia booking fees) and coordinate with your own travel (recommend to book and then call/email Egencia with your itinerary number to match for family). Note that booking through Egencia does not put you on the same reservation, nor guarantee the reservations will be linked (you would still need to call the airline to link them). <br />
<br />
''Volunteers, summer interns and outreachy interns will be sharing rooms and are unable to invite family to join them.'' <br />
<br />
* '''Call:''' +1 (877) 264-1622 or +1 (417) 521-0273; Monday - Friday 9 am - 6 pm EST. If you call outside these hours, you will get an after hours agent, who may not be as helpful.<br />
<br />
====Travel Insurance====<br />
Mozilla provides emergency medical accident and illness cover for all global MoCo employees/interns and their dependents. You can view more information on [https://mana.mozilla.org/wiki/display/PR/Travel+insurance%3A+Business Mana]. This coverage begins at the time the you leave home to start your business trip. It also has a provision for a 14 day extension for leisure travel outside of the business travel. If you have additional questions, please email benefits@mozilla.com. <br />
<br />
Mozilla does not cover travel insurance for elancers, upworkers, contractors, vendors, or volunteers/community members.<br />
<br />
=====''Air Travel Fine Print''=====<br />
*Change fees will be covered by Mozilla for '''business reasons only'''. If you need a change and have manager approval, email bmark@mozilla.com prior to requesting the change with Egencia. Once you have approval, call Egencia to make the change at +1 (702) 939-2530 or +1-877-264-1622 (note this will not be possible without prior approval so be sure to get that by way of an email from your manager to Brianna Mark). If you are changing for personal reasons, the change in airfare, change fee and Egencia fee is your responsibility.<br />
<br />
*Mozilla will not reimburse for Business/First class upgrades or tickets. <br />
<br />
*Any submitted expenses needs to have an itinerary attached to ensure it is employee expenses only and within policy.<br />
<br />
=='''Airport Shuttle'''==<br />
All Mozillians and guests who have flights arriving anytime on Monday, June 11th in San Francisco International Airport (SFO) and out on Saturday, June 16th, will be transferred to the hotel. If you arrive into another airport (OAK or SJC) or on a different date, ground transportation is on your own.<br />
<br />
=====Arrivals to San Francisco International Airport (SFO)=====<br />
The airport has four terminals: Terminal 1, 2 & 3, and the International Terminal. For domestic flights In Terminals 1, 2 & 3 and the International Terminal (there are domestic flights), everyone will be greeted at the bottom of the escalator in the baggage claim for your terminal (even if you have no checked bags). Please identify yourself to the greeter and they will direct you to the shuttles for your terminal. <br />
<br />
For International Flights into the International terminal, you will collect your luggage and pass through customs. Once through customs, you will walk directly out to the main lobby, where you’ll find a greeter and they will direct your to your shuttle.<br />
<br />
Transfer time from the airport to the hotel is approximately 40-60 minutes.<br />
<br />
=====Departures from San Francisco International Airport (SFO)=====<br />
<br />
Everyone departing on Saturday, June 16th, will receive transportation to SFO. You will be met by transportation staff in the Marriott hotel lobby and assisted onto the shuttles. <br />
<br />
If you have questions about arrivals or departures, please email mozilla@shworldwide.com.<br />
<br />
====Alternate Transportation Options====<br />
For those arriving or departing on dates other than June 11 and 16. <br />
*[http://www.bart.gov/stations/powl BART] goes from SFO to the Powell Street Station for $8.95. Tickets can be purchased at the airport or in advance. <br />
*[http://www.samtrans.com/schedulesandmaps/timetables/292.html SamTrans bus Route 292] goes from SFO to Mission St. & 5th St. only for [http://www.samtrans.com/fares/farechart.html $2.25 (inbound) or $4 (outbound)].<br />
*[https://www.supershuttle.com/locations/sanfranciscosfo/ Super Shuttle]. Shared shuttle service. Book in advance. <br />
<br />
Other options can be found on the [https://www.flysfo.com/to-from/ground-transportation SFO website].<br />
<br />
====Mountain View Office Shuttle====<br />
We will provide a shuttle from the Mountain View office on Monday, June 11th (10:00 am, 1:00 pm and 3:00 pm). They will depart from the main entrance. We will return to Mountain View on Saturday, June 16 (10:00 am and 11:30 am). Hotel Check in is 4:00 pm, Check out is 11:00 am. Sign ups for shuttle is now closed, please email bmark@mozilla.com to check availability. <br />
<br />
You can get dropped off or park at the office until 10:00 pm Sunday, June 17. There will be normal security patrols however, you should remove valuables from view and secure your vehicle.<br />
<br />
====Commuting daily or from the Bay Area but not taking the Mountain View Office Shuttle?====<br />
Our expectation is that you commute to the hotel just as you would to the office in the Bay Area. If you normally take the BART or MUNI, do that. If you normally drive and pay for parking - that's up to you but hotel parking is not a reimbursable expense for the All Hands.<br />
<br />
=====Parking=====<br />
Self-Parking is available at several lots nearby. [ http://www.fifthandmission.com/map.htm 5th & Mission Garage] is the closest option, recommended by the hotel. It is $34/night. <br />
<br />
The Marriott Marquis offers valet only for $80/night - please do not park valet. <br />
<br />
Mozilla will not reimburse for parking, plan to commute the way you normally would in the city. If you have questions about parking, email bmark@mozilla.com.<br />
<br />
=='''Day Pass Attendee Logistics'''==<br />
Day pass attendees must be pre-registered and on an approved list to attend. Please email bmark@mozilla.com for details on how to get them registered. <br />
<br />
If you have someone attending the All Hands on a day pass, please keep reading for logistics. <br />
<br />
====Badge Pick up====<br />
Day pass guests must wear badges at all times. Access to Lower B2 level (Yerba Buena Ballroom) is not possible without a badge.<br />
<br />
'''Badges can be picked up at the following days/times:'''<br />
*Monday, 12:00 pm - 6:00 pm, Golden Gate Registration, B2 Level; or 6:00 pm - 9:00 pm at City View at Meteron (our welcome reception location)<br />
*Tuesday, 7:00 am - 1:00 pm, Golden Gate Registration, B2 Level; or 10:30 am - 5:00 pm 2nd Floor, Atrium<br />
*Wednesday, 7:00 am - 1:00 pm, Golden Gate Registration, B2 Level; or 7 am - 5 pm 2nd floor Atrium<br />
*Thursday, 7:00 am - 1:00 pm, Golden Gate Registration, B2 Level; or 7 am - 5 pm 2nd floor Atrium<br />
*Friday, 7:00 am - 1:00 pm, Golden Gate Registration, B2 Level; or 7 am - 4 pm 2nd floor Atrium<br />
<br />
Day pass "hosts" may pick up badges in advance on behalf of those attending, should Badge pick up not be available. <br />
<br />
====What is included====<br />
*Lunch for each day the person is registered. <br />
*Evening event on the day person is registered, if selected in registration. <br />
<br />
====What is not included====<br />
*Parking^<br />
*Breakfast<br />
<br />
^Parking<br />
Self-Parking is available at several lots nearby. [ http://www.fifthandmission.com/map.htm 5th & Mission Garage] is the closest option, recommended by the hotel. It is $34/night. The Marriott Marquis offers valet only for $80/night - please do not park valet. Mozilla will not reimburse for parking, plan to commute the way you normally would in the city. If you have questions about parking, email bmark@mozilla.com. <br />
<br />
Managers may approve parking for specific team members, and that cost would be a cost center direct expense.<br />
<br />
=='''Accessibility'''==<br />
<br />
====Marriott Marquis====<br />
<br />
The guestroom tower has accessible elevators, and accessible rooms (on request). The main entrance and pathway to hotel registration are accessible. All meeting space can be access via elevators.<br />
<br />
All but 1 level of meeting space is accessed by the main guestroom elevators. To reach "Lower B2 level" (where the Yerba Buena Ballroom & Nob Hill rooms are located), take the main guestroom elevators to b2 level, cross the tunnel, and a second elevator is on the right to take you down to lower b2 level.<br />
<br />
====Evenings====<br />
The Monday Night reception is at City View, which is located on the 4th floor of the METREON and is accessible from the ground floor via 2 passenger elevators and escalators. There is ADA access from all building entrances. The Friday Night Party is at [https://www.exploratorium.edu/visit/accessibility Exploratorium], which has access to all levels by elevator.<br />
<br />
=='''Immigration'''==<br />
'''Any''' questions on immigration should be sent to immigration@mozilla.com.<br />
<br />
If you are from a country that requires a B-1/B-2 business visitor visa to enter the US, please plan for it early as government processing times constantly change.<br />
<br />
Please visit the following website to learn more about the visa application process and timing for your country: http://travel.state.gov/content/visas/english/visit/visitor.html#overview. Current estimated processing times at the US Embassies and Consulates abroad can be found at: https://travel.state.gov/content/visas/en/general/wait-times.html/<br />
<br />
Some travelers may be eligible to travel to the United States without first applying for a B-1/B-2 visa, if they are eligible for the Visa Waiver Program (VWP or "ESTA"). You are eligible to apply for admission under the Visa Waiver Program (VWP) if you:<br />
<br />
*Intend to enter the United States for 90 days or less for business, pleasure or transit<br />
*Have a valid passport lawfully issued to you by a Visa Waiver Program country: http://www.esta.us/visa_waiver_countries.html<br />
*Have authorization to travel via the Electronic System for Travel Authorization: https://esta.cbp.dhs.gov/<br />
*Arrive via a Visa Waiver Program signatory carrier (all commercial airlines meet this requirement)<br />
*Have a return or onward ticket<br />
*Travel may not terminate in contiguous territory or adjacent islands unless the traveler is a resident of one of those areas<br />
<br />
=====Employee Travel FAQ=====<br />
This [https://mana.mozilla.org/wiki/display/PR/Travel+FAQ FAQ] addresses questions about how to handle security concerns and electronic devices at the border and how to engage with US Customs & Border Protection (CBP). While it specifically focuses on concerns related to travel to the United States, much of this guidance is applicable to travel elsewhere. Mana access required.<br />
<br />
=====Pocket Letter=====<br />
A pocket letter is recommended to keep on hand for those who are entering the United States. It should accompany you whether or not you are required to have a visa to enter. You may request a copy of that letter when you register online. Please contact immigration@mozilla.com if you require a specific letter for your visa application or if you have any questions regarding your citizenship, visa capabilities or travel related questions.<br />
<br />
=====ESTA Point of Contact=====<br />
In the ESTA application you need to give a "U.S. Point of Contact Information". <br />
<br />
Please list Casey McGill as your US Point of Contact.<br />
Address: 331 East Evelyn Avenue, Mountain View, CA 94041 Phone: 918-812-0971<br />
<br />
=='''San Francisco All Hands Expense Policy'''==<br />
1. All "All Hands" Expenses must be submitted on 1 (and only 1) Expense report (e.g. San Francisco All Hands Expense Report)<br />
<br />
2. It must contain only those expenses relative to the All Hands Event (5-10 days of pre-post activity only)<br />
<br />
3. If your submitted expense report for All Hands is submitted outside these guidelines, it will be rejected and you will be asked to re-submit with only All Hands Expenses<br />
<br />
4. The deadline to submit the San Francisco All Hands Expense Report is '''July 31, 2018'''.<br />
<br />
5. Expenses related to team events, parking, room service, mini-bar charges, and food/drink costs above the vouched amounts, will not be approved. <br />
<br />
'''The intention of our all hands are to centrally organize a structure that includes:'''<br />
*Meals (two/day + snacks)<br />
*Transportation^<br />
*Accommodations<br />
*Some number of social events<br />
<br />
Due to the nature of the San Francisco, employees will be expensing specific meals. The amount that can be expensed will be communicated and expenses submitted can not exceed the approved amounts. Any social events that are not part of our central plan will generally be self-organized and funded by participants. <br />
<br />
^Transportation for those based in the Bay Area is limited to "commuting" as you normally would. Expenses for commuting are not reimbursable. We have provided shuttles from the MV office for those based in the south bay. For those who that doesn't make sense to use, commute using your normal means. We will not reimburse for hotel parking. <br />
<br />
=====Cell phone reimbursement policy=====<br />
Cell phone reimbursement must be approved by your manager prior to submitting the expense. Teams will decide for their staff what is appropriate to expense. <br />
<br />
=====Internet reimbursement policy=====<br />
Internet will be provided in all guestrooms and meeting space in all hotels. If you opt to upgrade/add service, those costs are not reimbursable, unless previously approved by your manager and are for business reasons. <br />
<br />
If you have questions about any of this, please reach out to bmark@mozilla.com<br />
<br />
=='''Families/Guests in San Francisco'''==<br />
<br />
Of course our focus, for the majority of the week, will be on Mozilla. Everyone is expected to be present and engaged each day, during work hours (as your schedule dictates). Please do what you can to make sure your loved ones understand the kind of commitment you’ve made. Family should not join you during your work sessions and meals. Please note that what we are able to do for families varies by each location. <br />
<br />
''Volunteers, summer interns and outreachy interns will be sharing rooms and are unable to invite family to join them.'' <br />
<br />
====Quick summary logistics====<br />
<br />
'''Air Travel''': Family travel can be booked/coordinated through Egencia by calling direct; or on your own. Employees do need to book via Egencia regardless of how families are booked.<br />
<br />
'''Hotel''': They are welcome to stay with you, however, any additional room expenses will be yours to cover. All room rates are based upon single occupancy and costs to add guests vary by hotel. Breakfast is not included in any of the guest room rates. Once hotel reservations are made, we will provide a link or contact add guests.<br />
<br />
'''Meals''': Breakfast will be provided to All Hands registered guests, for lunch families are on their own. They are invited to join our Monday & Friday evening festivities, we just ask that you let us know they'll be there in registration.<br />
<br />
=='''Urgent Care & Hospitals'''==<br />
Mozilla provides emergency medical accident and illness cover for all global MoCo & MoFo employees/interns and their dependents. You can view more information on [https://mana.mozilla.org/wiki/display/PR/Travel+Insurance+-+Business Mana]. This coverage begins at the time the you leave home to start your business trip. It also has a provision for a 14 day extension for leisure travel outside of the business travel. If you have additional questions, please email benefits@mozilla.com. <br />
<br />
Mozilla does not cover travel insurance for elancers, upworkers, contractors, vendors, or volunteers/community members.<br />
<br />
Here is list of hospitals and urgent care facilities in San Francisco that are in-network for our global travel insurance with UHCG for any non-US employee (MoCo and MoFo) who needs care. This is also available on the [https://mana.mozilla.org/wiki/display/PR/Travel+insurance%3A+Business?preview=/33099972/77896660/Hospital%20%26%20Urgent%20Care%20Facilities%20in%20San%20Francisco%2C%20CA.PDF mana]<br />
<br />
'''Saint Francis Memorial Hospital'''<br />
900 Hyde Street<br />
San Francisco<br />
California<br />
United States<br />
Postal Code: 94109<br />
International Number: 1 415 353 6000<br />
Local Number: 415 353 6000<br />
Website: www.dignityhealth.org<br />
Comments: This acute care hospital offers a broad range of medical specialties. The hospital is especially known<br />
for the following specialties: cardiology, endocrinology, nephrology, neurology and neurosurgery, orthopedics,<br />
pulmonology, oncology and rheumatology. The facility has 24/7 ER and advanced diagnostics at an international<br />
standard, including a 3 Tesla magnetic resonance imaging (MRI) system, a 128-slice computed tomography (CT)<br />
scanner and a 4D Ultrasound machine. The hospital is approximately 1.4 miles or 8 minutes of drive from San<br />
Francisco Marriott Marquis.<br />
<br />
'''California Pacific Medical Center'''<br />
(Sutter Health CPMC Davies Campus)<br />
Castro Street &, Duboce Avenue<br />
San Francisco<br />
California<br />
United States<br />
Postal Code: 94114<br />
International Number: 1 415 600 6000<br />
Local Number: 415 600 6000<br />
Website: www.cpmc.org<br />
Email: cpmcadmin@sutterhealth.org<br />
Comments: This multi-specialty medical and surgical facility is a full-service acute care facility offering 24/7 ER and broad range of advanced diagnostic capabilities. The hospital is especially known for the following specialties: orthopedics, cardiology, endocrinology, nephrology, neurology and neurosurgery, pulmonology. Both inpatient/outpatient medical services are readily available. The hospital is approximately 2.3 miles or 11 minutes of drive from San Francisco Marriott Marquis.<br />
<br />
'''Concentra Urgent Care'''<br />
2 Connecticut Street<br />
San Francisco<br />
California<br />
United States<br />
Postal Code: 94107<br />
International Number: 1 415 621 5055<br />
Local Number: 415 621 5055<br />
Fax Number: 1 415 621 0611<br />
Website: www.concentra.com<br />
Comments: This urgent care facility should be used for primary care, primarily to treat injuries or minor illnesses. The center offers occupational health, physical exams, test and preventive health screenings, X-rays and lab tests. The hours of operation are Monday to Friday from 7am to 6pm and Saturday from 9am to 3pm. Walk-ins are welcomed at this location. The hospital is approximately 2.2 miles or 10 minutes of drive from San Francisco Marriott Marquis.<br />
<br />
'''Golden Gate Urgent Care'''<br />
1600 Market Street<br />
San Francisco<br />
California<br />
United States<br />
Postal Code: 94102<br />
International Number: 1 415 746 1812<br />
Local Number: 415 746 1812<br />
Website: www.goldengateurgentcare.com<br />
Comments: Urgent care facility offers Adult and Pediatric Care, on-Site Digital X-Ray, on-Site Lab, Vaccinations and Flu Shots. The hours of operation are from Monday to Friday from 8am to 8pm, Saturday & Sunday from 8am to 6pm. The center is approximately 2.4 miles or 15 minutes of drive from San Francisco Marriott Marquis.<br />
<br />
=='''Extracurricular Activities'''==<br />
Costs for these activities are self-funded and can not be expensed. Feel free to add activities and invite others.<br />
<br />
* '''[https://public.etherpad-mozilla.org/p/sf-day-hike-2018 Hiking!]'''<br />
* '''[https://docs.google.com/document/d/1X1SdrUQWUiE82vfu-pjff-TZb7poLvPRZOIaPzjaUqI/ Running!]'''<br />
* '''Major League Baseball! Houston Astros vs Oakland Athletics, June 12 19:05 PDT''' (Sorry, sign-ups are now closed)<br />
* '''[https://www.museumoficecream.com/ Museum of Ice Cream]''' (required tickets in advance, already sold out for the entire week)<br />
* '''[https://docs.google.com/spreadsheets/d/18-omIrw_wPCE7Y3-7bqidBrKudLIA1f7pBbZeXMlG_M/edit?usp=sharing SF MoMA Magritte exhibit - sign up by Monday 5pm PT, June 4]'''<br />
* '''[https://docs.google.com/spreadsheets/d/1La7_bnyaEevreT0cegLYSSC-0NC_Syx9121YiMioOrM/edit?usp=sharing List of Museums near the Mariot Marquis] with admission prices and hours'''</div>Dbaronhttps://wiki.mozilla.org/index.php?title=Standards/Participating_in_a_W3C_Working_Group&diff=1194877Standards/Participating in a W3C Working Group2018-05-31T23:23:52Z<p>Dbaron: /* Technical tips */ start section, with tip about connecting github account</p>
<hr />
<div>== Ways to participate (to join or not to join) ==<br />
<br />
W3C working groups have a defined membership: people can become a member of a working group or community group by being nominated by a W3C member company, by being invited by the chairs of the group (an invited expert), or by being a W3C staff member placed on the group by the W3C. However, most W3C working groups have most of their technical discussion on public mailing lists, which means that non-members can participate in many of the activities of the group. So, when you approach a W3C working group, you could decide to do so by becoming a member of the group or just by joining the public mailing list and participating in the discussion.<br />
<br />
How should one choose between these alternatives? While there's a good bit of variation between groups depending on the [http://www.w3.org/Consortium/activities charter] of the group, its chair(s), and the other participants in the group, I suggest considering the following factors:<br />
* being a member of the group signals Mozilla's support for a group to others (e.g., W3C staff, others in the industry). (This means that if the group is working on something we don't like, being a member may confuse other companies into thinking that Mozilla supports or is contributing to the work of the group).<br />
* members of the group may (depending on the charter of the group) have more ability to influence the decisions and the output of the group<br />
* if you want to attend face-to-face meetings or teleconferences of the group, you should be a member of the group<br />
* the group may have expectations that members participate (e.g., by attending phone or face-to-face meetings, by keeping up with certain aspects of the discussion). These vary by group and are described in the "Participation" section of the group's charter.<br />
* some mailing lists may require being a member of the group to subscribe (although this is rare), even when the archives are publicly viewable<br />
* becoming a member of the working group involves making some patent commitments, which may make other participants more comfortable accepting your contributions<br />
* other members of the group may expect somebody representing Mozilla is responsible for implementation work / decisions in Gecko; if you're not, you may wish to consider being extra clear about what your role is<br />
<br />
When you decide you want to participate:<br />
* If you want to just join the [http://lists.w3.org/Archives/Public/ public mailing list]:<br />
*# Send an email to "list-name-request@w3.org" with the subject "subscribe". (Don't forget to add the "-request" to the end of the list name.)<br />
*# Reply to the automated reply.<br />
* If you want to become a member of the working group, and you work for Mozilla:<br />
*# Make sure you have a W3C member access account associated with Mozilla:<br />
*#* if you don't already have a W3C user account, [https://www.w3.org/accounts/request create one], and choose '''Mozilla Foundation''' as the affiliation<br />
*#* if you have an W3C user account associated with a previous employer or as an invited expert, [https://www.w3.org/Systems/db/userInfo#affiliation change the affiliation of that account] to '''Mozilla Foundation'''<br />
*# Contact Mozilla's Advisory Committee Representative, [[User:Dbaron|David Baron]], and ask him to add you to the group.<br />
<br />
== Suggestions for participation ==<br />
<br />
* Avoid making promises you can't keep, even if pressured to do so.<br />
* Try to avoid speaking on behalf of Mozilla. If the process or other participants in the working group want you to speak on behalf of Mozilla, question such process or participants. However, rather than staying silent in such a situation, it's probably a good idea to both state your position and clearly state how much Mozilla consensus there is behind that position. Though it's not an ideal situation, it's ok for Mozilla's employees to disagree with each other on the best way to move the Web forward and implement Mozilla's mission.<br />
<br />
== Technical tips ==<br />
<br />
* You should connect your github account to your W3C account at https://www.w3.org/users/myprofile/connectedaccounts in order to make IPR-checking bots (which some working groups use) happy.<br />
<br />
== Suggestions for chairing ==<br />
<br />
If you end up as the chair of a group, you should become more familiar with the process, since you'll sometimes be responsible for enforcing them (along with a team contact, if the group is a working group). Some documents that are helpful are:<br />
* [https://www.w3.org/Consortium/Process/ W3C Process] (for working groups)<br />
* [https://www.w3.org/community/about/agreements/#cgroups community group process] (for community groups)<br />
* [https://www.w3.org/Guide/ The Art of Consensus: A Guidebook for W3C Group Chairs and Participants]<br />
* [https://www.w3.org/Consortium/cepc/ W3C Code of Ethics and Professional Conduct]</div>Dbaronhttps://wiki.mozilla.org/index.php?title=Gecko:Overview&diff=1193211Gecko:Overview2018-05-02T21:34:33Z<p>Dbaron: /* Document rendering pipeline */ one more talk</p>
<hr />
<div>This document attempts to give an overview of the different parts of<br />
Gecko, what they do, and why they do it, say where the code for them is<br />
within the repository, and link to more specific documentation (when<br />
available) covering the details of that code. '''It is not yet complete.''' Maintainers of these<br />
areas of code should correct errors, add information, and add links to<br />
more detailed documentation (since this document is intended to remain<br />
an overview, not complete documentation).<br />
<br />
__TOC__<br />
<br />
== Browsers, Frames, and Document Navigation ==<br />
<br />
=== Docshell ===<br />
<br />
The user of a Web browser can change the page shown in that browser in<br />
many ways: by clicking a link, loading a new URL, using the forward and<br />
back buttons, or other ways. This can happen inside a space we'll call<br />
a '''browsing context'''; this space can be a browser window, a tab, or a frame<br />
or iframe within a document. The toplevel data structures within Gecko<br />
represent this browsing context; they contain other data structures<br />
representing the individual pages displayed inside of it (most<br />
importantly, the current one). In terms of implementation, these two<br />
types of navigation, the top level of a browser and the frames within<br />
it, largely use the same data structures.<br />
<br />
In Gecko, the '''docshell''' is the toplevel object responsible for<br />
managing a single browsing context. It, and the associated '''session history''' code, <br />
manage the navigation between pages inside of a<br />
docshell. (Note the difference between session history, which is a<br />
sequence of pages in a single browser session, used for recording information<br />
for back and forward navigation, and global history, which is the<br />
history of pages visited and associated times, regardless of browser<br />
session, used for things like link coloring and address autocompletion.)<br />
<br />
There are relatively few objects in Gecko that are associated with a<br />
docshell rather than being associated with a particular one of the pages<br />
inside of it. Most such objects are attached to the docshell. An important object associated with the docshell is the nsGlobalWindowOuter which is what the HTML5 spec refers to as a WindowProxy (into which Window objects, as implemented by nsGlobalWindowInner, are loaded). See the DOM section below for more information on<br />
this.<br />
<br />
The most toplevel object for managing the contents of a particular page<br />
being displayed within a docshell is a document viewer (see layout).<br />
Other important objects associated with this presentation are the<br />
document (see DOM) and the pres(entation) shell and pres(entation)<br />
context (see layout).<br />
<br />
[[File:WebNavigation.png|thumb|400px|<xul:browser>, frameloader and docshell in single process configuration]]<br />
<br />
Docshells are organized into a tree. If a docshell has a non-null parent, then it corresponds to a subframe in whatever page is currently loaded in the parent docshell, and the corresponding subframe element (for example, an iframe) is called a '''browsing context container'''. In Gecko, a browsing context container would implement <code>[https://dxr.mozilla.org/mozilla-central/rev/f9a5e9ed62103c84e4cde915f4d08f1ce71be83e/dom/base/nsIFrameLoader.idl#271 nsIFrameLoaderOwner]</code> to hold a '''frameloader''', which holds and manages the docshell. <br />
<br />
One of the most interfaces docshell implemented is <code>[https://dxr.mozilla.org/mozilla-central/source/docshell/base/nsIWebNavigation.idl nsIWebNavigation]</code>. It defines major functions of a browsing context, such as <code>loadURI</code> / <code>goBack</code> / <code>goForward</code> and <code>reload</code>. In single process configuration of desktop Firefox, <code><xul:browser></code> (which represents a tab) operates on docshell through <code>nsIWebNavigation</code>, as shown in the right figure.<br />
<br />
* code: mozilla/docshell/<br />
* bugzilla: Core::Document Navigation<br />
* documentation: [[DocShell:Home Page]]<br />
<br />
=== Session History ===<br />
<br />
In order to keep the session history of subframes after the root document is unloaded and docshells of subframes are destroyed, only the root docshell of a docshell tree manages the session history (this does not match the conceptual model in the HTML5 spec and may be subject to change).<br />
<br />
As an example to explain the structure of session history implementation in Gecko, consider there's a tab A, which loads document 1; in document 1, there are iframe B & C, which loads document 2 & 3, respectively. Later, an user navigates iframe B to document 4. The following figures show the conceptual model of the example, and the corresponding session history structure.<br />
<br />
{| <br />
| [[File:BrowsingContextExample1.png|thumb|190px|Conceptual model representation; color denotes current visible active documents]]<br />
| [[File:SHistoryExample1.png|thumb|180px|Session history structure; color denotes current transaction / entries]]<br />
|}<br />
<br />
In Gecko, a [https://dxr.mozilla.org/mozilla-central/source/docshell/shistory/nsSHistory.h session history] object holds a list of [https://dxr.mozilla.org/mozilla-central/source/docshell/shistory/nsSHTransaction.h transactions] (denoted as T1 & T2 in the figure); each transaction points to a tree of [https://dxr.mozilla.org/mozilla-central/source/docshell/shistory/nsSHEntry.h entries]; each entry records the docshell it associated to, and a URL. Now that if we navigate the tab to a different root document 5, which includes an iframe D with document 6, then it becomes:<br />
<br />
{| <br />
| [[File:BrowsingContextExample2.png|thumb|275px|Conceptual model representation]]<br />
| [[File:SHistoryExample2.png|thumb|250px|Session history structure]]<br />
|}<br />
<br />
=== Embedding ===<br />
<br />
To be written (and maybe rewritten if we get an IPC embedding API).<br />
<br />
[[File:WebNavigationE10S.png|thumb|500px|<xul:remote-browser>, frameloader and docshell in multiprocess configuration. The horizontal dash-lines represent inter-process communication]]<br />
<br />
=== Multi-process and IPC ===<br />
<br />
In a multi-process desktop Firefox, a tab is managed by <code>[https://dxr.mozilla.org/mozilla-central/source/toolkit/content/widgets/remote-browser.xml <xul:remote-browser>]</code>. It still operates on nsIWebNavigation, but in this case the docshell is in a remote process and can not be accessed directly. The encapsulation of remote nsIWebNavigation is done by the javascript-implemented <code>[https://dxr.mozilla.org/mozilla-central/source/toolkit/components/remotebrowserutils/RemoteWebNavigation.js RemoteWebNavigation]</code>.<br />
<br />
In this configuration, the frameloader of a root docshell lives in parent process, so it can not access docshell directly either. Instead, it holds a <code>[https://dxr.mozilla.org/mozilla-central/source/dom/ipc/TabParent.h TabParent]</code> instance to interact with <code>[https://dxr.mozilla.org/mozilla-central/source/dom/ipc/TabChild.h TabChild]</code> in child-process. At C/C++ level, the communication across processes for a single tab is through the '''PBrowser''' IPC protocol implemented by TabParent and TabChild, while at the javascript level it's done by '''message manager''' (which is ontop of PBrowser). RemoteWebNavigation, for example, sends messages to <code>[https://dxr.mozilla.org/mozilla-central/source/toolkit/content/browser-child.js browser-child.js]</code> in content process through message manager.<br />
<br />
== Networking ==<br />
<br />
The network library Gecko uses is called Necko. Necko APIs are largely organized around three concepts: '''URI objects''', '''protocol handlers''', and '''channels'''.<br />
<br />
=== Protocol handlers ===<br />
A '''protocol handler''' is an XPCOM service associated with a particular URI scheme or network protocol. Necko includes protocol handlers for HTTP, FTP, the data: URI scheme, and various others. Extensions can implement protocol handlers of their own.<br />
<br />
A protocol handler implements the <code>[https://dxr.mozilla.org/mozilla-central/source/netwerk/base/nsIProtocolHandler.idl nsIProtocolHandler]</code> API, which serves three primary purposes:<br />
# Providing metadata about the protocol (its security characteristics, whether it requires actual network access, what the corresponding URI scheme is, what TCP port the protocol uses by default).<br />
# Creating URI objects for the protocol's scheme.<br />
# Creating channel objects for the protocol's URI objects<br />
<br />
Typically, the built-in I/O service (<code>[https://dxr.mozilla.org/mozilla-central/source/netwerk/base/nsIIOService2.idl nsIIOService]</code>) is responsible for finding the right protocol handler for URI object creation and channel creation, while a variety of consumers queries protocol metadata. Querying protocol metadata is the recommended way to handle any sort of code that needs to have different behavior for different URI schemes. In particular, unlike whitelists or blacklists, it correctly handles the addition of new protocols.<br />
<br />
A service can register itself as a protocol handler by registering for the contract ID <code>"@mozilla.org/network/protocol;1?name=SSSSS"</code> where <code>SSSS</code> is the URI scheme for the protocol (e.g. "http", "ftp", and so forth).<br />
<br />
=== URI objects ===<br />
URI objects, which implement the <code>[https://dxr.mozilla.org/mozilla-central/source/netwerk/base/nsIURI.idl nsIURI]</code> API, are a way of representing URIs and IRIs. Their main advantage over strings is that they do basic syntax checking and canonicalization on the URI string that they're provided with. They also provide various accessors to extract particular parts of the URI and provide URI equality comparisons. URIs that correspond to hierarchical schemes implement the additional <code>[https://dxr.mozilla.org/mozilla-central/source/netwerk/base/nsIURL.idl nsIURL]</code> interface, which exposes even more accessors for breaking out parts of the URI.<br />
<br />
URI objects are typically created by calling the <code>newURI</code> method on the I/O service, or in C++ by calling the <code>NS_NewURI</code> utility function. This makes sure to create the URI object using the right protocol handler, which ensures that the right kind of object is created. Direct creation of URIs via <code>createInstance</code> is reserved for protocol handler implementations.<br />
<br />
=== Channels ===<br />
[https://dxr.mozilla.org/mozilla-central/source/netwerk/base/nsIChannel.idl Channels] are the Necko representation of a single request/response interaction with a server. A channel is created by calling the <code>newChannel</code> method on the [https://dxr.mozilla.org/mozilla-central/source/netwerk/base/nsIIOService.idl I/O service], or in C++ by calling the <code>[https://dxr.mozilla.org/mozilla-central/search?q=function%3ANS_NewChannel&case=true NS_NewChannel]</code> utility function. The channel can then be configured as needed, and finally its <code>asyncOpen</code> method can be called. This method takes an <code>[https://dxr.mozilla.org/mozilla-central/source/netwerk/base/nsIStreamListener.idl nsIStreamListener]</code> as an argument.<br />
<br />
If <code>asyncOpen</code> has returned successfully, the channel guarantees that it will asynchronously call the <code>onStartRequest</code> and <code>onStopRequest</code> methods on its stream listener. This will happen even if there are network errors that prevent Necko from actually performing the requests. Such errors will be reported in the channel's status and in the <code>status</code> argument to <code>onStopRequest</code>.<br />
<br />
If the channel ends up being able to provide data, it will make one or more <code>onDataAvailable</code> on its listener after calling <code>onStartRequest</code> and before calling <code>onStopRequest</code>. For each call, the listener is responsible for either returning an error or reading the entire data stream passed in to the call.<br />
<br />
If an error is returned from either <code>onStartRequest</code> or <code>onDataAvailable</code>, the channel must act as if it has been canceled with the corresponding error code.<br />
<br />
A channel has two URI objects associated with it. The <code>originalURI</code> of the channel is the URI that was originally passed to <code>newChannel</code> to create the channel that then had <code>asyncOpen</code> called on it. The <code>URI</code> is the URI from which the channel is reading data. These can be different in various cases involving protocol handlers that forward network access to other protocol handlers, as well as in situations in which a redirect occurs (e.g. following an HTTP 3xx response). In redirect situations, a new channel object will be created, but the originalURI will be propagated from the old channel to the new channel.<br />
<br />
Note that the <code>nsIRequest</code> that's passed to onStartRequest must match the one passed to onDataAvailable and onStopRequest, but need not be the original channel that asyncOpen was called on. In particular, when an HTTP redirect happens the request argument to the callbacks will be the post-redirect channel.<br />
<br />
TODO: crypto?<br />
<br />
== Document rendering pipeline ==<br />
<br />
Some of the major components of Gecko can be described as steps on the<br />
path from an HTML document coming in from the network to the graphics<br />
commands needed to render that document. An HTML document is a<br />
serialization of a tree structure. (FIXME: add diagram) The HTML<br />
parser and content sink create an in-memory representation of this tree,<br />
which we call the '''DOM tree''' or '''content tree'''.<br />
Many JavaScript APIs operate on the content tree. Then, in<br />
layout, we create a second tree, the '''frame tree''' (or<br />
'''rendering tree''') that is a similar shape to the content tree,<br />
but where each node in the tree represents a rectangle (except in SVG<br />
where they represent other shapes). We then compute the positions of<br />
the nodes in the frame tree (called '''frames''') and paint them<br />
using our cross-platform graphics APIs (which, underneath, map to<br />
platform-specific graphics APIs).<br />
<br />
Further documentation:<br />
* Talk: Fast CSS: How Browsers Lay Out Web Pages (David Baron, 2012-03-11): [https://dbaron.org/talks/2012-03-11-sxsw/slide-1.xhtml slideshow], [https://dbaron.org/talks/2012-03-11-sxsw/master.xhtml all slides], [http://audio.sxsw.com/2012/podcasts/11-ACC-Fast_CSS_How_Browser_Layout.mp3 audio (MP3)], [https://schedule.sxsw.com/2012/events/event_IAP12909 session page]<br />
* Talk: Efficient CSS Animations (an updated version of the previous talk with a slightly different focus) (David Baron, 2014-06-04): [https://dbaron.org/talks/2014-06-04-cssday/slide-1.xhtml slideshow], [https://dbaron.org/talks/2014-06-04-cssday/master.xhtml all slides], [http://vimeo.com/channels/cssday/103108124 video]<br />
* Talk: [https://air.mozilla.org/benoit-girard-gecko-rendering/ Overview of the Gecko Rendering Pipeline] (Benoit Girard, 2014-10-14)<br />
<br />
=== Parser ===<br />
<br />
The parser's job is to transform a character stream into a tree<br />
structure, with the help of the content sink classes.<br />
<br />
HTML is parsed using a parser implementing the parsing algorithm in the<br />
HTML specification (starting with HTML5). Much of this parser is<br />
translated from Java, and changes are made to the Java version. This<br />
parser in parser/html/. The parser is driven by the output of the networking layer (see nsHtml5StreamParser::OnDataAvailable). The HTML5 parser is capable of parsing off the main thread which is the normal case. It also parses on the main thread to be able to synchronously handle things such as innerHTML modifications.<br />
<br />
The codebase still has the previous generation HTML parser, which is<br />
still used for a small number of things, though we hope to be able to<br />
remove it entirely soon. This parser is in parser/htmlparser/.<br />
<br />
XML is parsed using the expat library (parser/expat/) and code that<br />
wraps it (parser/xml/). This is a non-validating parser; however, it<br />
loads certain DTDs to support XUL localization.<br />
<br />
=== DOM / Content ===<br />
<br />
The content tree or DOM tree is the central data structure for Web<br />
pages. It is a tree structure, initially created from the tree<br />
structure expressed in the HTML or XML markup. The nodes in the tree<br />
implement major parts of the DOM (Document Object Model) specifications.<br />
The nodes themselves are part of a class hierarchy rooted at<br />
<code>nsINode</code>; different derived classes are used for things such<br />
as text nodes, the document itself, HTML elements, SVG elements, etc.,<br />
with further subclasses of many of these types (e.g., for specific HTML<br />
elements). Many of the APIs available to script running in Web pages<br />
are associated with these nodes. The tree structure persists while the<br />
Web pages is displayed, since it stores much of state associated with<br />
the Web page. The code for these nodes lives in the content/ directory.<br />
<br />
The DOM APIs are not threadsafe. DOM nodes can be accessed only from<br />
the main thread (also known as the UI thread (user interface thread)) of<br />
the application.<br />
<br />
There are also many other APIs available to Web pages that are not APIs<br />
on the nodes in the DOM tree. Many of these other APIs also live in the<br />
same directories, though some live in content/ and some in dom/. These<br />
include APIs such as the DOM event model.<br />
<br />
The dom/ directory also includes some of the code needed to expose Web<br />
APIs to JavaScript (in other words, the glue code between JavaScript and<br />
these APIs). For an overview, see [https://ask.mozilla.org/question/390/how-is-the-web-exposed-dom-implemented/ DOM API Implementation]. See [[#Scripting|Scripting]] below for details of the JS engine.<br />
<br />
TODO: Internal APIs vs. DOM APIs.<br />
<br />
TODO: Mutation observers / document observers.<br />
<br />
TODO: Reference counting and cycle collection.<br />
<br />
TODO: specification links<br />
<br />
=== Style System ===<br />
<br />
==== Quantum CSS (Stylo) ====<br />
<br />
Starting with Firefox 57 and later, Gecko makes use of the parallel style system written in Rust that comes from Servo. There's an [https://hacks.mozilla.org/2017/08/inside-a-super-fast-css-engine-quantum-css-aka-stylo/ overview] of this with graphics to help explain what's going on. The [https://github.com/servo/servo/wiki/Layout-Overview Servo wiki] has some more details.<br />
<br />
==== Gecko ====<br />
<br />
The rest of the style section section describes the Gecko style system used in Firefox 56 and earlier. Some bits may still apply, but it likely needs revising.<br />
<br />
In order to display the content, Gecko needs to compute the styles<br />
relevant to each DOM node. It does this based on the model described in<br />
the CSS specifications: this model applies to style specified in CSS<br />
(e.g. by a 'style' element, an 'xml-stylesheet' processing instruction<br />
or a 'style' attribute),<br />
style specified by presentation attributes, and the default style<br />
specified by our own user agent style sheets. There are two major<br />
sets of data structures within the style system:<br />
* first, data structures that represent sources of style data, such as CSS style sheets or data from stylistic HTML attributes<br />
* second, data structures that represent computed style for a given DOM node.<br />
These sets of data structures are mostly distinct (for example, they<br />
store values in different ways).<br />
<br />
The loading of CSS style sheets from the network is managed by the <br />
[https://dxr.mozilla.org/mozilla-central/source/layout/style/Loader.h CSS loader]; <br />
they are then tokenized by the <br />
[https://dxr.mozilla.org/mozilla-central/source/layout/style/nsCSSScanner.h CSS scanner] <br />
and parsed by the <br />
[https://dxr.mozilla.org/mozilla-central/source/layout/style/nsCSSParser.h CSS parser]. <br />
Those that are attached to the document also expose APIs to<br />
script that are known as the CSS Object Model, or CSSOM.<br />
<br />
The style sheets that apply to a document are managed by a class called<br />
the [https://dxr.mozilla.org/mozilla-central/source/layout/style/nsStyleSet.h style set].<br />
The style set interacts with the different types of<br />
style sheets (representing CSS style sheets, presentational<br />
attributes, and 'style' attributes) through two interfaces:<br />
[http://dxr.mozilla.org/mozilla-central/source/layout/style/nsIStyleSheet.h nsIStyleSheet] for basic management of style sheets and<br />
[http://dxr.mozilla.org/mozilla-central/source/layout/style/nsIStyleRuleProcessor.h nsIStyleRuleProcessor] for getting the style data out of them. Usually<br />
the same object implements both interfaces, except in the most important<br />
case, CSS style sheets, where there is a single rule processor for all<br />
of the CSS style sheets in each origin (user/UA/author) of the CSS cascade.<br />
<br />
The computed style data for an element/frame are exposed to the rest of<br />
Gecko through the class mozilla::ComputedStyle (previously called<br />
nsStyleContext). Rather than having a member variable for each<br />
CSS property, it breaks up the properties into groups of related<br />
properties called style structs. These style structs obey the rule that<br />
all of the properties in a single struct either inherit by default (what<br />
the CSS specifications call "Inherited: yes" in the definition of<br />
properties; we call these inherited structs) or all are not inherited by<br />
default (we call these reset structs). Separating the properties in<br />
this way improves the ability to share the structs between similar<br />
ComputedStyle objects and reduce the amount of memory needed to store<br />
the style data. The ComputedStyle API exposes a method for getting each<br />
struct, so you'll see code like<br />
<code>sc->GetStyleText()->mTextAlign</code> for getting the value of the<br />
text-align CSS property. (Frames (see the Layout section below) also<br />
have the same<br />
GetStyle* methods, which just forward the call to the frame's<br />
ComputedStyle.)<br />
<br />
The ComputedStyles form a tree structure, in a shape somewhat like the<br />
content tree (except that we coalesce identical sibling ComputedStyles<br />
rather than keeping two of them around; if the parents have been<br />
coalesced then this can apply recursively and coalasce cousins, etc.;<br />
we do not coalesce parent/child ComputedStyles).<br />
The parent of a ComputedStyle has the style data that the ComputedStyle<br />
inherits from when CSS inheritance occurs. This means that the parent<br />
of the ComputedStyle for a DOM element is generally the ComputedStyle<br />
for that DOM element's parent, since that's how CSS says inheritance<br />
works.<br />
<br />
The process of turning the style sheets into computed style data goes<br />
through three main steps, the first two of which closely relate to the<br />
[http://dxr.mozilla.org/mozilla-central/source/layout/style/nsIStyleRule.h nsIStyleRule] interface, which represents an immutable source of style<br />
data, conceptually representing (and for CSS style rules, directly<br />
storing) a set of property:value pairs. (It is similar to the idea of a<br />
CSS style rule, except that it is immutable; this immutability allows<br />
for significant optimization. When a CSS style rule is changed through<br />
script, we create a new style rule.)<br />
<br />
The first step of going from style sheets to computed style data is<br />
finding the ordered sequence of style rules that apply to an element.<br />
The order represents which rules override which other rules: if two<br />
rules have a value for the same property, the higher ranking one wins.<br />
(Note that there's another difference from CSS style rules: declarations<br />
with !important are represented using a separate style rule.) This is<br />
done by calling one of the nsIStyleRuleProcessor::RulesMatching methods.<br />
The ordered sequence is stored in a<br />
[http://en.wikipedia.org/wiki/Trie trie] called the rule tree: the path<br />
from the root of the rule tree to any (leaf or non-leaf) node in the<br />
rule tree represents a sequence of rules, with the highest ranking<br />
farthest from the root. Each rule node (except for the root) has a<br />
pointer to a rule, but since a rule may appear in many sequences, there<br />
are sometimes many rule nodes pointing to the same rule. Once we have<br />
this list we create a ComputedStyle (or find an appropriate existing<br />
sibling) with the correct parent pointer (for inheritance) and rule node<br />
pointer (for the list of rules), and a few other pieces of information<br />
(like the pseudo-element).<br />
<br />
The second step of going from style sheets to computed style data is<br />
getting the winning property:value pairs from the rules. (This only<br />
provides property:value pairs for some of the properties; the remaining<br />
properties will fall back to inheritance or to their initial values<br />
depending on whether the property is inherited by default.) We do this<br />
step (and the third) for each style struct, the first time it is needed.<br />
This is done in nsRuleNode::WalkRuleTree, where we ask each style rule<br />
to fill in its property:value pairs by calling its MapRuleInfoInto<br />
function. When called, the rule fills in only those pairs that haven't<br />
been filled in already, since we're calling from the highest priority<br />
rule to the lowest (since in many cases this allows us to stop before<br />
going through the whole list, or to do partial computation that just<br />
adds to data cached higher in the rule tree).<br />
<br />
The third step of going from style sheets to computed style data (which<br />
various caching optimizations allow us to skip in many cases) is<br />
actually doing the computation; this generally means we transform the<br />
style data into the data type described in the "Computed Value" line in<br />
the property's definition in the CSS specifications. This<br />
transformation happens in functions called nsRuleNode::Compute*Data,<br />
where the * in the middle represents the name of the style struct. This<br />
is where the transformation from the style sheet value storage format to<br />
the computed value storage format happens.<br />
<br />
Once we have the computed style data, we then store it: if a style struct<br />
in the computed style data doesn't<br />
depend on inherited values or on data from other style structs, then we<br />
can cache it in the rule tree (and then reuse it, without recomputing<br />
it, for any ComputedStyles pointing to that rule node). Otherwise, we<br />
store it on the ComputedStyle (in which case it may be shared<br />
with the ComputedStyle's descendant ComputedStyles).<br />
This is where keeping inherited and<br />
non-inherited properties separate is useful: in the common case of<br />
relatively few properties being specified, we can generally cache the<br />
non-inherited structs in the rule tree, and we can generally share the<br />
inherited structs up and down the ComputedStyle tree.<br />
<br />
The ownership models in style sheet structures are a mix of reference<br />
counted structures (for things accessible from script) and directly<br />
owned structures. ComputedStyles are reference counted, and own their<br />
parents (from which they inherit), and rule nodes are garbage collected<br />
with a simple mark and sweep collector (which often never needs to run).<br />
<br />
* code: [http://dxr.mozilla.org/mozilla-central/source/layout/style/ layout/style/], where most files have useful one line descriptions at the top that show up in DXR<br />
* Bugzilla: Style System (CSS)<br />
* specifications<br />
** [http://www.w3.org/TR/CSS21/ CSS 2.1]<br />
** [http://www.w3.org/TR/css-2010/ CSS 2010, listing stable css3 modules]<br />
** [http://dev.w3.org/csswg/ CSS WG editors drafts] (often more current, but sometimes more unstable than the drafts on the technical reports page)<br />
** [http://dbaron.org/mozilla/visited-privacy Preventing attacks on a user's history through CSS :visited selectors]<br />
* documentation<br />
** [http://www-archive.mozilla.org/newlayout/doc/style-system.html style system documentation] (somewhat out of date)<br />
<br />
=== Layout ===<br />
<br />
Much of the layout code deals with operations on the frame tree (or<br />
rendering tree). In the frame tree, each node represents a rectangle<br />
(or, for SVG, other shapes). The frame tree has a shape similar to the<br />
content tree, since many content nodes have one corresponding frame,<br />
though it differs in a few ways, since some content nodes have more than<br />
one frame or don't have any frames at all. When elements are<br />
display:none in CSS or undisplayed for certain other reasons, they won't<br />
have any frames. When elements are broken across lines or pages, they<br />
have multiple frames; elements may also have multiple frames when<br />
multiple frames nested inside each other are needed to display a single<br />
element (for example, a table, a table cell, or many types of form<br />
controls).<br />
<br />
Each node in the frame tree is an instance of a class derived from<br />
<code>nsIFrame</code>. As with the content tree, there is a substantial<br />
type hierarchy, but the type hierarchy is very different: it includes<br />
types like text frames, blocks and inlines, the various parts of tables,<br />
and the various types of HTML form controls.<br />
<br />
Frames are allocated within an arena owned by the pres shell. Each<br />
frame is owned by its parent; frames are not reference counted, and code<br />
must not hold on to pointers to frames. To mitigate potential security<br />
bugs when pointers to destroyed frames, we use<br />
[http://robert.ocallahan.org/2010/10/mitigating-dangling-pointer-bugs-using_15.html frame poisoning], which takes two parts. When a frame is destroyed<br />
other than at the end of life of the presentation, we fill its memory<br />
with a pattern consisting of a repeated pointer to inaccessible memory,<br />
and then put the memory on a per-frame-class freelist. This means that<br />
if code accesses the memory through a dangling pointer, it will either<br />
crash quickly by dereferencing the poison pattern or it will find a<br />
valid frame.<br />
<br />
Like the content tree, frames must be accessed only from the UI thread.<br />
<br />
The frame tree should not store any important data. While it does<br />
usually persist while a page is being displayed, frames are often<br />
destroyed and recreated in response to certain style changes, and in the<br />
future we may do the same to reduce memory use for pages that are<br />
currently inactive. There were a number of cases where this rule was<br />
violated in the past and we stored important data in the frame tree;<br />
however, most (though not quite all) such cases are now fixed.<br />
<br />
The rectangle represented by the frame is what CSS calls the element's<br />
border box. This is the outside edge of the border (or the inside edge<br />
of the margin). The margin lives outside the border; and the padding<br />
lives inside the border. In addition to nsIFrame::GetRect, we also have<br />
the APIs nsIFrame::GetPaddingRect to get the padding box (the outside<br />
edge of the padding, or inside edge of the border) and<br />
nsIFrame::GetContentRect to get the content box (the outside edge of the<br />
content, or inside edge of the padding). These APIs may produce out of<br />
date results when reflow is needed (or has not yet occurred).<br />
<br />
In addition to tracking a rectangle, frames also track two overflow<br />
areas: visual overflow and scrollable overflow. These overflow areas<br />
represent the union of the area needed by the frame and by all its<br />
descendants. The visual overflow is used for painting-related<br />
optimizations: it is a rectangle covering all of the area that might be<br />
painted when the frame and all of its descendants paint. The scrollable<br />
overflow represents the area that the user should be able to scroll to<br />
to see the frame and all of its descendants. In some cases differences<br />
between the frame's rect and its overflow happen because of descendants<br />
that stick out of the frame; in other cases they occur because of some<br />
characteristic of the frame itself. The two overflow areas are<br />
similar, but there are differences: for example, margins are part of<br />
scrollable overflow but not visual overflow, whereas text-shadows are<br />
part of visual overflow but not scrollable overflow.<br />
<br />
When frames are broken across lines, columns, or pages, we create<br />
multiple frames representing the multiple rectangles of the element.<br />
The first one is the primary frame, and the rest are its continuations<br />
(which are more likely to be destroyed and recreated during reflow).<br />
These frames are linked together as continuations: they have a<br />
doubly-linked list that can be used to traverse the continuations using<br />
nsIFrame::GetPrevContinuation and nsIFrame::GetNextContinuation.<br />
(Currently continuations always have the same style data, though we may<br />
at some point want to break that invariant.)<br />
<br />
Continuations are sometimes siblings of each other, and sometimes not.<br />
For example, if a paragraph contains a span which contains a link, and<br />
the link is split across lines, then the continuations of the span are<br />
siblings (since they are both children of the paragraph), but the<br />
continuations of the link are not siblings (since each continuation of<br />
the link is descended from a different continuation of the span).<br />
Traversing the entire frame tree does '''not''' require considering<br />
continuations, since all of the continuations are descendants of the<br />
element containing the break.<br />
<br />
We also use continuations for cases (most importantly, bidi reordering,<br />
where left-to-right text and right-to-left text need to be separated<br />
into different continuations since they may not form a contiguous<br />
rectangle) where the continuations should not be rewrapped during<br />
reflow: we call these continuations fixed rather than fluid.<br />
nsIFrame::GetNextInFlow and nsIFrame::GetPrevInFlow traverse only the<br />
fluid continuations and do not cross fixed continuation boundaries.<br />
<br />
If an inline frame has non-inline children, then we split the original <br />
inline frame into parts. The original inline's children are <br />
distributed into these parts like so- The children of the original <br />
inline are grouped into runs of inline and non-inline and runs of <br />
inline get an inline parent while runs of non-inline get an anonymous <br />
block parent. This is 'ib-splitting' or block-inside-inline-splitting. <br />
This splitting proceeds recursively up the frame tree until all <br />
non-inlines inside inlines are ancestors of a block frame with anonymous <br />
block wrappers in between. This splitting maintains the relative order<br />
between these child frames and the relationship between the parts of a <br />
split inline is maintained using an ib-sibling chain. It is important <br />
to note that any wrappers created during frame construction (such as <br />
for tables) may not be included in the ib-sibling chain depending on <br />
when this wrapper creation takes place. <br />
<br />
TODO: nsBox craziness from https://bugzilla.mozilla.org/show_bug.cgi?id=524925#c64<br />
<br />
TODO: link to documentation of block and inline layout<br />
<br />
TODO: link to documentation of scrollframes<br />
<br />
TODO: link to documentation of XUL frame classes<br />
<br />
Code (note that most files in base and generic have useful one line descriptions at the top that show up in DXR):<br />
* [http://dxr.mozilla.org/mozilla-central/source/layout/base/ layout/base/] contains objects that coordinate everything and a bunch of other miscellaneous things<br />
* [http://dxr.mozilla.org/mozilla-central/source/layout/generic/ layout/generic/] contains the basic frame classes as well as support code for their reflow methods (ReflowInput, ReflowOutput)<br />
* [http://dxr.mozilla.org/mozilla-central/source/layout/forms/ layout/forms/] contains frame classes for HTML form controls<br />
* [http://dxr.mozilla.org/mozilla-central/source/layout/tables/ layout/tables/] contains frame classes for CSS/HTML tables<br />
* [http://dxr.mozilla.org/mozilla-central/source/layout/mathml/ layout/mathml/] contains frame classes for MathML<br />
* [http://dxr.mozilla.org/mozilla-central/source/layout/svg/ layout/svg/] contains frame classes for SVG<br />
* [http://dxr.mozilla.org/mozilla-central/source/layout/xul/ layout/xul/] contains frame classes for the XUL box model and for various XUL widgets<br />
<br />
Bugzilla:<br />
* All of the components whose names begin with "Layout" in the "Core" product<br />
<br />
Further documentation:<br />
* Talk: [https://air.mozilla.org/introduction-to-graphics-layout-architecture/ Introduction to graphics/layout architecture] (Robert O'Callahan, 2014-04-18)<br />
* Talk: [https://air.mozilla.org/bz-layout-and-styles/ Layout and Styles] (Boris Zbarsky, 2014-10-14)<br />
<br />
<br />
==== Frame Construction ====<br />
<br />
Frame construction is the process of creating frames. This is done when styles change in ways that require frames to be created or recreated or when nodes are inserted into the document. The content tree and the frame tree don't have quite the same shape, and the frame construction process does some of the work of creating the right shape for the frame tree. It handles the aspects of creating the right shape that don't depend on layout information. So for example, frame construction handles the work needed to implement [http://www.w3.org/TR/CSS21/tables.html#anonymous-boxes table anonymous objects] but does not handle frames that need to be created when an element is broken across lines or pages.<br />
<br />
The basic unit of frame construction is a run of contiguous children of a single parent element. When asked to construct frames for such a run of children, the frame constructor first determines, based on the siblings and parent of the nodes involved, where in the frame tree the new frames should be inserted. Then the frame constructor walks through the list of content nodes involved and for each one creates a temporary data structure called a '''frame construction item'''. The frame construction item encapsulates various information needed to create the frames for the content node: its style data, some metadata about how one would create a frame for this node based on its namespace, tag name, and styles, and some data about what sort of frame will be created. This list of frame construction items is then analyzed to see whether constructing frames based on it and inserting them at the chosen insertion point will produce a valid frame tree. If it will not, the frame constructor either fixes up the list of frame construction items so that the resulting frame tree would be valid or throws away the list of frame construction items and requests the destruction and re-creation of the frame for the parent element so that it has a chance to create a list of frame construction items that it <em>can</em> fix up.<br />
<br />
Once the frame constructor has a list of frame construction items and an insertion point that would lead to a valid frame tree, it goes ahead and creates frames based on those items. Creation of a non-leaf frame recursively attempts to create frames for the children of that frame's element, so in effect frames are created in a depth-first traversal of the content tree.<br />
<br />
The vast majority of the code in the frame constructor, therefore, falls into one of these categories:<br />
* Code to determine the correct insertion point in the frame tree for new frames.<br />
* Code to create, for a given content node, frame construction items. This involves some searches through static data tables for metadata about the frame to be created.<br />
* Code to analyze the list of frame construction items.<br />
* Code to fix up the list of frame construction items.<br />
* Code to create frames from frame construction items.<br />
<br />
Code: [http://dxr.mozilla.org/mozilla-central/source/layout/base/nsCSSFrameConstructor.h layout/base/nsCSSFrameConstructor.h] and [http://dxr.mozilla.org/mozilla-central/source/layout/base/nsCSSFrameConstructor.cpp layout/base/nsCSSFrameConstructor.cpp]<br />
<br />
==== Reflow ====<br />
<br />
Reflow is the process of computing the positions and sizes of frames. (After all,<br />
frames represent rectangles, and at some point we need to figure out<br />
exactly *what* rectangle.) Reflow is done recursively, with each<br />
frame's Reflow method calling the Reflow methods on that frame's<br />
descendants.<br />
<br />
In many cases, the correct results are defined by CSS specifications<br />
(particularly [http://www.w3.org/TR/CSS21/visudet.html CSS 2.1]). In some cases, the details are not defined by<br />
CSS, though in some (but not all) of those cases we are constrained by<br />
Web compatibility. When the details are defined by CSS, however, the<br />
code to compute the layout is generally structured somewhat differently<br />
from the way it is described in the CSS specifications, since the CSS<br />
specifications are generally written in terms of constraints, whereas<br />
our layout code consists of algorithms optimized for incremental<br />
recomputation.<br />
<br />
The reflow generally starts from the root of the frame tree, though some other<br />
types of frame can act as reflow roots and start a reflow from them.<br />
Reflow roots must obey the invariant that a change inside one of their<br />
descendants never changes their rect or overflow areas (though currently<br />
scrollbars are reflow roots but don't quite obey this invariant).<br />
<br />
In many cases, we want to reflow a part of the frame tree, and we want<br />
this reflow to be efficient. For example, when content is added or<br />
removed from the document tree or when styles change, we want the amount<br />
of work we need to redo to be proportional to the amount of content. We<br />
also want to efficiently handle a series of changes to the same content.<br />
<br />
To do this, we maintain two bits on frames:<br />
[http://dxr.mozilla.org/mozilla-central/search?q=var%3ANS_FRAME_IS_DIRTY&case=true&redirect=true NS_FRAME_IS_DIRTY]<br />
indicates that a frame and all of its descendants require reflow.<br />
[http://dxr.mozilla.org/mozilla-central/search?q=var%3ANS_FRAME_HAS_DIRTY_CHILDREN&case=true&redirect=true NS_FRAME_HAS_DIRTY_CHILDREN]<br />
indicates that a frame has a descendant that<br />
is dirty or has had a descendant removed (i.e., that it has a child that<br />
has NS_FRAME_IS_DIRTY or NS_FRAME_HAS_DIRTY_CHILDREN or it had a child<br />
removed). These bits allow coalescing of multiple updates; this<br />
coalescing is done in nsPresShell, which tracks the set of reflow roots<br />
that require reflow. The bits are set during calls to<br />
nsPresShell::FrameNeedsReflow and are cleared during reflow.<br />
<br />
The layout algorithms used by many of the frame classes are those<br />
specified in CSS, which are based on the traditional document formatting<br />
model, where widths are input and heights are output.<br />
<br />
In some cases, however, widths need to be determined based on the<br />
content. This depends on two ''intrinsic widths'': the minimum<br />
intrinsic width (see [http://dxr.mozilla.org/search?q=type%3AnsIFrame%20function%3AGetMinWidth&tree=mozilla-central nsIFrame::GetMinWidth]) and the preferred intrinsic<br />
width (see [http://dxr.mozilla.org/search?q=type%3AnsIFrame%20function%3AGetPrefWidth&tree=mozilla-central nsIFrame::GetPrefWidth]). The concept of what these widths<br />
represent is best explained by describing what they are on a paragraph<br />
containing only text: in such a paragraph the minimum intrinsic width<br />
is the width of the longest word, and the preferred intrinsic width is<br />
the width of the entire paragraph laid out on one line.<br />
<br />
Intrinsic widths are invalidated separately from the dirty bits<br />
described above. When a caller informs the pres shell that a frame<br />
needs reflow (nsIPresShell::FrameNeedsReflow), it passes one of three<br />
options:<br />
* eResize indicates that no intrinsic widths are dirty<br />
* eTreeChange indicates that intrinsic widths on it and its ancestors are dirty (which happens, for example, if new children are added to it)<br />
* eStyleChange indicates that intrinsic widths on it, its ancestors, and its descendants are dirty (for example, if the font-size changes)<br />
<br />
Reflow is the area where the XUL frame classes (those that inherit from<br />
nsBoxFrame or nsLeafBoxFrame) are most different from the rest. Instead<br />
of using nsIFrame::Reflow, they do their layout computations using<br />
intrinsic size methods called GetMinSize, GetPrefSize, and GetMaxSize<br />
(which report intrinsic sizes in two dimensions) and a final layout<br />
method called Layout. In many cases these methods defer some of the<br />
computation to a separate object called a layout manager.<br />
<br />
When an individual frame's Reflow method is called, most of the input is<br />
provided on an object called ReflowInput and the output is filled<br />
in to an object called ReflowOutput. After reflow, the caller<br />
(usually the parent) is responsible for setting the frame's size based<br />
on the metrics reported. (This can make some computations during reflow<br />
difficult, since the new size is found in either the reflow state or the<br />
metrics, but the frame's size is still the old size. However, it's<br />
useful for invalidating the correct areas that need to be repainted.)<br />
<br />
One major difference worth noting is that in XUL layout, the size of the<br />
child is set prior to its parent calling its Layout method. (Once<br />
invalidation uses display lists and is no longer tangled up in Reflow,<br />
it may be worth switching non-XUL layout to work this way as well.)<br />
<br />
==== Painting ====<br />
<br />
TODO: display lists (and event handling)<br />
<br />
TODO: layers<br />
<br />
==== Pagination ====<br />
<br />
The concepts behind pagination (also known as fragmentation) are a bit complicated, so for now we've split them off into a separate document: [[Gecko:Continuation_Model]]. This code is used for printing, print-preview, and multicolumn frames.<br />
<br />
=== Dynamic change handling along the rendering pipeline ===<br />
<br />
The ability to make changes to the DOM from script is a major feature of the Web platform. Web authors rely on the concept (though there are a few exceptions, such as animations) that changing the DOM from script leads to the same rendering that would have resulted from starting from that DOM tree. They also rely on the performance characteristics of these changes: small changes to the DOM that have small effects should have proportionally small processing time. This means that Gecko needs to efficiently propagate changes from the content tree to style, the frame tree, the geometry of the frame tree, and the screen.<br />
<br />
For many types of changes, however, there is substantial overhead to processing a change, no matter how small. For example, reflow must propagate from the top of the frame tree down to the frames that are dirty, no matter how small the change. One very common way around this is to batch up changes. We batch up changes in lots of ways, for example:<br />
* The content sink adds multiple nodes to the DOM tree before notifying listeners that they've been added. This allows notifying once about an ancestor rather than for each of its descendants, or notifying about a group of descendants all at once, which speeds up the processing of those notifications.<br />
* We batch up nodes that require style reresolution (recomputation of selector matching and processing the resulting style changes). This batching is tree based, so it not only merges multiple notifications on the same element, but also merges a notification on an ancestor with a notification on its descendant (since ''some'' of these notifications imply that style reresolution is required on all descendants).<br />
* We wait to reconstruct frames that require reconstruction (after destroying frames eagerly). This, like the tree-based style reresolution batching, avoids duplication both for same-element notifications and ancestor-descendant notifications, even though it doesn't actually do any tree-based caching.<br />
* We postpone doing reflows until needed. As for style reresolution, this maintains tree-based dirty bits (see the description of NS_FRAME_IS_DIRTY and NS_FRAME_HAS_DIRTY_CHILDREN under Reflow).<br />
* We allow the OS to queue up multiple invalidates before repainting (though we will likely switch to controlling that ourselves). This leads to a single repaint of some set of pixels where there might otherwise have been multiple (though it may also lead to more pixels being repainted if multiple rectangles are merged to a single one).<br />
<br />
Having changes buffered up means, however, that various pieces of information (layout, style, etc.) may not be up-to-date. Some things require up-to-date information: for example, we don't want to expose the details of our buffering to Web page script since the programming model of Web page script assumes that DOM changes take effect "immediately", i.e., that the script shouldn't be able to detect any buffering. Many Web pages depend on this.<br />
<br />
We therefore have ways to flush these different sorts of buffers. There are methods called FlushPendingNotifications on nsIDocument and nsIPresShell, that take an argument of what things to flush:<br />
* Flush_Content: create all the content nodes from data buffered in the parser<br />
* Flush_ContentAndNotify: the above, plus notify document observers about the creation of all nodes created so far<br />
* Flush_Style: the above, plus make sure style data are up-to-date<br />
* Flush_Frames: the above, plus make sure all frame construction has happened (currently the same as Flush_Style)<br />
* Flush_InterruptibleLayout: the above, plus perform layout (Reflow), but allow interrupting layout if it takes too long<br />
* Flush_Layout: the above, plus ensure layout (Reflow) runs to completion<br />
* Flush_Display (should never be used): the above, plus ensure repainting happens<br />
<br />
The major way that notifications of changes propagate from the content code to layout and other areas of code is through the nsIDocumentObserver and nsIMutationObserver interfaces. Classes can implement this interface to listen to notifications of changes for an entire document or for a subtree of the content tree.<br />
<br />
WRITE ME: ... layout document observer implementations<br />
<br />
TODO: how style system optimizes away rerunning selector matching<br />
<br />
TODO: style changes and nsChangeHint<br />
<br />
=== Refresh driver ===<br />
<br />
== Graphics ==<br />
[https://wiki.mozilla.org/Platform/GFX Wiki page] | [https://wiki.mozilla.org/index.php?title=Platform/GFX/Contribute contribute]<br />
<br />
Further documentation:<br />
* Talk: [https://air.mozilla.org/introduction-to-graphics-layout-architecture/ Introduction to graphics/layout architecture] (Robert O'Callahan, 2014-04-18)<br />
* Talk: [https://air.mozilla.org/bjacob-gfx-overview/ An overview of Gecko's graphics stack] (Benoit Jacob, 2014-08-12)<br />
* Talk: [https://air.mozilla.org/jeff-muizelaar-2d-graphics/ 2D Graphics] (Jeff Muizelaar, 2014-10-14)<br />
<br />
==== Painting/Rasterizing ====<br />
<br />
Painting/rendering/rasterizing is the step where graphical primitives (such as a command to fill an [https://developer.mozilla.org/en-US/docs/Web/SVG SVG] circle, or a [https://developer.mozilla.org/en-US/docs/Web/Guide/Graphics/Drawing_graphics_with_canvas canvas] command to stroke a path between x, y, z, or the internally produced command to draw the edge of an HTML div's border) are used to color in the pixels of a surface so that the surface "displays" those rasterized primitives.<br />
<br />
The platform independent library that gecko uses to render is [http://dxr.mozilla.org/mozilla-central/source/gfx/2d/2D.h Moz2D]. Gecko code paints into Moz2D DrawTarget objects (the DrawTarget baseclass having multiple platform dependent subclasses). (At least this is where gecko is going - for now there is still significant amounts of code that uses [http://dxr.mozilla.org/mozilla-central/source/gfx/thebes/gfxContext.h Thebes gfxContext] objects or the even older nsRenderingContext objects. Objects of these types now always wrap a DrawTarget so all painting does now go through Moz2D, but conversion to use the wrapped DrawTargets directly is taking time since consumer code can sometimes need to be radically rewritten to fit the Moz2D API and immediate mode paradigm.)<br />
<br />
==== Compositing ====<br />
<br />
The compositing stage of the rendering pipeline is operated by the [http://dxr.mozilla.org/mozilla-central/source/gfx/layers/ gfx/layers] module.<br />
<br />
Different parts of a web page can sometimes be painted into intermediate surfaces retained by layers. It can be convenient to think of layers as the layers in image manipulation programs like The Gimp or Photoshop. Layers are organized as a tree. Layers are primarily used to minimize invalidating and repainting when elements are being animated independently of one another in a way that can be optimized using layers (e.g. opacity or transform animations), and to enable some effects (such as transparency and 3D transforms).<br />
<br />
Compositing is the action of flattening the layers into the final image that is shown on the screen.<br />
<br />
On some platform, compositing happens on the Content thread. However, on other platforms we composite on a separate thread (Off-main-thread compositing, or OMTC). OMTC is at the moment the default behavior on mobile platforms, but the goal is to do it on all platforms in the long run.<br />
<br />
The Layers architecture is built on the following notions:<br />
* Compositor: an object that can draw quads on the screen (or on an off-screen render target).<br />
* Texture: an object that contains image data.<br />
* Compositable: an object that can manipulate one or several textures, and knows how to present them to the compositor<br />
* Layer: an element of the layer tree. A layer usually doesn't know much about compositing: it uses a compositable to do the work. Layers are mostly nodes of the layer tree.<br />
<br />
[[File:LayersRefactoring.png|thumb|650px|New layers architecture, with OGL backend]]<br />
<br />
The above abstractions are sufficient to perform compositing on the main thread, but on the OMTC case, we need a mechanism to synchronize a client layer tree that is constructed on the content thread, and a host layer tree that is used for compositing on the compositor thread.<br />
This synchronization process must ensure that the host layer tree reflects the state of the current layer tree while remaining in a consistent state, and must transfer texture data from a thread to the other. Moreover, on some platforms the content and compositor threads may live in separate processes.<br />
<br />
To perform this synchronization, we use the IPDL IPC framework. IPDL lets us describe communications protocols and actors in a domain specific language. for more information about IPDL, read https://wiki.mozilla.org/IPDL<br />
<br />
When the client layer tree is modified, we record modifications into messages that are sent together to the host side within a transaction. A transaction is basically a list of modifications to the layer tree that have to be applied all at once to preserve consistency in the state of the host layer tree.<br />
<br />
Texture transfer is done by synchronizing texture objects across processes/threads using a couple TextureClient/TextureHost that wrap shared data and provide access to it on both sides. TextureHosts provide access to one or several TextureSource, which has the necessary API to actually composite the texture (TextureClient/Host being more about IPC synchronization than actual compositing.<br />
The logic behind texture transfer (as in single/double/triple buffering, texture tiling, etc) is operated by the CompositableClient and CompositableHost.<br />
<br />
It is important to understand the separation between layers and compositables. Compositables handle all the logic around texture transfer, while layers define the shape of the layer tree. a Compositable is created independently from a layer and attached to it on both sides. While layers transactions can only originate from the content thread, this separation makes it possible for us to have separate compositable transactions between any thread and the compositor thread. We use the ImageBridge IPDL protocol to that end. The Idea of ImageBridge is to create a Compositable that is manipulated on the ImageBridgeThread, and that can transfer/synchronize textures without using the content thread at all. This is very useful for smooth Video compositing: video frames are decoded and passed into the ImageBridge without ever touching the content thread, which could be busy processing reflows or heavy javascript workloads.<br />
<br />
It is worth reading the inline code documentation in the following files:<br />
* [http://dxr.mozilla.org/mozilla-central/source/gfx/layers/Compositor.h gfx/layers/Compositor.h]<br />
* [http://dxr.mozilla.org/mozilla-central/source/gfx/layers/ShadowLayers.h gfx/layers/ShadowLayers.h]<br />
* [http://dxr.mozilla.org/mozilla-central/source/gfx/layers/Layers.h gfx/layers/Layers.h]<br />
* [http://dxr.mozilla.org/mozilla-central/source/gfx/layers/host/TextureHost.h gfx/layers/host/TextureHost.h]<br />
* [http://dxr.mozilla.org/mozilla-central/source/gfx/layers/client/CompositableClient.h gfx/layers/client/CompositableClient.h]<br />
<br />
To visualize how a web page is layered, turn on the pref "layers.draw-borders" in about:config. When this pref is on, the borders of layers and tiles are displayed on top of the content. This only works when using the new Compositor API, that is when off-main-thread compositing is activated. OMTC is activated by default on all mobile platforms, and will progressively get activated on desktop platforms (not yet, though). On platforms where OMTC is not used, this pref has no effect. <br />
<br />
Blog posts with information on Layers that should be integrated here:<br />
<br />
* [http://www.basschouten.com/blog1.php/layers-cross-platform-acceleration Layers: Cross-Platform Acceleration]<br />
* [http://robert.ocallahan.org/2010/04/layers_01.html Layers]<br />
* [http://robert.ocallahan.org/2010/07/retained-layers_16.html Retained Layers]<br />
* [http://chrislord.net/index.php/2011/07/25/shadow-layers-and-learning-by-failing/ Shadow Layers, and learning by failing]<br />
* [http://chrislord.net/index.php/2011/08/16/accelerated-layer-rendering-and-learning-by-some-success/ Accelerated layer-rendering, and learning by (some) success]<br />
* [http://featherweightmusings.blogspot.co.uk/2012/05/mask-layers_26.html Mask Layers]<br />
* [http://featherweightmusings.blogspot.co.uk/2012/05/building-mask-layer.html Building a mask layer]<br />
* [http://featherweightmusings.blogspot.co.uk/2012/06/mask-layers-on-direct3d-backends.html Mask Layers on the Direct3D backends]<br />
* [http://robert.ocallahan.org/2011/09/graphics-api-design.html Graphics API Design]<br />
<br />
==== Async Panning and Zooming ====<br />
<br />
On some of our mobile platforms we have some code that allows the user to do asynchronous (i.e. off-main-thread) panning and zooming of content. This code is the Async Pan/Zoom module (APZ) code and is further documented at [[Platform/GFX/APZ]].<br />
<br />
== Scripting ==<br />
<br />
=== JavaScript Engine ===<br />
<br />
Gecko embeds the SpiderMonkey JavaScript engine (located in js/src). The JS engine includes a number of Just-In-Time compilers (or JITs). SpiderMonkey provides a powerful and extensive embedding API (called the JSAPI). Because of its complexity, using the JSAPI directly is frowned upon, and a number of abstractions have been built in Gecko to allow interacting with the JS engine without using JSAPI directly. Some JSAPI concepts are important for Gecko developers to understand, and they are listed below:<br />
<br />
* Global object: The '''global object''' is the object on which all global variables/properties/methods live. In a web page this is the 'window' object. In other things such as XPCOM components or sandboxes XPConnect creates a global object with a small number of builtin APIs.<br />
* Compartments: A '''compartment''' is a subdivision of the JS heap. The mapping from global objects to compartments is one-to-one; that is, every global object has a compartment associated with it, and no compartment is associated with more than one global object. (NB: There are compartments associated with no global object, but they aren't very interesting). When JS code is running SpiderMonkey has a concept of a "current" compartment. New objects that are created will be created in the "current" compartment and associated with the global object of that compartment.<br />
* When objects in one compartment can see objects in another compartment (via e.g. iframe.contentWindow.foo) '''cross-compartment wrappers''' or '''CCWs''' mediate the interaction between the two compartments. By default CCWs ensure that the current compartment is kept up-to-date when execution crosses a compartment boundary. SpiderMonkey also allows embeddings to extend wrappers with custom behavior to implement security policies, which Gecko uses extensively (see the Security section for more information).<br />
<br />
Further documentation:<br />
* Talk: [https://air.mozilla.org/kannan-vijayan-baseline-jit/ Baseline JIT] (Kannan Vijayan, 2014-10-14)<br />
<br />
=== XPConnect ===<br />
<br />
'''XPConnect''' is a bridge between C++ and JS used by XPCOM components exposed to or implemented in JavaScript. XPConnect allows two XPCOM components to talk to each other without knowing or caring which language they are implemented in. XPConnect allows JS code to call XPCOM components by exposing XPCOM interfaces as JS objects, and mapping function calls and attributes from JS into virtual method calls on the underlying C++ object. It also allows JS code to implement an XPCOM component that can be called from C++ by faking the vtable of an interface and translating calls on the interface into JS calls. XPConnect accomplishes this using the vtable data stored in XPCOM TypeLibs (or XPT files) by the XPIDL compiler and a small layer of platform specific code called [https://developer.mozilla.org/en-US/docs/xptcall_FAQ xptcall] that knows how to interact with and impersonate vtables of XPCOM interfaces.<br />
<br />
XPConnect is also used for a small (and decreasing) number of legacy DOM objects. At one time all of the DOM used XPConnect to talk to JS, but we have been replacing XPConnect with the WebIDL bindings (see the next section for more information). Arbitrary XPCOM components are not exposed to web content. XPCOM components that want to be accessible to web content must provide class info (that is, they must QI to nsIClassInfo) and must be marked with the nsIClassInfo::DOM_OBJECT flag. Most of these objects also are listed in dom/base/nsDOMClassInfo.cpp, where the interfaces that should be visible to the web are enumerated. This file also houses some "scriptable helpers" (classes ending in "SH" and implementing nsIXPCScriptable), which are a set of optional hooks that can be used by XPConnect objects to implement more exotic behaviors (such as indexed getters or setters, lazily resolved properties, etc). This is all legacy code, and any new DOM code should use the WebIDL bindings.<br />
<br />
=== WebIDL Bindings ===<br />
<br />
The '''WebIDL bindings''' are a separate bridge between C++ and JS that is specifically designed for use by DOM code. We intend to replace all uses of XPConnect to interface with content JavaScript with the WebIDL bindings. [https://developer.mozilla.org/en-US/docs/Mozilla/WebIDL_bindings Extensive documentation] on the WebIDL bindings is available, but the basic idea is that a binding generator takes WebIDL files from web standards and some configuration data provided by us and generates at build time C++ glue code that sits between the JS engine and the DOM object. This setup allows us to produce faster, more specialized code for better performance at the cost of increased codesize.<br />
<br />
The WebIDL bindings also implement all of the behavior specified in WebIDL, making it possible for new additions to the DOM to behave correctly "out of the box". The binding layer also provides C++ abstractions for types that would otherwise require direct JSAPI calls to handle, such as typed arrays. <br />
<br />
=== Security ===<br />
<br />
Gecko's JS security model is based on the concept of compartments. Every compartment has a '''principal''' associated with it that contains security information such as the '''origin''' of the compartment, whether or not it has system privileges, etc. For the following discussion, '''wrappee''' refers to the underlying object being wrapped, '''scope''' refers to the compartment the object is being wrapped for use in, and '''wrapper''' refers to the object created in '''scope''' that allows it to interact with '''wrappee'''. "Chrome" refers to JS that is built in to the browser or part of an extension, which runs with full privileges, and is contrasted with "content", which is web provided script that is subject to security restrictions and the same origin policy.<br />
<br />
* Xray wrappers: Xray wrappers are used when the scope has chrome privileges and the wrappee is the JS reflection of an underlying DOM object. Beyond the usual CCW duties of making sure that content code does not run with chrome privileges, Xray wrappers also ensure that calling methods or accessing attributes on the wrappee has the "expected" effect. For example, a web page could replace the <code>close</code> method on its window with a JS function that does something completely different. (e.g. <code>window.close = function() { alert("This isn't what you wanted!") };</code>). Overwriting methods in this way (or creating entirely new ones) is referred to as '''expando''' properties. Xrays see through expando properties, invoking the original method/getter/setter if the expando overwrites a builtin or seeing undefined in the expando creates a new property. This allows chrome code to call methods on content DOM objects without worrying about how the page has changed the object.<br />
* Waived xray wrappers: The xray behavior is not always desirable. It is possible for chrome to "waive" the xray behavior and see the actual JS object. The wrapper still guarantees that code runs with the correct privileges, but methods/getters/setters may not behave as expected. This is equivalent to the behavior chrome sees when it looks at non-DOM content JS objects.<br />
* For more information, see the [https://developer.mozilla.org/en-US/docs/Mozilla/Gecko/Script_security MDN page]<br />
* bholley's [https://air.mozilla.org/enter-the-compartment/ Enter the Compartment] talk also provides an overview of our compartment architecture.<br />
<br />
== Images ==<br />
<br />
== Plugins ==<br />
<br />
== Platform-specific layers ==<br />
<br />
* widget<br />
* native theme<br />
* files, networking, other low-level things<br />
* Accessibility APIs<br />
* Input. Touch-input stuff is somewhat described at [[Platform/Input/Touch]].<br />
<br />
== Editor ==<br />
<br />
== Base layers ==<br />
<br />
=== NSPR ===<br />
<br />
NSPR is a library for providing cross-platform APIs for various<br />
platform-specific functions. We tend to be trying to use it as little<br />
as possible, although there are a number of areas (particularly some<br />
network-related APIs and threading/locking primitives) where we use it<br />
quite a bit.<br />
<br />
=== XPCOM ===<br />
<br />
XPCOM is a cross-platform modularity library, modeled on Microsoft COM. It<br />
is an object system in which all objects inherit from the <code>nsISupports</code> interface.<br />
<br />
components and services, contract IDs and CIDs<br />
<br />
prior overuse of XPCOM; littering with XPCOM does not produce modularity<br />
<br />
Base headers (part of xpcom/base/) and data structures. See also mfbt.<br />
<br />
Threading<br />
<br />
xptcall, proxies<br />
<br />
reference counting, cycle collection<br />
<br />
Further documentation:<br />
* XPCOM and Internal Strings in Gecko (talk by David Baron, 2014-03-20): [https://air.mozilla.org/xpcom-and-internal-strings-in-gecko/ video], [https://dbaron.org/talks/2014-03-20-xpcom-string-taipei/speaking-notes speaking notes]<br />
<br />
=== String ===<br />
<br />
XPCOM has string classes for representing sequences of characters. Typical C++ string classes have the goals of encapsulating the memory management of buffers and the issues needed to avoid buffer overruns common in traditional C string handling. Mozilla's string classes have these goals, and also the goal of reducing copying of strings.<br />
<br />
(There is a second set of string classes in xpcom/glue for callers outside of libxul; these classes are partially source-compatible but have different (worse) performance characteristics. This discussion does not cover those classes.)<br />
<br />
We have two parallel sets of classes, one for strings with 1-byte units (<code>char</code>, which may be signed or unsigned), and one for strings with 2-byte units (<code>char16_t</code>, always unsigned). The classes are named such that the class for 2-byte characters ends with <code>String</code> and the corresponding class for 1-byte characters ends with <code>CString</code>. 2-byte strings are almost always used to encode [http://en.wikipedia.org/wiki/UTF-16 UTF-16]. 1-byte strings are usually used to encode either [http://en.wikipedia.org/wiki/ASCII ASCII] or [http://en.wikipedia.org/wiki/UTF-8 UTF-8], but are sometimes also used to hold data in some other encoding or just byte sequences.<br />
<br />
The string classes distinguish, as part of the type hierarchy, between strings that must have a null-terminator at the end of their buffer (<code>ns[C]String</code>) and strings that are not required to have a null-terminator (<code>ns[C]Substring</code>). <code>ns[C]Substring</code> is the base of the string classes (since it imposes fewer requirements) and <code>ns[C]String</code> is a class derived from it. Functions taking strings as parameters should generally take one of these four types.<br />
<br />
In order to avoid unnecessary copying of string data (which can have significant performance cost), the string classes support different ownership models. All string classes support the following three ownership models dynamically:<br />
* reference counted, copy-on-write, buffers (the default)<br />
* adopted buffers (a buffer that the string class owns, but is not reference counted, because it came from somewhere else)<br />
* dependent buffers, that is, an underlying buffer that the string class does not own, but that the caller that constructed the string guarantees will outlive the string instance<br />
In addition, there is a special string class, <code>nsAuto[C]String</code>, that ''additionally'' contains an internal 64-unit buffer (intended primarily for use on the stack), leading to a fourth ownership model:<br />
* storage within an auto string's stack buffer<br />
Auto strings will prefer reference counting an existing reference-counted buffer over their stack buffer, but will otherwise use their stack buffer for anything that will fit in it.<br />
<br />
There are a number of additional string classes, particularly <code>nsDependent[C]String</code>, <code>nsDependent[C]Substring</code>, and the <code>NS_LITERAL_[C]STRING</code> macros which construct an <code>nsLiteral[C]String</code> which exist primarily as constructors for the other types. These types are really just convenient notation for constructing an <code>ns[C]S[ubs]tring</code> with a non-default ownership mode; they should not be thought of as different types. (The <code>Substring</code>, <code>StringHead</code>, and <code>StringTail</code> functions are also constructors for dependent [sub]strings.) Non-default ownership modes can also be set up using the <code>Rebind</code> and <code>Adopt</code> methods, although the <code>Rebind</code> methods actually live on the derived types, which is probably a mistake (although moving them up would require some care to avoid making an API that easily allows assigning a non-null-terminated buffer to a string whose static type indicates that it is null-terminated).<br />
<br />
Note that the presence of all of these classes imposes some awkwardness in terms of distinctions being available as both static type distinctions and dynamic type distinctions. In general, the only distinctions that should be made statically are 1-byte vs. 2-byte sequences (<code>CString</code> vs <code>String</code>) and whether the buffer is null-terminated or not (<code>Substring</code> vs <code>String</code>). (Does the code actually do a good job of dynamically enforcing the <code>Substring</code> vs. <code>String</code> restriction?)<br />
<br />
TODO: buffer growth, concatenation optimizations<br />
<br />
TODO: encoding conversion, what's validated and what isn't<br />
<br />
TODO: "string API", nsAString (historical)<br />
<br />
* Code: xpcom/string/<br />
* Bugzilla: Core::String<br />
<br />
Further documentation:<br />
* XPCOM and Internal Strings in Gecko (talk by David Baron, 2014-03-20): [https://air.mozilla.org/xpcom-and-internal-strings-in-gecko/ video], [https://dbaron.org/talks/2014-03-20-xpcom-string-taipei/speaking-notes speaking notes]</div>Dbaronhttps://wiki.mozilla.org/index.php?title=Gecko:Overview&diff=1193209Gecko:Overview2018-05-02T21:33:06Z<p>Dbaron: /* JavaScript Engine */ add video</p>
<hr />
<div>This document attempts to give an overview of the different parts of<br />
Gecko, what they do, and why they do it, say where the code for them is<br />
within the repository, and link to more specific documentation (when<br />
available) covering the details of that code. '''It is not yet complete.''' Maintainers of these<br />
areas of code should correct errors, add information, and add links to<br />
more detailed documentation (since this document is intended to remain<br />
an overview, not complete documentation).<br />
<br />
__TOC__<br />
<br />
== Browsers, Frames, and Document Navigation ==<br />
<br />
=== Docshell ===<br />
<br />
The user of a Web browser can change the page shown in that browser in<br />
many ways: by clicking a link, loading a new URL, using the forward and<br />
back buttons, or other ways. This can happen inside a space we'll call<br />
a '''browsing context'''; this space can be a browser window, a tab, or a frame<br />
or iframe within a document. The toplevel data structures within Gecko<br />
represent this browsing context; they contain other data structures<br />
representing the individual pages displayed inside of it (most<br />
importantly, the current one). In terms of implementation, these two<br />
types of navigation, the top level of a browser and the frames within<br />
it, largely use the same data structures.<br />
<br />
In Gecko, the '''docshell''' is the toplevel object responsible for<br />
managing a single browsing context. It, and the associated '''session history''' code, <br />
manage the navigation between pages inside of a<br />
docshell. (Note the difference between session history, which is a<br />
sequence of pages in a single browser session, used for recording information<br />
for back and forward navigation, and global history, which is the<br />
history of pages visited and associated times, regardless of browser<br />
session, used for things like link coloring and address autocompletion.)<br />
<br />
There are relatively few objects in Gecko that are associated with a<br />
docshell rather than being associated with a particular one of the pages<br />
inside of it. Most such objects are attached to the docshell. An important object associated with the docshell is the nsGlobalWindowOuter which is what the HTML5 spec refers to as a WindowProxy (into which Window objects, as implemented by nsGlobalWindowInner, are loaded). See the DOM section below for more information on<br />
this.<br />
<br />
The most toplevel object for managing the contents of a particular page<br />
being displayed within a docshell is a document viewer (see layout).<br />
Other important objects associated with this presentation are the<br />
document (see DOM) and the pres(entation) shell and pres(entation)<br />
context (see layout).<br />
<br />
[[File:WebNavigation.png|thumb|400px|<xul:browser>, frameloader and docshell in single process configuration]]<br />
<br />
Docshells are organized into a tree. If a docshell has a non-null parent, then it corresponds to a subframe in whatever page is currently loaded in the parent docshell, and the corresponding subframe element (for example, an iframe) is called a '''browsing context container'''. In Gecko, a browsing context container would implement <code>[https://dxr.mozilla.org/mozilla-central/rev/f9a5e9ed62103c84e4cde915f4d08f1ce71be83e/dom/base/nsIFrameLoader.idl#271 nsIFrameLoaderOwner]</code> to hold a '''frameloader''', which holds and manages the docshell. <br />
<br />
One of the most interfaces docshell implemented is <code>[https://dxr.mozilla.org/mozilla-central/source/docshell/base/nsIWebNavigation.idl nsIWebNavigation]</code>. It defines major functions of a browsing context, such as <code>loadURI</code> / <code>goBack</code> / <code>goForward</code> and <code>reload</code>. In single process configuration of desktop Firefox, <code><xul:browser></code> (which represents a tab) operates on docshell through <code>nsIWebNavigation</code>, as shown in the right figure.<br />
<br />
* code: mozilla/docshell/<br />
* bugzilla: Core::Document Navigation<br />
* documentation: [[DocShell:Home Page]]<br />
<br />
=== Session History ===<br />
<br />
In order to keep the session history of subframes after the root document is unloaded and docshells of subframes are destroyed, only the root docshell of a docshell tree manages the session history (this does not match the conceptual model in the HTML5 spec and may be subject to change).<br />
<br />
As an example to explain the structure of session history implementation in Gecko, consider there's a tab A, which loads document 1; in document 1, there are iframe B & C, which loads document 2 & 3, respectively. Later, an user navigates iframe B to document 4. The following figures show the conceptual model of the example, and the corresponding session history structure.<br />
<br />
{| <br />
| [[File:BrowsingContextExample1.png|thumb|190px|Conceptual model representation; color denotes current visible active documents]]<br />
| [[File:SHistoryExample1.png|thumb|180px|Session history structure; color denotes current transaction / entries]]<br />
|}<br />
<br />
In Gecko, a [https://dxr.mozilla.org/mozilla-central/source/docshell/shistory/nsSHistory.h session history] object holds a list of [https://dxr.mozilla.org/mozilla-central/source/docshell/shistory/nsSHTransaction.h transactions] (denoted as T1 & T2 in the figure); each transaction points to a tree of [https://dxr.mozilla.org/mozilla-central/source/docshell/shistory/nsSHEntry.h entries]; each entry records the docshell it associated to, and a URL. Now that if we navigate the tab to a different root document 5, which includes an iframe D with document 6, then it becomes:<br />
<br />
{| <br />
| [[File:BrowsingContextExample2.png|thumb|275px|Conceptual model representation]]<br />
| [[File:SHistoryExample2.png|thumb|250px|Session history structure]]<br />
|}<br />
<br />
=== Embedding ===<br />
<br />
To be written (and maybe rewritten if we get an IPC embedding API).<br />
<br />
[[File:WebNavigationE10S.png|thumb|500px|<xul:remote-browser>, frameloader and docshell in multiprocess configuration. The horizontal dash-lines represent inter-process communication]]<br />
<br />
=== Multi-process and IPC ===<br />
<br />
In a multi-process desktop Firefox, a tab is managed by <code>[https://dxr.mozilla.org/mozilla-central/source/toolkit/content/widgets/remote-browser.xml <xul:remote-browser>]</code>. It still operates on nsIWebNavigation, but in this case the docshell is in a remote process and can not be accessed directly. The encapsulation of remote nsIWebNavigation is done by the javascript-implemented <code>[https://dxr.mozilla.org/mozilla-central/source/toolkit/components/remotebrowserutils/RemoteWebNavigation.js RemoteWebNavigation]</code>.<br />
<br />
In this configuration, the frameloader of a root docshell lives in parent process, so it can not access docshell directly either. Instead, it holds a <code>[https://dxr.mozilla.org/mozilla-central/source/dom/ipc/TabParent.h TabParent]</code> instance to interact with <code>[https://dxr.mozilla.org/mozilla-central/source/dom/ipc/TabChild.h TabChild]</code> in child-process. At C/C++ level, the communication across processes for a single tab is through the '''PBrowser''' IPC protocol implemented by TabParent and TabChild, while at the javascript level it's done by '''message manager''' (which is ontop of PBrowser). RemoteWebNavigation, for example, sends messages to <code>[https://dxr.mozilla.org/mozilla-central/source/toolkit/content/browser-child.js browser-child.js]</code> in content process through message manager.<br />
<br />
== Networking ==<br />
<br />
The network library Gecko uses is called Necko. Necko APIs are largely organized around three concepts: '''URI objects''', '''protocol handlers''', and '''channels'''.<br />
<br />
=== Protocol handlers ===<br />
A '''protocol handler''' is an XPCOM service associated with a particular URI scheme or network protocol. Necko includes protocol handlers for HTTP, FTP, the data: URI scheme, and various others. Extensions can implement protocol handlers of their own.<br />
<br />
A protocol handler implements the <code>[https://dxr.mozilla.org/mozilla-central/source/netwerk/base/nsIProtocolHandler.idl nsIProtocolHandler]</code> API, which serves three primary purposes:<br />
# Providing metadata about the protocol (its security characteristics, whether it requires actual network access, what the corresponding URI scheme is, what TCP port the protocol uses by default).<br />
# Creating URI objects for the protocol's scheme.<br />
# Creating channel objects for the protocol's URI objects<br />
<br />
Typically, the built-in I/O service (<code>[https://dxr.mozilla.org/mozilla-central/source/netwerk/base/nsIIOService2.idl nsIIOService]</code>) is responsible for finding the right protocol handler for URI object creation and channel creation, while a variety of consumers queries protocol metadata. Querying protocol metadata is the recommended way to handle any sort of code that needs to have different behavior for different URI schemes. In particular, unlike whitelists or blacklists, it correctly handles the addition of new protocols.<br />
<br />
A service can register itself as a protocol handler by registering for the contract ID <code>"@mozilla.org/network/protocol;1?name=SSSSS"</code> where <code>SSSS</code> is the URI scheme for the protocol (e.g. "http", "ftp", and so forth).<br />
<br />
=== URI objects ===<br />
URI objects, which implement the <code>[https://dxr.mozilla.org/mozilla-central/source/netwerk/base/nsIURI.idl nsIURI]</code> API, are a way of representing URIs and IRIs. Their main advantage over strings is that they do basic syntax checking and canonicalization on the URI string that they're provided with. They also provide various accessors to extract particular parts of the URI and provide URI equality comparisons. URIs that correspond to hierarchical schemes implement the additional <code>[https://dxr.mozilla.org/mozilla-central/source/netwerk/base/nsIURL.idl nsIURL]</code> interface, which exposes even more accessors for breaking out parts of the URI.<br />
<br />
URI objects are typically created by calling the <code>newURI</code> method on the I/O service, or in C++ by calling the <code>NS_NewURI</code> utility function. This makes sure to create the URI object using the right protocol handler, which ensures that the right kind of object is created. Direct creation of URIs via <code>createInstance</code> is reserved for protocol handler implementations.<br />
<br />
=== Channels ===<br />
[https://dxr.mozilla.org/mozilla-central/source/netwerk/base/nsIChannel.idl Channels] are the Necko representation of a single request/response interaction with a server. A channel is created by calling the <code>newChannel</code> method on the [https://dxr.mozilla.org/mozilla-central/source/netwerk/base/nsIIOService.idl I/O service], or in C++ by calling the <code>[https://dxr.mozilla.org/mozilla-central/search?q=function%3ANS_NewChannel&case=true NS_NewChannel]</code> utility function. The channel can then be configured as needed, and finally its <code>asyncOpen</code> method can be called. This method takes an <code>[https://dxr.mozilla.org/mozilla-central/source/netwerk/base/nsIStreamListener.idl nsIStreamListener]</code> as an argument.<br />
<br />
If <code>asyncOpen</code> has returned successfully, the channel guarantees that it will asynchronously call the <code>onStartRequest</code> and <code>onStopRequest</code> methods on its stream listener. This will happen even if there are network errors that prevent Necko from actually performing the requests. Such errors will be reported in the channel's status and in the <code>status</code> argument to <code>onStopRequest</code>.<br />
<br />
If the channel ends up being able to provide data, it will make one or more <code>onDataAvailable</code> on its listener after calling <code>onStartRequest</code> and before calling <code>onStopRequest</code>. For each call, the listener is responsible for either returning an error or reading the entire data stream passed in to the call.<br />
<br />
If an error is returned from either <code>onStartRequest</code> or <code>onDataAvailable</code>, the channel must act as if it has been canceled with the corresponding error code.<br />
<br />
A channel has two URI objects associated with it. The <code>originalURI</code> of the channel is the URI that was originally passed to <code>newChannel</code> to create the channel that then had <code>asyncOpen</code> called on it. The <code>URI</code> is the URI from which the channel is reading data. These can be different in various cases involving protocol handlers that forward network access to other protocol handlers, as well as in situations in which a redirect occurs (e.g. following an HTTP 3xx response). In redirect situations, a new channel object will be created, but the originalURI will be propagated from the old channel to the new channel.<br />
<br />
Note that the <code>nsIRequest</code> that's passed to onStartRequest must match the one passed to onDataAvailable and onStopRequest, but need not be the original channel that asyncOpen was called on. In particular, when an HTTP redirect happens the request argument to the callbacks will be the post-redirect channel.<br />
<br />
TODO: crypto?<br />
<br />
== Document rendering pipeline ==<br />
<br />
Some of the major components of Gecko can be described as steps on the<br />
path from an HTML document coming in from the network to the graphics<br />
commands needed to render that document. An HTML document is a<br />
serialization of a tree structure. (FIXME: add diagram) The HTML<br />
parser and content sink create an in-memory representation of this tree,<br />
which we call the '''DOM tree''' or '''content tree'''.<br />
Many JavaScript APIs operate on the content tree. Then, in<br />
layout, we create a second tree, the '''frame tree''' (or<br />
'''rendering tree''') that is a similar shape to the content tree,<br />
but where each node in the tree represents a rectangle (except in SVG<br />
where they represent other shapes). We then compute the positions of<br />
the nodes in the frame tree (called '''frames''') and paint them<br />
using our cross-platform graphics APIs (which, underneath, map to<br />
platform-specific graphics APIs).<br />
<br />
Further documentation:<br />
* Talk: Fast CSS: How Browsers Lay Out Web Pages (David Baron, 2012-03-11): [https://dbaron.org/talks/2012-03-11-sxsw/slide-1.xhtml slideshow], [https://dbaron.org/talks/2012-03-11-sxsw/master.xhtml all slides], [http://audio.sxsw.com/2012/podcasts/11-ACC-Fast_CSS_How_Browser_Layout.mp3 audio (MP3)], [https://schedule.sxsw.com/2012/events/event_IAP12909 session page]<br />
* Talk: [https://air.mozilla.org/benoit-girard-gecko-rendering/ Overview of the Gecko Rendering Pipeline] (Benoit Girard, 2014-10-14)<br />
<br />
=== Parser ===<br />
<br />
The parser's job is to transform a character stream into a tree<br />
structure, with the help of the content sink classes.<br />
<br />
HTML is parsed using a parser implementing the parsing algorithm in the<br />
HTML specification (starting with HTML5). Much of this parser is<br />
translated from Java, and changes are made to the Java version. This<br />
parser in parser/html/. The parser is driven by the output of the networking layer (see nsHtml5StreamParser::OnDataAvailable). The HTML5 parser is capable of parsing off the main thread which is the normal case. It also parses on the main thread to be able to synchronously handle things such as innerHTML modifications.<br />
<br />
The codebase still has the previous generation HTML parser, which is<br />
still used for a small number of things, though we hope to be able to<br />
remove it entirely soon. This parser is in parser/htmlparser/.<br />
<br />
XML is parsed using the expat library (parser/expat/) and code that<br />
wraps it (parser/xml/). This is a non-validating parser; however, it<br />
loads certain DTDs to support XUL localization.<br />
<br />
=== DOM / Content ===<br />
<br />
The content tree or DOM tree is the central data structure for Web<br />
pages. It is a tree structure, initially created from the tree<br />
structure expressed in the HTML or XML markup. The nodes in the tree<br />
implement major parts of the DOM (Document Object Model) specifications.<br />
The nodes themselves are part of a class hierarchy rooted at<br />
<code>nsINode</code>; different derived classes are used for things such<br />
as text nodes, the document itself, HTML elements, SVG elements, etc.,<br />
with further subclasses of many of these types (e.g., for specific HTML<br />
elements). Many of the APIs available to script running in Web pages<br />
are associated with these nodes. The tree structure persists while the<br />
Web pages is displayed, since it stores much of state associated with<br />
the Web page. The code for these nodes lives in the content/ directory.<br />
<br />
The DOM APIs are not threadsafe. DOM nodes can be accessed only from<br />
the main thread (also known as the UI thread (user interface thread)) of<br />
the application.<br />
<br />
There are also many other APIs available to Web pages that are not APIs<br />
on the nodes in the DOM tree. Many of these other APIs also live in the<br />
same directories, though some live in content/ and some in dom/. These<br />
include APIs such as the DOM event model.<br />
<br />
The dom/ directory also includes some of the code needed to expose Web<br />
APIs to JavaScript (in other words, the glue code between JavaScript and<br />
these APIs). For an overview, see [https://ask.mozilla.org/question/390/how-is-the-web-exposed-dom-implemented/ DOM API Implementation]. See [[#Scripting|Scripting]] below for details of the JS engine.<br />
<br />
TODO: Internal APIs vs. DOM APIs.<br />
<br />
TODO: Mutation observers / document observers.<br />
<br />
TODO: Reference counting and cycle collection.<br />
<br />
TODO: specification links<br />
<br />
=== Style System ===<br />
<br />
==== Quantum CSS (Stylo) ====<br />
<br />
Starting with Firefox 57 and later, Gecko makes use of the parallel style system written in Rust that comes from Servo. There's an [https://hacks.mozilla.org/2017/08/inside-a-super-fast-css-engine-quantum-css-aka-stylo/ overview] of this with graphics to help explain what's going on. The [https://github.com/servo/servo/wiki/Layout-Overview Servo wiki] has some more details.<br />
<br />
==== Gecko ====<br />
<br />
The rest of the style section section describes the Gecko style system used in Firefox 56 and earlier. Some bits may still apply, but it likely needs revising.<br />
<br />
In order to display the content, Gecko needs to compute the styles<br />
relevant to each DOM node. It does this based on the model described in<br />
the CSS specifications: this model applies to style specified in CSS<br />
(e.g. by a 'style' element, an 'xml-stylesheet' processing instruction<br />
or a 'style' attribute),<br />
style specified by presentation attributes, and the default style<br />
specified by our own user agent style sheets. There are two major<br />
sets of data structures within the style system:<br />
* first, data structures that represent sources of style data, such as CSS style sheets or data from stylistic HTML attributes<br />
* second, data structures that represent computed style for a given DOM node.<br />
These sets of data structures are mostly distinct (for example, they<br />
store values in different ways).<br />
<br />
The loading of CSS style sheets from the network is managed by the <br />
[https://dxr.mozilla.org/mozilla-central/source/layout/style/Loader.h CSS loader]; <br />
they are then tokenized by the <br />
[https://dxr.mozilla.org/mozilla-central/source/layout/style/nsCSSScanner.h CSS scanner] <br />
and parsed by the <br />
[https://dxr.mozilla.org/mozilla-central/source/layout/style/nsCSSParser.h CSS parser]. <br />
Those that are attached to the document also expose APIs to<br />
script that are known as the CSS Object Model, or CSSOM.<br />
<br />
The style sheets that apply to a document are managed by a class called<br />
the [https://dxr.mozilla.org/mozilla-central/source/layout/style/nsStyleSet.h style set].<br />
The style set interacts with the different types of<br />
style sheets (representing CSS style sheets, presentational<br />
attributes, and 'style' attributes) through two interfaces:<br />
[http://dxr.mozilla.org/mozilla-central/source/layout/style/nsIStyleSheet.h nsIStyleSheet] for basic management of style sheets and<br />
[http://dxr.mozilla.org/mozilla-central/source/layout/style/nsIStyleRuleProcessor.h nsIStyleRuleProcessor] for getting the style data out of them. Usually<br />
the same object implements both interfaces, except in the most important<br />
case, CSS style sheets, where there is a single rule processor for all<br />
of the CSS style sheets in each origin (user/UA/author) of the CSS cascade.<br />
<br />
The computed style data for an element/frame are exposed to the rest of<br />
Gecko through the class mozilla::ComputedStyle (previously called<br />
nsStyleContext). Rather than having a member variable for each<br />
CSS property, it breaks up the properties into groups of related<br />
properties called style structs. These style structs obey the rule that<br />
all of the properties in a single struct either inherit by default (what<br />
the CSS specifications call "Inherited: yes" in the definition of<br />
properties; we call these inherited structs) or all are not inherited by<br />
default (we call these reset structs). Separating the properties in<br />
this way improves the ability to share the structs between similar<br />
ComputedStyle objects and reduce the amount of memory needed to store<br />
the style data. The ComputedStyle API exposes a method for getting each<br />
struct, so you'll see code like<br />
<code>sc->GetStyleText()->mTextAlign</code> for getting the value of the<br />
text-align CSS property. (Frames (see the Layout section below) also<br />
have the same<br />
GetStyle* methods, which just forward the call to the frame's<br />
ComputedStyle.)<br />
<br />
The ComputedStyles form a tree structure, in a shape somewhat like the<br />
content tree (except that we coalesce identical sibling ComputedStyles<br />
rather than keeping two of them around; if the parents have been<br />
coalesced then this can apply recursively and coalasce cousins, etc.;<br />
we do not coalesce parent/child ComputedStyles).<br />
The parent of a ComputedStyle has the style data that the ComputedStyle<br />
inherits from when CSS inheritance occurs. This means that the parent<br />
of the ComputedStyle for a DOM element is generally the ComputedStyle<br />
for that DOM element's parent, since that's how CSS says inheritance<br />
works.<br />
<br />
The process of turning the style sheets into computed style data goes<br />
through three main steps, the first two of which closely relate to the<br />
[http://dxr.mozilla.org/mozilla-central/source/layout/style/nsIStyleRule.h nsIStyleRule] interface, which represents an immutable source of style<br />
data, conceptually representing (and for CSS style rules, directly<br />
storing) a set of property:value pairs. (It is similar to the idea of a<br />
CSS style rule, except that it is immutable; this immutability allows<br />
for significant optimization. When a CSS style rule is changed through<br />
script, we create a new style rule.)<br />
<br />
The first step of going from style sheets to computed style data is<br />
finding the ordered sequence of style rules that apply to an element.<br />
The order represents which rules override which other rules: if two<br />
rules have a value for the same property, the higher ranking one wins.<br />
(Note that there's another difference from CSS style rules: declarations<br />
with !important are represented using a separate style rule.) This is<br />
done by calling one of the nsIStyleRuleProcessor::RulesMatching methods.<br />
The ordered sequence is stored in a<br />
[http://en.wikipedia.org/wiki/Trie trie] called the rule tree: the path<br />
from the root of the rule tree to any (leaf or non-leaf) node in the<br />
rule tree represents a sequence of rules, with the highest ranking<br />
farthest from the root. Each rule node (except for the root) has a<br />
pointer to a rule, but since a rule may appear in many sequences, there<br />
are sometimes many rule nodes pointing to the same rule. Once we have<br />
this list we create a ComputedStyle (or find an appropriate existing<br />
sibling) with the correct parent pointer (for inheritance) and rule node<br />
pointer (for the list of rules), and a few other pieces of information<br />
(like the pseudo-element).<br />
<br />
The second step of going from style sheets to computed style data is<br />
getting the winning property:value pairs from the rules. (This only<br />
provides property:value pairs for some of the properties; the remaining<br />
properties will fall back to inheritance or to their initial values<br />
depending on whether the property is inherited by default.) We do this<br />
step (and the third) for each style struct, the first time it is needed.<br />
This is done in nsRuleNode::WalkRuleTree, where we ask each style rule<br />
to fill in its property:value pairs by calling its MapRuleInfoInto<br />
function. When called, the rule fills in only those pairs that haven't<br />
been filled in already, since we're calling from the highest priority<br />
rule to the lowest (since in many cases this allows us to stop before<br />
going through the whole list, or to do partial computation that just<br />
adds to data cached higher in the rule tree).<br />
<br />
The third step of going from style sheets to computed style data (which<br />
various caching optimizations allow us to skip in many cases) is<br />
actually doing the computation; this generally means we transform the<br />
style data into the data type described in the "Computed Value" line in<br />
the property's definition in the CSS specifications. This<br />
transformation happens in functions called nsRuleNode::Compute*Data,<br />
where the * in the middle represents the name of the style struct. This<br />
is where the transformation from the style sheet value storage format to<br />
the computed value storage format happens.<br />
<br />
Once we have the computed style data, we then store it: if a style struct<br />
in the computed style data doesn't<br />
depend on inherited values or on data from other style structs, then we<br />
can cache it in the rule tree (and then reuse it, without recomputing<br />
it, for any ComputedStyles pointing to that rule node). Otherwise, we<br />
store it on the ComputedStyle (in which case it may be shared<br />
with the ComputedStyle's descendant ComputedStyles).<br />
This is where keeping inherited and<br />
non-inherited properties separate is useful: in the common case of<br />
relatively few properties being specified, we can generally cache the<br />
non-inherited structs in the rule tree, and we can generally share the<br />
inherited structs up and down the ComputedStyle tree.<br />
<br />
The ownership models in style sheet structures are a mix of reference<br />
counted structures (for things accessible from script) and directly<br />
owned structures. ComputedStyles are reference counted, and own their<br />
parents (from which they inherit), and rule nodes are garbage collected<br />
with a simple mark and sweep collector (which often never needs to run).<br />
<br />
* code: [http://dxr.mozilla.org/mozilla-central/source/layout/style/ layout/style/], where most files have useful one line descriptions at the top that show up in DXR<br />
* Bugzilla: Style System (CSS)<br />
* specifications<br />
** [http://www.w3.org/TR/CSS21/ CSS 2.1]<br />
** [http://www.w3.org/TR/css-2010/ CSS 2010, listing stable css3 modules]<br />
** [http://dev.w3.org/csswg/ CSS WG editors drafts] (often more current, but sometimes more unstable than the drafts on the technical reports page)<br />
** [http://dbaron.org/mozilla/visited-privacy Preventing attacks on a user's history through CSS :visited selectors]<br />
* documentation<br />
** [http://www-archive.mozilla.org/newlayout/doc/style-system.html style system documentation] (somewhat out of date)<br />
<br />
=== Layout ===<br />
<br />
Much of the layout code deals with operations on the frame tree (or<br />
rendering tree). In the frame tree, each node represents a rectangle<br />
(or, for SVG, other shapes). The frame tree has a shape similar to the<br />
content tree, since many content nodes have one corresponding frame,<br />
though it differs in a few ways, since some content nodes have more than<br />
one frame or don't have any frames at all. When elements are<br />
display:none in CSS or undisplayed for certain other reasons, they won't<br />
have any frames. When elements are broken across lines or pages, they<br />
have multiple frames; elements may also have multiple frames when<br />
multiple frames nested inside each other are needed to display a single<br />
element (for example, a table, a table cell, or many types of form<br />
controls).<br />
<br />
Each node in the frame tree is an instance of a class derived from<br />
<code>nsIFrame</code>. As with the content tree, there is a substantial<br />
type hierarchy, but the type hierarchy is very different: it includes<br />
types like text frames, blocks and inlines, the various parts of tables,<br />
and the various types of HTML form controls.<br />
<br />
Frames are allocated within an arena owned by the pres shell. Each<br />
frame is owned by its parent; frames are not reference counted, and code<br />
must not hold on to pointers to frames. To mitigate potential security<br />
bugs when pointers to destroyed frames, we use<br />
[http://robert.ocallahan.org/2010/10/mitigating-dangling-pointer-bugs-using_15.html frame poisoning], which takes two parts. When a frame is destroyed<br />
other than at the end of life of the presentation, we fill its memory<br />
with a pattern consisting of a repeated pointer to inaccessible memory,<br />
and then put the memory on a per-frame-class freelist. This means that<br />
if code accesses the memory through a dangling pointer, it will either<br />
crash quickly by dereferencing the poison pattern or it will find a<br />
valid frame.<br />
<br />
Like the content tree, frames must be accessed only from the UI thread.<br />
<br />
The frame tree should not store any important data. While it does<br />
usually persist while a page is being displayed, frames are often<br />
destroyed and recreated in response to certain style changes, and in the<br />
future we may do the same to reduce memory use for pages that are<br />
currently inactive. There were a number of cases where this rule was<br />
violated in the past and we stored important data in the frame tree;<br />
however, most (though not quite all) such cases are now fixed.<br />
<br />
The rectangle represented by the frame is what CSS calls the element's<br />
border box. This is the outside edge of the border (or the inside edge<br />
of the margin). The margin lives outside the border; and the padding<br />
lives inside the border. In addition to nsIFrame::GetRect, we also have<br />
the APIs nsIFrame::GetPaddingRect to get the padding box (the outside<br />
edge of the padding, or inside edge of the border) and<br />
nsIFrame::GetContentRect to get the content box (the outside edge of the<br />
content, or inside edge of the padding). These APIs may produce out of<br />
date results when reflow is needed (or has not yet occurred).<br />
<br />
In addition to tracking a rectangle, frames also track two overflow<br />
areas: visual overflow and scrollable overflow. These overflow areas<br />
represent the union of the area needed by the frame and by all its<br />
descendants. The visual overflow is used for painting-related<br />
optimizations: it is a rectangle covering all of the area that might be<br />
painted when the frame and all of its descendants paint. The scrollable<br />
overflow represents the area that the user should be able to scroll to<br />
to see the frame and all of its descendants. In some cases differences<br />
between the frame's rect and its overflow happen because of descendants<br />
that stick out of the frame; in other cases they occur because of some<br />
characteristic of the frame itself. The two overflow areas are<br />
similar, but there are differences: for example, margins are part of<br />
scrollable overflow but not visual overflow, whereas text-shadows are<br />
part of visual overflow but not scrollable overflow.<br />
<br />
When frames are broken across lines, columns, or pages, we create<br />
multiple frames representing the multiple rectangles of the element.<br />
The first one is the primary frame, and the rest are its continuations<br />
(which are more likely to be destroyed and recreated during reflow).<br />
These frames are linked together as continuations: they have a<br />
doubly-linked list that can be used to traverse the continuations using<br />
nsIFrame::GetPrevContinuation and nsIFrame::GetNextContinuation.<br />
(Currently continuations always have the same style data, though we may<br />
at some point want to break that invariant.)<br />
<br />
Continuations are sometimes siblings of each other, and sometimes not.<br />
For example, if a paragraph contains a span which contains a link, and<br />
the link is split across lines, then the continuations of the span are<br />
siblings (since they are both children of the paragraph), but the<br />
continuations of the link are not siblings (since each continuation of<br />
the link is descended from a different continuation of the span).<br />
Traversing the entire frame tree does '''not''' require considering<br />
continuations, since all of the continuations are descendants of the<br />
element containing the break.<br />
<br />
We also use continuations for cases (most importantly, bidi reordering,<br />
where left-to-right text and right-to-left text need to be separated<br />
into different continuations since they may not form a contiguous<br />
rectangle) where the continuations should not be rewrapped during<br />
reflow: we call these continuations fixed rather than fluid.<br />
nsIFrame::GetNextInFlow and nsIFrame::GetPrevInFlow traverse only the<br />
fluid continuations and do not cross fixed continuation boundaries.<br />
<br />
If an inline frame has non-inline children, then we split the original <br />
inline frame into parts. The original inline's children are <br />
distributed into these parts like so- The children of the original <br />
inline are grouped into runs of inline and non-inline and runs of <br />
inline get an inline parent while runs of non-inline get an anonymous <br />
block parent. This is 'ib-splitting' or block-inside-inline-splitting. <br />
This splitting proceeds recursively up the frame tree until all <br />
non-inlines inside inlines are ancestors of a block frame with anonymous <br />
block wrappers in between. This splitting maintains the relative order<br />
between these child frames and the relationship between the parts of a <br />
split inline is maintained using an ib-sibling chain. It is important <br />
to note that any wrappers created during frame construction (such as <br />
for tables) may not be included in the ib-sibling chain depending on <br />
when this wrapper creation takes place. <br />
<br />
TODO: nsBox craziness from https://bugzilla.mozilla.org/show_bug.cgi?id=524925#c64<br />
<br />
TODO: link to documentation of block and inline layout<br />
<br />
TODO: link to documentation of scrollframes<br />
<br />
TODO: link to documentation of XUL frame classes<br />
<br />
Code (note that most files in base and generic have useful one line descriptions at the top that show up in DXR):<br />
* [http://dxr.mozilla.org/mozilla-central/source/layout/base/ layout/base/] contains objects that coordinate everything and a bunch of other miscellaneous things<br />
* [http://dxr.mozilla.org/mozilla-central/source/layout/generic/ layout/generic/] contains the basic frame classes as well as support code for their reflow methods (ReflowInput, ReflowOutput)<br />
* [http://dxr.mozilla.org/mozilla-central/source/layout/forms/ layout/forms/] contains frame classes for HTML form controls<br />
* [http://dxr.mozilla.org/mozilla-central/source/layout/tables/ layout/tables/] contains frame classes for CSS/HTML tables<br />
* [http://dxr.mozilla.org/mozilla-central/source/layout/mathml/ layout/mathml/] contains frame classes for MathML<br />
* [http://dxr.mozilla.org/mozilla-central/source/layout/svg/ layout/svg/] contains frame classes for SVG<br />
* [http://dxr.mozilla.org/mozilla-central/source/layout/xul/ layout/xul/] contains frame classes for the XUL box model and for various XUL widgets<br />
<br />
Bugzilla:<br />
* All of the components whose names begin with "Layout" in the "Core" product<br />
<br />
Further documentation:<br />
* Talk: [https://air.mozilla.org/introduction-to-graphics-layout-architecture/ Introduction to graphics/layout architecture] (Robert O'Callahan, 2014-04-18)<br />
* Talk: [https://air.mozilla.org/bz-layout-and-styles/ Layout and Styles] (Boris Zbarsky, 2014-10-14)<br />
<br />
<br />
==== Frame Construction ====<br />
<br />
Frame construction is the process of creating frames. This is done when styles change in ways that require frames to be created or recreated or when nodes are inserted into the document. The content tree and the frame tree don't have quite the same shape, and the frame construction process does some of the work of creating the right shape for the frame tree. It handles the aspects of creating the right shape that don't depend on layout information. So for example, frame construction handles the work needed to implement [http://www.w3.org/TR/CSS21/tables.html#anonymous-boxes table anonymous objects] but does not handle frames that need to be created when an element is broken across lines or pages.<br />
<br />
The basic unit of frame construction is a run of contiguous children of a single parent element. When asked to construct frames for such a run of children, the frame constructor first determines, based on the siblings and parent of the nodes involved, where in the frame tree the new frames should be inserted. Then the frame constructor walks through the list of content nodes involved and for each one creates a temporary data structure called a '''frame construction item'''. The frame construction item encapsulates various information needed to create the frames for the content node: its style data, some metadata about how one would create a frame for this node based on its namespace, tag name, and styles, and some data about what sort of frame will be created. This list of frame construction items is then analyzed to see whether constructing frames based on it and inserting them at the chosen insertion point will produce a valid frame tree. If it will not, the frame constructor either fixes up the list of frame construction items so that the resulting frame tree would be valid or throws away the list of frame construction items and requests the destruction and re-creation of the frame for the parent element so that it has a chance to create a list of frame construction items that it <em>can</em> fix up.<br />
<br />
Once the frame constructor has a list of frame construction items and an insertion point that would lead to a valid frame tree, it goes ahead and creates frames based on those items. Creation of a non-leaf frame recursively attempts to create frames for the children of that frame's element, so in effect frames are created in a depth-first traversal of the content tree.<br />
<br />
The vast majority of the code in the frame constructor, therefore, falls into one of these categories:<br />
* Code to determine the correct insertion point in the frame tree for new frames.<br />
* Code to create, for a given content node, frame construction items. This involves some searches through static data tables for metadata about the frame to be created.<br />
* Code to analyze the list of frame construction items.<br />
* Code to fix up the list of frame construction items.<br />
* Code to create frames from frame construction items.<br />
<br />
Code: [http://dxr.mozilla.org/mozilla-central/source/layout/base/nsCSSFrameConstructor.h layout/base/nsCSSFrameConstructor.h] and [http://dxr.mozilla.org/mozilla-central/source/layout/base/nsCSSFrameConstructor.cpp layout/base/nsCSSFrameConstructor.cpp]<br />
<br />
==== Reflow ====<br />
<br />
Reflow is the process of computing the positions and sizes of frames. (After all,<br />
frames represent rectangles, and at some point we need to figure out<br />
exactly *what* rectangle.) Reflow is done recursively, with each<br />
frame's Reflow method calling the Reflow methods on that frame's<br />
descendants.<br />
<br />
In many cases, the correct results are defined by CSS specifications<br />
(particularly [http://www.w3.org/TR/CSS21/visudet.html CSS 2.1]). In some cases, the details are not defined by<br />
CSS, though in some (but not all) of those cases we are constrained by<br />
Web compatibility. When the details are defined by CSS, however, the<br />
code to compute the layout is generally structured somewhat differently<br />
from the way it is described in the CSS specifications, since the CSS<br />
specifications are generally written in terms of constraints, whereas<br />
our layout code consists of algorithms optimized for incremental<br />
recomputation.<br />
<br />
The reflow generally starts from the root of the frame tree, though some other<br />
types of frame can act as reflow roots and start a reflow from them.<br />
Reflow roots must obey the invariant that a change inside one of their<br />
descendants never changes their rect or overflow areas (though currently<br />
scrollbars are reflow roots but don't quite obey this invariant).<br />
<br />
In many cases, we want to reflow a part of the frame tree, and we want<br />
this reflow to be efficient. For example, when content is added or<br />
removed from the document tree or when styles change, we want the amount<br />
of work we need to redo to be proportional to the amount of content. We<br />
also want to efficiently handle a series of changes to the same content.<br />
<br />
To do this, we maintain two bits on frames:<br />
[http://dxr.mozilla.org/mozilla-central/search?q=var%3ANS_FRAME_IS_DIRTY&case=true&redirect=true NS_FRAME_IS_DIRTY]<br />
indicates that a frame and all of its descendants require reflow.<br />
[http://dxr.mozilla.org/mozilla-central/search?q=var%3ANS_FRAME_HAS_DIRTY_CHILDREN&case=true&redirect=true NS_FRAME_HAS_DIRTY_CHILDREN]<br />
indicates that a frame has a descendant that<br />
is dirty or has had a descendant removed (i.e., that it has a child that<br />
has NS_FRAME_IS_DIRTY or NS_FRAME_HAS_DIRTY_CHILDREN or it had a child<br />
removed). These bits allow coalescing of multiple updates; this<br />
coalescing is done in nsPresShell, which tracks the set of reflow roots<br />
that require reflow. The bits are set during calls to<br />
nsPresShell::FrameNeedsReflow and are cleared during reflow.<br />
<br />
The layout algorithms used by many of the frame classes are those<br />
specified in CSS, which are based on the traditional document formatting<br />
model, where widths are input and heights are output.<br />
<br />
In some cases, however, widths need to be determined based on the<br />
content. This depends on two ''intrinsic widths'': the minimum<br />
intrinsic width (see [http://dxr.mozilla.org/search?q=type%3AnsIFrame%20function%3AGetMinWidth&tree=mozilla-central nsIFrame::GetMinWidth]) and the preferred intrinsic<br />
width (see [http://dxr.mozilla.org/search?q=type%3AnsIFrame%20function%3AGetPrefWidth&tree=mozilla-central nsIFrame::GetPrefWidth]). The concept of what these widths<br />
represent is best explained by describing what they are on a paragraph<br />
containing only text: in such a paragraph the minimum intrinsic width<br />
is the width of the longest word, and the preferred intrinsic width is<br />
the width of the entire paragraph laid out on one line.<br />
<br />
Intrinsic widths are invalidated separately from the dirty bits<br />
described above. When a caller informs the pres shell that a frame<br />
needs reflow (nsIPresShell::FrameNeedsReflow), it passes one of three<br />
options:<br />
* eResize indicates that no intrinsic widths are dirty<br />
* eTreeChange indicates that intrinsic widths on it and its ancestors are dirty (which happens, for example, if new children are added to it)<br />
* eStyleChange indicates that intrinsic widths on it, its ancestors, and its descendants are dirty (for example, if the font-size changes)<br />
<br />
Reflow is the area where the XUL frame classes (those that inherit from<br />
nsBoxFrame or nsLeafBoxFrame) are most different from the rest. Instead<br />
of using nsIFrame::Reflow, they do their layout computations using<br />
intrinsic size methods called GetMinSize, GetPrefSize, and GetMaxSize<br />
(which report intrinsic sizes in two dimensions) and a final layout<br />
method called Layout. In many cases these methods defer some of the<br />
computation to a separate object called a layout manager.<br />
<br />
When an individual frame's Reflow method is called, most of the input is<br />
provided on an object called ReflowInput and the output is filled<br />
in to an object called ReflowOutput. After reflow, the caller<br />
(usually the parent) is responsible for setting the frame's size based<br />
on the metrics reported. (This can make some computations during reflow<br />
difficult, since the new size is found in either the reflow state or the<br />
metrics, but the frame's size is still the old size. However, it's<br />
useful for invalidating the correct areas that need to be repainted.)<br />
<br />
One major difference worth noting is that in XUL layout, the size of the<br />
child is set prior to its parent calling its Layout method. (Once<br />
invalidation uses display lists and is no longer tangled up in Reflow,<br />
it may be worth switching non-XUL layout to work this way as well.)<br />
<br />
==== Painting ====<br />
<br />
TODO: display lists (and event handling)<br />
<br />
TODO: layers<br />
<br />
==== Pagination ====<br />
<br />
The concepts behind pagination (also known as fragmentation) are a bit complicated, so for now we've split them off into a separate document: [[Gecko:Continuation_Model]]. This code is used for printing, print-preview, and multicolumn frames.<br />
<br />
=== Dynamic change handling along the rendering pipeline ===<br />
<br />
The ability to make changes to the DOM from script is a major feature of the Web platform. Web authors rely on the concept (though there are a few exceptions, such as animations) that changing the DOM from script leads to the same rendering that would have resulted from starting from that DOM tree. They also rely on the performance characteristics of these changes: small changes to the DOM that have small effects should have proportionally small processing time. This means that Gecko needs to efficiently propagate changes from the content tree to style, the frame tree, the geometry of the frame tree, and the screen.<br />
<br />
For many types of changes, however, there is substantial overhead to processing a change, no matter how small. For example, reflow must propagate from the top of the frame tree down to the frames that are dirty, no matter how small the change. One very common way around this is to batch up changes. We batch up changes in lots of ways, for example:<br />
* The content sink adds multiple nodes to the DOM tree before notifying listeners that they've been added. This allows notifying once about an ancestor rather than for each of its descendants, or notifying about a group of descendants all at once, which speeds up the processing of those notifications.<br />
* We batch up nodes that require style reresolution (recomputation of selector matching and processing the resulting style changes). This batching is tree based, so it not only merges multiple notifications on the same element, but also merges a notification on an ancestor with a notification on its descendant (since ''some'' of these notifications imply that style reresolution is required on all descendants).<br />
* We wait to reconstruct frames that require reconstruction (after destroying frames eagerly). This, like the tree-based style reresolution batching, avoids duplication both for same-element notifications and ancestor-descendant notifications, even though it doesn't actually do any tree-based caching.<br />
* We postpone doing reflows until needed. As for style reresolution, this maintains tree-based dirty bits (see the description of NS_FRAME_IS_DIRTY and NS_FRAME_HAS_DIRTY_CHILDREN under Reflow).<br />
* We allow the OS to queue up multiple invalidates before repainting (though we will likely switch to controlling that ourselves). This leads to a single repaint of some set of pixels where there might otherwise have been multiple (though it may also lead to more pixels being repainted if multiple rectangles are merged to a single one).<br />
<br />
Having changes buffered up means, however, that various pieces of information (layout, style, etc.) may not be up-to-date. Some things require up-to-date information: for example, we don't want to expose the details of our buffering to Web page script since the programming model of Web page script assumes that DOM changes take effect "immediately", i.e., that the script shouldn't be able to detect any buffering. Many Web pages depend on this.<br />
<br />
We therefore have ways to flush these different sorts of buffers. There are methods called FlushPendingNotifications on nsIDocument and nsIPresShell, that take an argument of what things to flush:<br />
* Flush_Content: create all the content nodes from data buffered in the parser<br />
* Flush_ContentAndNotify: the above, plus notify document observers about the creation of all nodes created so far<br />
* Flush_Style: the above, plus make sure style data are up-to-date<br />
* Flush_Frames: the above, plus make sure all frame construction has happened (currently the same as Flush_Style)<br />
* Flush_InterruptibleLayout: the above, plus perform layout (Reflow), but allow interrupting layout if it takes too long<br />
* Flush_Layout: the above, plus ensure layout (Reflow) runs to completion<br />
* Flush_Display (should never be used): the above, plus ensure repainting happens<br />
<br />
The major way that notifications of changes propagate from the content code to layout and other areas of code is through the nsIDocumentObserver and nsIMutationObserver interfaces. Classes can implement this interface to listen to notifications of changes for an entire document or for a subtree of the content tree.<br />
<br />
WRITE ME: ... layout document observer implementations<br />
<br />
TODO: how style system optimizes away rerunning selector matching<br />
<br />
TODO: style changes and nsChangeHint<br />
<br />
=== Refresh driver ===<br />
<br />
== Graphics ==<br />
[https://wiki.mozilla.org/Platform/GFX Wiki page] | [https://wiki.mozilla.org/index.php?title=Platform/GFX/Contribute contribute]<br />
<br />
Further documentation:<br />
* Talk: [https://air.mozilla.org/introduction-to-graphics-layout-architecture/ Introduction to graphics/layout architecture] (Robert O'Callahan, 2014-04-18)<br />
* Talk: [https://air.mozilla.org/bjacob-gfx-overview/ An overview of Gecko's graphics stack] (Benoit Jacob, 2014-08-12)<br />
* Talk: [https://air.mozilla.org/jeff-muizelaar-2d-graphics/ 2D Graphics] (Jeff Muizelaar, 2014-10-14)<br />
<br />
==== Painting/Rasterizing ====<br />
<br />
Painting/rendering/rasterizing is the step where graphical primitives (such as a command to fill an [https://developer.mozilla.org/en-US/docs/Web/SVG SVG] circle, or a [https://developer.mozilla.org/en-US/docs/Web/Guide/Graphics/Drawing_graphics_with_canvas canvas] command to stroke a path between x, y, z, or the internally produced command to draw the edge of an HTML div's border) are used to color in the pixels of a surface so that the surface "displays" those rasterized primitives.<br />
<br />
The platform independent library that gecko uses to render is [http://dxr.mozilla.org/mozilla-central/source/gfx/2d/2D.h Moz2D]. Gecko code paints into Moz2D DrawTarget objects (the DrawTarget baseclass having multiple platform dependent subclasses). (At least this is where gecko is going - for now there is still significant amounts of code that uses [http://dxr.mozilla.org/mozilla-central/source/gfx/thebes/gfxContext.h Thebes gfxContext] objects or the even older nsRenderingContext objects. Objects of these types now always wrap a DrawTarget so all painting does now go through Moz2D, but conversion to use the wrapped DrawTargets directly is taking time since consumer code can sometimes need to be radically rewritten to fit the Moz2D API and immediate mode paradigm.)<br />
<br />
==== Compositing ====<br />
<br />
The compositing stage of the rendering pipeline is operated by the [http://dxr.mozilla.org/mozilla-central/source/gfx/layers/ gfx/layers] module.<br />
<br />
Different parts of a web page can sometimes be painted into intermediate surfaces retained by layers. It can be convenient to think of layers as the layers in image manipulation programs like The Gimp or Photoshop. Layers are organized as a tree. Layers are primarily used to minimize invalidating and repainting when elements are being animated independently of one another in a way that can be optimized using layers (e.g. opacity or transform animations), and to enable some effects (such as transparency and 3D transforms).<br />
<br />
Compositing is the action of flattening the layers into the final image that is shown on the screen.<br />
<br />
On some platform, compositing happens on the Content thread. However, on other platforms we composite on a separate thread (Off-main-thread compositing, or OMTC). OMTC is at the moment the default behavior on mobile platforms, but the goal is to do it on all platforms in the long run.<br />
<br />
The Layers architecture is built on the following notions:<br />
* Compositor: an object that can draw quads on the screen (or on an off-screen render target).<br />
* Texture: an object that contains image data.<br />
* Compositable: an object that can manipulate one or several textures, and knows how to present them to the compositor<br />
* Layer: an element of the layer tree. A layer usually doesn't know much about compositing: it uses a compositable to do the work. Layers are mostly nodes of the layer tree.<br />
<br />
[[File:LayersRefactoring.png|thumb|650px|New layers architecture, with OGL backend]]<br />
<br />
The above abstractions are sufficient to perform compositing on the main thread, but on the OMTC case, we need a mechanism to synchronize a client layer tree that is constructed on the content thread, and a host layer tree that is used for compositing on the compositor thread.<br />
This synchronization process must ensure that the host layer tree reflects the state of the current layer tree while remaining in a consistent state, and must transfer texture data from a thread to the other. Moreover, on some platforms the content and compositor threads may live in separate processes.<br />
<br />
To perform this synchronization, we use the IPDL IPC framework. IPDL lets us describe communications protocols and actors in a domain specific language. for more information about IPDL, read https://wiki.mozilla.org/IPDL<br />
<br />
When the client layer tree is modified, we record modifications into messages that are sent together to the host side within a transaction. A transaction is basically a list of modifications to the layer tree that have to be applied all at once to preserve consistency in the state of the host layer tree.<br />
<br />
Texture transfer is done by synchronizing texture objects across processes/threads using a couple TextureClient/TextureHost that wrap shared data and provide access to it on both sides. TextureHosts provide access to one or several TextureSource, which has the necessary API to actually composite the texture (TextureClient/Host being more about IPC synchronization than actual compositing.<br />
The logic behind texture transfer (as in single/double/triple buffering, texture tiling, etc) is operated by the CompositableClient and CompositableHost.<br />
<br />
It is important to understand the separation between layers and compositables. Compositables handle all the logic around texture transfer, while layers define the shape of the layer tree. a Compositable is created independently from a layer and attached to it on both sides. While layers transactions can only originate from the content thread, this separation makes it possible for us to have separate compositable transactions between any thread and the compositor thread. We use the ImageBridge IPDL protocol to that end. The Idea of ImageBridge is to create a Compositable that is manipulated on the ImageBridgeThread, and that can transfer/synchronize textures without using the content thread at all. This is very useful for smooth Video compositing: video frames are decoded and passed into the ImageBridge without ever touching the content thread, which could be busy processing reflows or heavy javascript workloads.<br />
<br />
It is worth reading the inline code documentation in the following files:<br />
* [http://dxr.mozilla.org/mozilla-central/source/gfx/layers/Compositor.h gfx/layers/Compositor.h]<br />
* [http://dxr.mozilla.org/mozilla-central/source/gfx/layers/ShadowLayers.h gfx/layers/ShadowLayers.h]<br />
* [http://dxr.mozilla.org/mozilla-central/source/gfx/layers/Layers.h gfx/layers/Layers.h]<br />
* [http://dxr.mozilla.org/mozilla-central/source/gfx/layers/host/TextureHost.h gfx/layers/host/TextureHost.h]<br />
* [http://dxr.mozilla.org/mozilla-central/source/gfx/layers/client/CompositableClient.h gfx/layers/client/CompositableClient.h]<br />
<br />
To visualize how a web page is layered, turn on the pref "layers.draw-borders" in about:config. When this pref is on, the borders of layers and tiles are displayed on top of the content. This only works when using the new Compositor API, that is when off-main-thread compositing is activated. OMTC is activated by default on all mobile platforms, and will progressively get activated on desktop platforms (not yet, though). On platforms where OMTC is not used, this pref has no effect. <br />
<br />
Blog posts with information on Layers that should be integrated here:<br />
<br />
* [http://www.basschouten.com/blog1.php/layers-cross-platform-acceleration Layers: Cross-Platform Acceleration]<br />
* [http://robert.ocallahan.org/2010/04/layers_01.html Layers]<br />
* [http://robert.ocallahan.org/2010/07/retained-layers_16.html Retained Layers]<br />
* [http://chrislord.net/index.php/2011/07/25/shadow-layers-and-learning-by-failing/ Shadow Layers, and learning by failing]<br />
* [http://chrislord.net/index.php/2011/08/16/accelerated-layer-rendering-and-learning-by-some-success/ Accelerated layer-rendering, and learning by (some) success]<br />
* [http://featherweightmusings.blogspot.co.uk/2012/05/mask-layers_26.html Mask Layers]<br />
* [http://featherweightmusings.blogspot.co.uk/2012/05/building-mask-layer.html Building a mask layer]<br />
* [http://featherweightmusings.blogspot.co.uk/2012/06/mask-layers-on-direct3d-backends.html Mask Layers on the Direct3D backends]<br />
* [http://robert.ocallahan.org/2011/09/graphics-api-design.html Graphics API Design]<br />
<br />
==== Async Panning and Zooming ====<br />
<br />
On some of our mobile platforms we have some code that allows the user to do asynchronous (i.e. off-main-thread) panning and zooming of content. This code is the Async Pan/Zoom module (APZ) code and is further documented at [[Platform/GFX/APZ]].<br />
<br />
== Scripting ==<br />
<br />
=== JavaScript Engine ===<br />
<br />
Gecko embeds the SpiderMonkey JavaScript engine (located in js/src). The JS engine includes a number of Just-In-Time compilers (or JITs). SpiderMonkey provides a powerful and extensive embedding API (called the JSAPI). Because of its complexity, using the JSAPI directly is frowned upon, and a number of abstractions have been built in Gecko to allow interacting with the JS engine without using JSAPI directly. Some JSAPI concepts are important for Gecko developers to understand, and they are listed below:<br />
<br />
* Global object: The '''global object''' is the object on which all global variables/properties/methods live. In a web page this is the 'window' object. In other things such as XPCOM components or sandboxes XPConnect creates a global object with a small number of builtin APIs.<br />
* Compartments: A '''compartment''' is a subdivision of the JS heap. The mapping from global objects to compartments is one-to-one; that is, every global object has a compartment associated with it, and no compartment is associated with more than one global object. (NB: There are compartments associated with no global object, but they aren't very interesting). When JS code is running SpiderMonkey has a concept of a "current" compartment. New objects that are created will be created in the "current" compartment and associated with the global object of that compartment.<br />
* When objects in one compartment can see objects in another compartment (via e.g. iframe.contentWindow.foo) '''cross-compartment wrappers''' or '''CCWs''' mediate the interaction between the two compartments. By default CCWs ensure that the current compartment is kept up-to-date when execution crosses a compartment boundary. SpiderMonkey also allows embeddings to extend wrappers with custom behavior to implement security policies, which Gecko uses extensively (see the Security section for more information).<br />
<br />
Further documentation:<br />
* Talk: [https://air.mozilla.org/kannan-vijayan-baseline-jit/ Baseline JIT] (Kannan Vijayan, 2014-10-14)<br />
<br />
=== XPConnect ===<br />
<br />
'''XPConnect''' is a bridge between C++ and JS used by XPCOM components exposed to or implemented in JavaScript. XPConnect allows two XPCOM components to talk to each other without knowing or caring which language they are implemented in. XPConnect allows JS code to call XPCOM components by exposing XPCOM interfaces as JS objects, and mapping function calls and attributes from JS into virtual method calls on the underlying C++ object. It also allows JS code to implement an XPCOM component that can be called from C++ by faking the vtable of an interface and translating calls on the interface into JS calls. XPConnect accomplishes this using the vtable data stored in XPCOM TypeLibs (or XPT files) by the XPIDL compiler and a small layer of platform specific code called [https://developer.mozilla.org/en-US/docs/xptcall_FAQ xptcall] that knows how to interact with and impersonate vtables of XPCOM interfaces.<br />
<br />
XPConnect is also used for a small (and decreasing) number of legacy DOM objects. At one time all of the DOM used XPConnect to talk to JS, but we have been replacing XPConnect with the WebIDL bindings (see the next section for more information). Arbitrary XPCOM components are not exposed to web content. XPCOM components that want to be accessible to web content must provide class info (that is, they must QI to nsIClassInfo) and must be marked with the nsIClassInfo::DOM_OBJECT flag. Most of these objects also are listed in dom/base/nsDOMClassInfo.cpp, where the interfaces that should be visible to the web are enumerated. This file also houses some "scriptable helpers" (classes ending in "SH" and implementing nsIXPCScriptable), which are a set of optional hooks that can be used by XPConnect objects to implement more exotic behaviors (such as indexed getters or setters, lazily resolved properties, etc). This is all legacy code, and any new DOM code should use the WebIDL bindings.<br />
<br />
=== WebIDL Bindings ===<br />
<br />
The '''WebIDL bindings''' are a separate bridge between C++ and JS that is specifically designed for use by DOM code. We intend to replace all uses of XPConnect to interface with content JavaScript with the WebIDL bindings. [https://developer.mozilla.org/en-US/docs/Mozilla/WebIDL_bindings Extensive documentation] on the WebIDL bindings is available, but the basic idea is that a binding generator takes WebIDL files from web standards and some configuration data provided by us and generates at build time C++ glue code that sits between the JS engine and the DOM object. This setup allows us to produce faster, more specialized code for better performance at the cost of increased codesize.<br />
<br />
The WebIDL bindings also implement all of the behavior specified in WebIDL, making it possible for new additions to the DOM to behave correctly "out of the box". The binding layer also provides C++ abstractions for types that would otherwise require direct JSAPI calls to handle, such as typed arrays. <br />
<br />
=== Security ===<br />
<br />
Gecko's JS security model is based on the concept of compartments. Every compartment has a '''principal''' associated with it that contains security information such as the '''origin''' of the compartment, whether or not it has system privileges, etc. For the following discussion, '''wrappee''' refers to the underlying object being wrapped, '''scope''' refers to the compartment the object is being wrapped for use in, and '''wrapper''' refers to the object created in '''scope''' that allows it to interact with '''wrappee'''. "Chrome" refers to JS that is built in to the browser or part of an extension, which runs with full privileges, and is contrasted with "content", which is web provided script that is subject to security restrictions and the same origin policy.<br />
<br />
* Xray wrappers: Xray wrappers are used when the scope has chrome privileges and the wrappee is the JS reflection of an underlying DOM object. Beyond the usual CCW duties of making sure that content code does not run with chrome privileges, Xray wrappers also ensure that calling methods or accessing attributes on the wrappee has the "expected" effect. For example, a web page could replace the <code>close</code> method on its window with a JS function that does something completely different. (e.g. <code>window.close = function() { alert("This isn't what you wanted!") };</code>). Overwriting methods in this way (or creating entirely new ones) is referred to as '''expando''' properties. Xrays see through expando properties, invoking the original method/getter/setter if the expando overwrites a builtin or seeing undefined in the expando creates a new property. This allows chrome code to call methods on content DOM objects without worrying about how the page has changed the object.<br />
* Waived xray wrappers: The xray behavior is not always desirable. It is possible for chrome to "waive" the xray behavior and see the actual JS object. The wrapper still guarantees that code runs with the correct privileges, but methods/getters/setters may not behave as expected. This is equivalent to the behavior chrome sees when it looks at non-DOM content JS objects.<br />
* For more information, see the [https://developer.mozilla.org/en-US/docs/Mozilla/Gecko/Script_security MDN page]<br />
* bholley's [https://air.mozilla.org/enter-the-compartment/ Enter the Compartment] talk also provides an overview of our compartment architecture.<br />
<br />
== Images ==<br />
<br />
== Plugins ==<br />
<br />
== Platform-specific layers ==<br />
<br />
* widget<br />
* native theme<br />
* files, networking, other low-level things<br />
* Accessibility APIs<br />
* Input. Touch-input stuff is somewhat described at [[Platform/Input/Touch]].<br />
<br />
== Editor ==<br />
<br />
== Base layers ==<br />
<br />
=== NSPR ===<br />
<br />
NSPR is a library for providing cross-platform APIs for various<br />
platform-specific functions. We tend to be trying to use it as little<br />
as possible, although there are a number of areas (particularly some<br />
network-related APIs and threading/locking primitives) where we use it<br />
quite a bit.<br />
<br />
=== XPCOM ===<br />
<br />
XPCOM is a cross-platform modularity library, modeled on Microsoft COM. It<br />
is an object system in which all objects inherit from the <code>nsISupports</code> interface.<br />
<br />
components and services, contract IDs and CIDs<br />
<br />
prior overuse of XPCOM; littering with XPCOM does not produce modularity<br />
<br />
Base headers (part of xpcom/base/) and data structures. See also mfbt.<br />
<br />
Threading<br />
<br />
xptcall, proxies<br />
<br />
reference counting, cycle collection<br />
<br />
Further documentation:<br />
* XPCOM and Internal Strings in Gecko (talk by David Baron, 2014-03-20): [https://air.mozilla.org/xpcom-and-internal-strings-in-gecko/ video], [https://dbaron.org/talks/2014-03-20-xpcom-string-taipei/speaking-notes speaking notes]<br />
<br />
=== String ===<br />
<br />
XPCOM has string classes for representing sequences of characters. Typical C++ string classes have the goals of encapsulating the memory management of buffers and the issues needed to avoid buffer overruns common in traditional C string handling. Mozilla's string classes have these goals, and also the goal of reducing copying of strings.<br />
<br />
(There is a second set of string classes in xpcom/glue for callers outside of libxul; these classes are partially source-compatible but have different (worse) performance characteristics. This discussion does not cover those classes.)<br />
<br />
We have two parallel sets of classes, one for strings with 1-byte units (<code>char</code>, which may be signed or unsigned), and one for strings with 2-byte units (<code>char16_t</code>, always unsigned). The classes are named such that the class for 2-byte characters ends with <code>String</code> and the corresponding class for 1-byte characters ends with <code>CString</code>. 2-byte strings are almost always used to encode [http://en.wikipedia.org/wiki/UTF-16 UTF-16]. 1-byte strings are usually used to encode either [http://en.wikipedia.org/wiki/ASCII ASCII] or [http://en.wikipedia.org/wiki/UTF-8 UTF-8], but are sometimes also used to hold data in some other encoding or just byte sequences.<br />
<br />
The string classes distinguish, as part of the type hierarchy, between strings that must have a null-terminator at the end of their buffer (<code>ns[C]String</code>) and strings that are not required to have a null-terminator (<code>ns[C]Substring</code>). <code>ns[C]Substring</code> is the base of the string classes (since it imposes fewer requirements) and <code>ns[C]String</code> is a class derived from it. Functions taking strings as parameters should generally take one of these four types.<br />
<br />
In order to avoid unnecessary copying of string data (which can have significant performance cost), the string classes support different ownership models. All string classes support the following three ownership models dynamically:<br />
* reference counted, copy-on-write, buffers (the default)<br />
* adopted buffers (a buffer that the string class owns, but is not reference counted, because it came from somewhere else)<br />
* dependent buffers, that is, an underlying buffer that the string class does not own, but that the caller that constructed the string guarantees will outlive the string instance<br />
In addition, there is a special string class, <code>nsAuto[C]String</code>, that ''additionally'' contains an internal 64-unit buffer (intended primarily for use on the stack), leading to a fourth ownership model:<br />
* storage within an auto string's stack buffer<br />
Auto strings will prefer reference counting an existing reference-counted buffer over their stack buffer, but will otherwise use their stack buffer for anything that will fit in it.<br />
<br />
There are a number of additional string classes, particularly <code>nsDependent[C]String</code>, <code>nsDependent[C]Substring</code>, and the <code>NS_LITERAL_[C]STRING</code> macros which construct an <code>nsLiteral[C]String</code> which exist primarily as constructors for the other types. These types are really just convenient notation for constructing an <code>ns[C]S[ubs]tring</code> with a non-default ownership mode; they should not be thought of as different types. (The <code>Substring</code>, <code>StringHead</code>, and <code>StringTail</code> functions are also constructors for dependent [sub]strings.) Non-default ownership modes can also be set up using the <code>Rebind</code> and <code>Adopt</code> methods, although the <code>Rebind</code> methods actually live on the derived types, which is probably a mistake (although moving them up would require some care to avoid making an API that easily allows assigning a non-null-terminated buffer to a string whose static type indicates that it is null-terminated).<br />
<br />
Note that the presence of all of these classes imposes some awkwardness in terms of distinctions being available as both static type distinctions and dynamic type distinctions. In general, the only distinctions that should be made statically are 1-byte vs. 2-byte sequences (<code>CString</code> vs <code>String</code>) and whether the buffer is null-terminated or not (<code>Substring</code> vs <code>String</code>). (Does the code actually do a good job of dynamically enforcing the <code>Substring</code> vs. <code>String</code> restriction?)<br />
<br />
TODO: buffer growth, concatenation optimizations<br />
<br />
TODO: encoding conversion, what's validated and what isn't<br />
<br />
TODO: "string API", nsAString (historical)<br />
<br />
* Code: xpcom/string/<br />
* Bugzilla: Core::String<br />
<br />
Further documentation:<br />
* XPCOM and Internal Strings in Gecko (talk by David Baron, 2014-03-20): [https://air.mozilla.org/xpcom-and-internal-strings-in-gecko/ video], [https://dbaron.org/talks/2014-03-20-xpcom-string-taipei/speaking-notes speaking notes]</div>Dbaronhttps://wiki.mozilla.org/index.php?title=Gecko:Overview&diff=1193208Gecko:Overview2018-05-02T21:31:23Z<p>Dbaron: /* Document rendering pipeline */ another video, and reformat the existing one</p>
<hr />
<div>This document attempts to give an overview of the different parts of<br />
Gecko, what they do, and why they do it, say where the code for them is<br />
within the repository, and link to more specific documentation (when<br />
available) covering the details of that code. '''It is not yet complete.''' Maintainers of these<br />
areas of code should correct errors, add information, and add links to<br />
more detailed documentation (since this document is intended to remain<br />
an overview, not complete documentation).<br />
<br />
__TOC__<br />
<br />
== Browsers, Frames, and Document Navigation ==<br />
<br />
=== Docshell ===<br />
<br />
The user of a Web browser can change the page shown in that browser in<br />
many ways: by clicking a link, loading a new URL, using the forward and<br />
back buttons, or other ways. This can happen inside a space we'll call<br />
a '''browsing context'''; this space can be a browser window, a tab, or a frame<br />
or iframe within a document. The toplevel data structures within Gecko<br />
represent this browsing context; they contain other data structures<br />
representing the individual pages displayed inside of it (most<br />
importantly, the current one). In terms of implementation, these two<br />
types of navigation, the top level of a browser and the frames within<br />
it, largely use the same data structures.<br />
<br />
In Gecko, the '''docshell''' is the toplevel object responsible for<br />
managing a single browsing context. It, and the associated '''session history''' code, <br />
manage the navigation between pages inside of a<br />
docshell. (Note the difference between session history, which is a<br />
sequence of pages in a single browser session, used for recording information<br />
for back and forward navigation, and global history, which is the<br />
history of pages visited and associated times, regardless of browser<br />
session, used for things like link coloring and address autocompletion.)<br />
<br />
There are relatively few objects in Gecko that are associated with a<br />
docshell rather than being associated with a particular one of the pages<br />
inside of it. Most such objects are attached to the docshell. An important object associated with the docshell is the nsGlobalWindowOuter which is what the HTML5 spec refers to as a WindowProxy (into which Window objects, as implemented by nsGlobalWindowInner, are loaded). See the DOM section below for more information on<br />
this.<br />
<br />
The most toplevel object for managing the contents of a particular page<br />
being displayed within a docshell is a document viewer (see layout).<br />
Other important objects associated with this presentation are the<br />
document (see DOM) and the pres(entation) shell and pres(entation)<br />
context (see layout).<br />
<br />
[[File:WebNavigation.png|thumb|400px|<xul:browser>, frameloader and docshell in single process configuration]]<br />
<br />
Docshells are organized into a tree. If a docshell has a non-null parent, then it corresponds to a subframe in whatever page is currently loaded in the parent docshell, and the corresponding subframe element (for example, an iframe) is called a '''browsing context container'''. In Gecko, a browsing context container would implement <code>[https://dxr.mozilla.org/mozilla-central/rev/f9a5e9ed62103c84e4cde915f4d08f1ce71be83e/dom/base/nsIFrameLoader.idl#271 nsIFrameLoaderOwner]</code> to hold a '''frameloader''', which holds and manages the docshell. <br />
<br />
One of the most interfaces docshell implemented is <code>[https://dxr.mozilla.org/mozilla-central/source/docshell/base/nsIWebNavigation.idl nsIWebNavigation]</code>. It defines major functions of a browsing context, such as <code>loadURI</code> / <code>goBack</code> / <code>goForward</code> and <code>reload</code>. In single process configuration of desktop Firefox, <code><xul:browser></code> (which represents a tab) operates on docshell through <code>nsIWebNavigation</code>, as shown in the right figure.<br />
<br />
* code: mozilla/docshell/<br />
* bugzilla: Core::Document Navigation<br />
* documentation: [[DocShell:Home Page]]<br />
<br />
=== Session History ===<br />
<br />
In order to keep the session history of subframes after the root document is unloaded and docshells of subframes are destroyed, only the root docshell of a docshell tree manages the session history (this does not match the conceptual model in the HTML5 spec and may be subject to change).<br />
<br />
As an example to explain the structure of session history implementation in Gecko, consider there's a tab A, which loads document 1; in document 1, there are iframe B & C, which loads document 2 & 3, respectively. Later, an user navigates iframe B to document 4. The following figures show the conceptual model of the example, and the corresponding session history structure.<br />
<br />
{| <br />
| [[File:BrowsingContextExample1.png|thumb|190px|Conceptual model representation; color denotes current visible active documents]]<br />
| [[File:SHistoryExample1.png|thumb|180px|Session history structure; color denotes current transaction / entries]]<br />
|}<br />
<br />
In Gecko, a [https://dxr.mozilla.org/mozilla-central/source/docshell/shistory/nsSHistory.h session history] object holds a list of [https://dxr.mozilla.org/mozilla-central/source/docshell/shistory/nsSHTransaction.h transactions] (denoted as T1 & T2 in the figure); each transaction points to a tree of [https://dxr.mozilla.org/mozilla-central/source/docshell/shistory/nsSHEntry.h entries]; each entry records the docshell it associated to, and a URL. Now that if we navigate the tab to a different root document 5, which includes an iframe D with document 6, then it becomes:<br />
<br />
{| <br />
| [[File:BrowsingContextExample2.png|thumb|275px|Conceptual model representation]]<br />
| [[File:SHistoryExample2.png|thumb|250px|Session history structure]]<br />
|}<br />
<br />
=== Embedding ===<br />
<br />
To be written (and maybe rewritten if we get an IPC embedding API).<br />
<br />
[[File:WebNavigationE10S.png|thumb|500px|<xul:remote-browser>, frameloader and docshell in multiprocess configuration. The horizontal dash-lines represent inter-process communication]]<br />
<br />
=== Multi-process and IPC ===<br />
<br />
In a multi-process desktop Firefox, a tab is managed by <code>[https://dxr.mozilla.org/mozilla-central/source/toolkit/content/widgets/remote-browser.xml <xul:remote-browser>]</code>. It still operates on nsIWebNavigation, but in this case the docshell is in a remote process and can not be accessed directly. The encapsulation of remote nsIWebNavigation is done by the javascript-implemented <code>[https://dxr.mozilla.org/mozilla-central/source/toolkit/components/remotebrowserutils/RemoteWebNavigation.js RemoteWebNavigation]</code>.<br />
<br />
In this configuration, the frameloader of a root docshell lives in parent process, so it can not access docshell directly either. Instead, it holds a <code>[https://dxr.mozilla.org/mozilla-central/source/dom/ipc/TabParent.h TabParent]</code> instance to interact with <code>[https://dxr.mozilla.org/mozilla-central/source/dom/ipc/TabChild.h TabChild]</code> in child-process. At C/C++ level, the communication across processes for a single tab is through the '''PBrowser''' IPC protocol implemented by TabParent and TabChild, while at the javascript level it's done by '''message manager''' (which is ontop of PBrowser). RemoteWebNavigation, for example, sends messages to <code>[https://dxr.mozilla.org/mozilla-central/source/toolkit/content/browser-child.js browser-child.js]</code> in content process through message manager.<br />
<br />
== Networking ==<br />
<br />
The network library Gecko uses is called Necko. Necko APIs are largely organized around three concepts: '''URI objects''', '''protocol handlers''', and '''channels'''.<br />
<br />
=== Protocol handlers ===<br />
A '''protocol handler''' is an XPCOM service associated with a particular URI scheme or network protocol. Necko includes protocol handlers for HTTP, FTP, the data: URI scheme, and various others. Extensions can implement protocol handlers of their own.<br />
<br />
A protocol handler implements the <code>[https://dxr.mozilla.org/mozilla-central/source/netwerk/base/nsIProtocolHandler.idl nsIProtocolHandler]</code> API, which serves three primary purposes:<br />
# Providing metadata about the protocol (its security characteristics, whether it requires actual network access, what the corresponding URI scheme is, what TCP port the protocol uses by default).<br />
# Creating URI objects for the protocol's scheme.<br />
# Creating channel objects for the protocol's URI objects<br />
<br />
Typically, the built-in I/O service (<code>[https://dxr.mozilla.org/mozilla-central/source/netwerk/base/nsIIOService2.idl nsIIOService]</code>) is responsible for finding the right protocol handler for URI object creation and channel creation, while a variety of consumers queries protocol metadata. Querying protocol metadata is the recommended way to handle any sort of code that needs to have different behavior for different URI schemes. In particular, unlike whitelists or blacklists, it correctly handles the addition of new protocols.<br />
<br />
A service can register itself as a protocol handler by registering for the contract ID <code>"@mozilla.org/network/protocol;1?name=SSSSS"</code> where <code>SSSS</code> is the URI scheme for the protocol (e.g. "http", "ftp", and so forth).<br />
<br />
=== URI objects ===<br />
URI objects, which implement the <code>[https://dxr.mozilla.org/mozilla-central/source/netwerk/base/nsIURI.idl nsIURI]</code> API, are a way of representing URIs and IRIs. Their main advantage over strings is that they do basic syntax checking and canonicalization on the URI string that they're provided with. They also provide various accessors to extract particular parts of the URI and provide URI equality comparisons. URIs that correspond to hierarchical schemes implement the additional <code>[https://dxr.mozilla.org/mozilla-central/source/netwerk/base/nsIURL.idl nsIURL]</code> interface, which exposes even more accessors for breaking out parts of the URI.<br />
<br />
URI objects are typically created by calling the <code>newURI</code> method on the I/O service, or in C++ by calling the <code>NS_NewURI</code> utility function. This makes sure to create the URI object using the right protocol handler, which ensures that the right kind of object is created. Direct creation of URIs via <code>createInstance</code> is reserved for protocol handler implementations.<br />
<br />
=== Channels ===<br />
[https://dxr.mozilla.org/mozilla-central/source/netwerk/base/nsIChannel.idl Channels] are the Necko representation of a single request/response interaction with a server. A channel is created by calling the <code>newChannel</code> method on the [https://dxr.mozilla.org/mozilla-central/source/netwerk/base/nsIIOService.idl I/O service], or in C++ by calling the <code>[https://dxr.mozilla.org/mozilla-central/search?q=function%3ANS_NewChannel&case=true NS_NewChannel]</code> utility function. The channel can then be configured as needed, and finally its <code>asyncOpen</code> method can be called. This method takes an <code>[https://dxr.mozilla.org/mozilla-central/source/netwerk/base/nsIStreamListener.idl nsIStreamListener]</code> as an argument.<br />
<br />
If <code>asyncOpen</code> has returned successfully, the channel guarantees that it will asynchronously call the <code>onStartRequest</code> and <code>onStopRequest</code> methods on its stream listener. This will happen even if there are network errors that prevent Necko from actually performing the requests. Such errors will be reported in the channel's status and in the <code>status</code> argument to <code>onStopRequest</code>.<br />
<br />
If the channel ends up being able to provide data, it will make one or more <code>onDataAvailable</code> on its listener after calling <code>onStartRequest</code> and before calling <code>onStopRequest</code>. For each call, the listener is responsible for either returning an error or reading the entire data stream passed in to the call.<br />
<br />
If an error is returned from either <code>onStartRequest</code> or <code>onDataAvailable</code>, the channel must act as if it has been canceled with the corresponding error code.<br />
<br />
A channel has two URI objects associated with it. The <code>originalURI</code> of the channel is the URI that was originally passed to <code>newChannel</code> to create the channel that then had <code>asyncOpen</code> called on it. The <code>URI</code> is the URI from which the channel is reading data. These can be different in various cases involving protocol handlers that forward network access to other protocol handlers, as well as in situations in which a redirect occurs (e.g. following an HTTP 3xx response). In redirect situations, a new channel object will be created, but the originalURI will be propagated from the old channel to the new channel.<br />
<br />
Note that the <code>nsIRequest</code> that's passed to onStartRequest must match the one passed to onDataAvailable and onStopRequest, but need not be the original channel that asyncOpen was called on. In particular, when an HTTP redirect happens the request argument to the callbacks will be the post-redirect channel.<br />
<br />
TODO: crypto?<br />
<br />
== Document rendering pipeline ==<br />
<br />
Some of the major components of Gecko can be described as steps on the<br />
path from an HTML document coming in from the network to the graphics<br />
commands needed to render that document. An HTML document is a<br />
serialization of a tree structure. (FIXME: add diagram) The HTML<br />
parser and content sink create an in-memory representation of this tree,<br />
which we call the '''DOM tree''' or '''content tree'''.<br />
Many JavaScript APIs operate on the content tree. Then, in<br />
layout, we create a second tree, the '''frame tree''' (or<br />
'''rendering tree''') that is a similar shape to the content tree,<br />
but where each node in the tree represents a rectangle (except in SVG<br />
where they represent other shapes). We then compute the positions of<br />
the nodes in the frame tree (called '''frames''') and paint them<br />
using our cross-platform graphics APIs (which, underneath, map to<br />
platform-specific graphics APIs).<br />
<br />
Further documentation:<br />
* Talk: Fast CSS: How Browsers Lay Out Web Pages (David Baron, 2012-03-11): [https://dbaron.org/talks/2012-03-11-sxsw/slide-1.xhtml slideshow], [https://dbaron.org/talks/2012-03-11-sxsw/master.xhtml all slides], [http://audio.sxsw.com/2012/podcasts/11-ACC-Fast_CSS_How_Browser_Layout.mp3 audio (MP3)], [https://schedule.sxsw.com/2012/events/event_IAP12909 session page]<br />
* Talk: [https://air.mozilla.org/benoit-girard-gecko-rendering/ Overview of the Gecko Rendering Pipeline] (Benoit Girard, 2014-10-14)<br />
<br />
=== Parser ===<br />
<br />
The parser's job is to transform a character stream into a tree<br />
structure, with the help of the content sink classes.<br />
<br />
HTML is parsed using a parser implementing the parsing algorithm in the<br />
HTML specification (starting with HTML5). Much of this parser is<br />
translated from Java, and changes are made to the Java version. This<br />
parser in parser/html/. The parser is driven by the output of the networking layer (see nsHtml5StreamParser::OnDataAvailable). The HTML5 parser is capable of parsing off the main thread which is the normal case. It also parses on the main thread to be able to synchronously handle things such as innerHTML modifications.<br />
<br />
The codebase still has the previous generation HTML parser, which is<br />
still used for a small number of things, though we hope to be able to<br />
remove it entirely soon. This parser is in parser/htmlparser/.<br />
<br />
XML is parsed using the expat library (parser/expat/) and code that<br />
wraps it (parser/xml/). This is a non-validating parser; however, it<br />
loads certain DTDs to support XUL localization.<br />
<br />
=== DOM / Content ===<br />
<br />
The content tree or DOM tree is the central data structure for Web<br />
pages. It is a tree structure, initially created from the tree<br />
structure expressed in the HTML or XML markup. The nodes in the tree<br />
implement major parts of the DOM (Document Object Model) specifications.<br />
The nodes themselves are part of a class hierarchy rooted at<br />
<code>nsINode</code>; different derived classes are used for things such<br />
as text nodes, the document itself, HTML elements, SVG elements, etc.,<br />
with further subclasses of many of these types (e.g., for specific HTML<br />
elements). Many of the APIs available to script running in Web pages<br />
are associated with these nodes. The tree structure persists while the<br />
Web pages is displayed, since it stores much of state associated with<br />
the Web page. The code for these nodes lives in the content/ directory.<br />
<br />
The DOM APIs are not threadsafe. DOM nodes can be accessed only from<br />
the main thread (also known as the UI thread (user interface thread)) of<br />
the application.<br />
<br />
There are also many other APIs available to Web pages that are not APIs<br />
on the nodes in the DOM tree. Many of these other APIs also live in the<br />
same directories, though some live in content/ and some in dom/. These<br />
include APIs such as the DOM event model.<br />
<br />
The dom/ directory also includes some of the code needed to expose Web<br />
APIs to JavaScript (in other words, the glue code between JavaScript and<br />
these APIs). For an overview, see [https://ask.mozilla.org/question/390/how-is-the-web-exposed-dom-implemented/ DOM API Implementation]. See [[#Scripting|Scripting]] below for details of the JS engine.<br />
<br />
TODO: Internal APIs vs. DOM APIs.<br />
<br />
TODO: Mutation observers / document observers.<br />
<br />
TODO: Reference counting and cycle collection.<br />
<br />
TODO: specification links<br />
<br />
=== Style System ===<br />
<br />
==== Quantum CSS (Stylo) ====<br />
<br />
Starting with Firefox 57 and later, Gecko makes use of the parallel style system written in Rust that comes from Servo. There's an [https://hacks.mozilla.org/2017/08/inside-a-super-fast-css-engine-quantum-css-aka-stylo/ overview] of this with graphics to help explain what's going on. The [https://github.com/servo/servo/wiki/Layout-Overview Servo wiki] has some more details.<br />
<br />
==== Gecko ====<br />
<br />
The rest of the style section section describes the Gecko style system used in Firefox 56 and earlier. Some bits may still apply, but it likely needs revising.<br />
<br />
In order to display the content, Gecko needs to compute the styles<br />
relevant to each DOM node. It does this based on the model described in<br />
the CSS specifications: this model applies to style specified in CSS<br />
(e.g. by a 'style' element, an 'xml-stylesheet' processing instruction<br />
or a 'style' attribute),<br />
style specified by presentation attributes, and the default style<br />
specified by our own user agent style sheets. There are two major<br />
sets of data structures within the style system:<br />
* first, data structures that represent sources of style data, such as CSS style sheets or data from stylistic HTML attributes<br />
* second, data structures that represent computed style for a given DOM node.<br />
These sets of data structures are mostly distinct (for example, they<br />
store values in different ways).<br />
<br />
The loading of CSS style sheets from the network is managed by the <br />
[https://dxr.mozilla.org/mozilla-central/source/layout/style/Loader.h CSS loader]; <br />
they are then tokenized by the <br />
[https://dxr.mozilla.org/mozilla-central/source/layout/style/nsCSSScanner.h CSS scanner] <br />
and parsed by the <br />
[https://dxr.mozilla.org/mozilla-central/source/layout/style/nsCSSParser.h CSS parser]. <br />
Those that are attached to the document also expose APIs to<br />
script that are known as the CSS Object Model, or CSSOM.<br />
<br />
The style sheets that apply to a document are managed by a class called<br />
the [https://dxr.mozilla.org/mozilla-central/source/layout/style/nsStyleSet.h style set].<br />
The style set interacts with the different types of<br />
style sheets (representing CSS style sheets, presentational<br />
attributes, and 'style' attributes) through two interfaces:<br />
[http://dxr.mozilla.org/mozilla-central/source/layout/style/nsIStyleSheet.h nsIStyleSheet] for basic management of style sheets and<br />
[http://dxr.mozilla.org/mozilla-central/source/layout/style/nsIStyleRuleProcessor.h nsIStyleRuleProcessor] for getting the style data out of them. Usually<br />
the same object implements both interfaces, except in the most important<br />
case, CSS style sheets, where there is a single rule processor for all<br />
of the CSS style sheets in each origin (user/UA/author) of the CSS cascade.<br />
<br />
The computed style data for an element/frame are exposed to the rest of<br />
Gecko through the class mozilla::ComputedStyle (previously called<br />
nsStyleContext). Rather than having a member variable for each<br />
CSS property, it breaks up the properties into groups of related<br />
properties called style structs. These style structs obey the rule that<br />
all of the properties in a single struct either inherit by default (what<br />
the CSS specifications call "Inherited: yes" in the definition of<br />
properties; we call these inherited structs) or all are not inherited by<br />
default (we call these reset structs). Separating the properties in<br />
this way improves the ability to share the structs between similar<br />
ComputedStyle objects and reduce the amount of memory needed to store<br />
the style data. The ComputedStyle API exposes a method for getting each<br />
struct, so you'll see code like<br />
<code>sc->GetStyleText()->mTextAlign</code> for getting the value of the<br />
text-align CSS property. (Frames (see the Layout section below) also<br />
have the same<br />
GetStyle* methods, which just forward the call to the frame's<br />
ComputedStyle.)<br />
<br />
The ComputedStyles form a tree structure, in a shape somewhat like the<br />
content tree (except that we coalesce identical sibling ComputedStyles<br />
rather than keeping two of them around; if the parents have been<br />
coalesced then this can apply recursively and coalasce cousins, etc.;<br />
we do not coalesce parent/child ComputedStyles).<br />
The parent of a ComputedStyle has the style data that the ComputedStyle<br />
inherits from when CSS inheritance occurs. This means that the parent<br />
of the ComputedStyle for a DOM element is generally the ComputedStyle<br />
for that DOM element's parent, since that's how CSS says inheritance<br />
works.<br />
<br />
The process of turning the style sheets into computed style data goes<br />
through three main steps, the first two of which closely relate to the<br />
[http://dxr.mozilla.org/mozilla-central/source/layout/style/nsIStyleRule.h nsIStyleRule] interface, which represents an immutable source of style<br />
data, conceptually representing (and for CSS style rules, directly<br />
storing) a set of property:value pairs. (It is similar to the idea of a<br />
CSS style rule, except that it is immutable; this immutability allows<br />
for significant optimization. When a CSS style rule is changed through<br />
script, we create a new style rule.)<br />
<br />
The first step of going from style sheets to computed style data is<br />
finding the ordered sequence of style rules that apply to an element.<br />
The order represents which rules override which other rules: if two<br />
rules have a value for the same property, the higher ranking one wins.<br />
(Note that there's another difference from CSS style rules: declarations<br />
with !important are represented using a separate style rule.) This is<br />
done by calling one of the nsIStyleRuleProcessor::RulesMatching methods.<br />
The ordered sequence is stored in a<br />
[http://en.wikipedia.org/wiki/Trie trie] called the rule tree: the path<br />
from the root of the rule tree to any (leaf or non-leaf) node in the<br />
rule tree represents a sequence of rules, with the highest ranking<br />
farthest from the root. Each rule node (except for the root) has a<br />
pointer to a rule, but since a rule may appear in many sequences, there<br />
are sometimes many rule nodes pointing to the same rule. Once we have<br />
this list we create a ComputedStyle (or find an appropriate existing<br />
sibling) with the correct parent pointer (for inheritance) and rule node<br />
pointer (for the list of rules), and a few other pieces of information<br />
(like the pseudo-element).<br />
<br />
The second step of going from style sheets to computed style data is<br />
getting the winning property:value pairs from the rules. (This only<br />
provides property:value pairs for some of the properties; the remaining<br />
properties will fall back to inheritance or to their initial values<br />
depending on whether the property is inherited by default.) We do this<br />
step (and the third) for each style struct, the first time it is needed.<br />
This is done in nsRuleNode::WalkRuleTree, where we ask each style rule<br />
to fill in its property:value pairs by calling its MapRuleInfoInto<br />
function. When called, the rule fills in only those pairs that haven't<br />
been filled in already, since we're calling from the highest priority<br />
rule to the lowest (since in many cases this allows us to stop before<br />
going through the whole list, or to do partial computation that just<br />
adds to data cached higher in the rule tree).<br />
<br />
The third step of going from style sheets to computed style data (which<br />
various caching optimizations allow us to skip in many cases) is<br />
actually doing the computation; this generally means we transform the<br />
style data into the data type described in the "Computed Value" line in<br />
the property's definition in the CSS specifications. This<br />
transformation happens in functions called nsRuleNode::Compute*Data,<br />
where the * in the middle represents the name of the style struct. This<br />
is where the transformation from the style sheet value storage format to<br />
the computed value storage format happens.<br />
<br />
Once we have the computed style data, we then store it: if a style struct<br />
in the computed style data doesn't<br />
depend on inherited values or on data from other style structs, then we<br />
can cache it in the rule tree (and then reuse it, without recomputing<br />
it, for any ComputedStyles pointing to that rule node). Otherwise, we<br />
store it on the ComputedStyle (in which case it may be shared<br />
with the ComputedStyle's descendant ComputedStyles).<br />
This is where keeping inherited and<br />
non-inherited properties separate is useful: in the common case of<br />
relatively few properties being specified, we can generally cache the<br />
non-inherited structs in the rule tree, and we can generally share the<br />
inherited structs up and down the ComputedStyle tree.<br />
<br />
The ownership models in style sheet structures are a mix of reference<br />
counted structures (for things accessible from script) and directly<br />
owned structures. ComputedStyles are reference counted, and own their<br />
parents (from which they inherit), and rule nodes are garbage collected<br />
with a simple mark and sweep collector (which often never needs to run).<br />
<br />
* code: [http://dxr.mozilla.org/mozilla-central/source/layout/style/ layout/style/], where most files have useful one line descriptions at the top that show up in DXR<br />
* Bugzilla: Style System (CSS)<br />
* specifications<br />
** [http://www.w3.org/TR/CSS21/ CSS 2.1]<br />
** [http://www.w3.org/TR/css-2010/ CSS 2010, listing stable css3 modules]<br />
** [http://dev.w3.org/csswg/ CSS WG editors drafts] (often more current, but sometimes more unstable than the drafts on the technical reports page)<br />
** [http://dbaron.org/mozilla/visited-privacy Preventing attacks on a user's history through CSS :visited selectors]<br />
* documentation<br />
** [http://www-archive.mozilla.org/newlayout/doc/style-system.html style system documentation] (somewhat out of date)<br />
<br />
=== Layout ===<br />
<br />
Much of the layout code deals with operations on the frame tree (or<br />
rendering tree). In the frame tree, each node represents a rectangle<br />
(or, for SVG, other shapes). The frame tree has a shape similar to the<br />
content tree, since many content nodes have one corresponding frame,<br />
though it differs in a few ways, since some content nodes have more than<br />
one frame or don't have any frames at all. When elements are<br />
display:none in CSS or undisplayed for certain other reasons, they won't<br />
have any frames. When elements are broken across lines or pages, they<br />
have multiple frames; elements may also have multiple frames when<br />
multiple frames nested inside each other are needed to display a single<br />
element (for example, a table, a table cell, or many types of form<br />
controls).<br />
<br />
Each node in the frame tree is an instance of a class derived from<br />
<code>nsIFrame</code>. As with the content tree, there is a substantial<br />
type hierarchy, but the type hierarchy is very different: it includes<br />
types like text frames, blocks and inlines, the various parts of tables,<br />
and the various types of HTML form controls.<br />
<br />
Frames are allocated within an arena owned by the pres shell. Each<br />
frame is owned by its parent; frames are not reference counted, and code<br />
must not hold on to pointers to frames. To mitigate potential security<br />
bugs when pointers to destroyed frames, we use<br />
[http://robert.ocallahan.org/2010/10/mitigating-dangling-pointer-bugs-using_15.html frame poisoning], which takes two parts. When a frame is destroyed<br />
other than at the end of life of the presentation, we fill its memory<br />
with a pattern consisting of a repeated pointer to inaccessible memory,<br />
and then put the memory on a per-frame-class freelist. This means that<br />
if code accesses the memory through a dangling pointer, it will either<br />
crash quickly by dereferencing the poison pattern or it will find a<br />
valid frame.<br />
<br />
Like the content tree, frames must be accessed only from the UI thread.<br />
<br />
The frame tree should not store any important data. While it does<br />
usually persist while a page is being displayed, frames are often<br />
destroyed and recreated in response to certain style changes, and in the<br />
future we may do the same to reduce memory use for pages that are<br />
currently inactive. There were a number of cases where this rule was<br />
violated in the past and we stored important data in the frame tree;<br />
however, most (though not quite all) such cases are now fixed.<br />
<br />
The rectangle represented by the frame is what CSS calls the element's<br />
border box. This is the outside edge of the border (or the inside edge<br />
of the margin). The margin lives outside the border; and the padding<br />
lives inside the border. In addition to nsIFrame::GetRect, we also have<br />
the APIs nsIFrame::GetPaddingRect to get the padding box (the outside<br />
edge of the padding, or inside edge of the border) and<br />
nsIFrame::GetContentRect to get the content box (the outside edge of the<br />
content, or inside edge of the padding). These APIs may produce out of<br />
date results when reflow is needed (or has not yet occurred).<br />
<br />
In addition to tracking a rectangle, frames also track two overflow<br />
areas: visual overflow and scrollable overflow. These overflow areas<br />
represent the union of the area needed by the frame and by all its<br />
descendants. The visual overflow is used for painting-related<br />
optimizations: it is a rectangle covering all of the area that might be<br />
painted when the frame and all of its descendants paint. The scrollable<br />
overflow represents the area that the user should be able to scroll to<br />
to see the frame and all of its descendants. In some cases differences<br />
between the frame's rect and its overflow happen because of descendants<br />
that stick out of the frame; in other cases they occur because of some<br />
characteristic of the frame itself. The two overflow areas are<br />
similar, but there are differences: for example, margins are part of<br />
scrollable overflow but not visual overflow, whereas text-shadows are<br />
part of visual overflow but not scrollable overflow.<br />
<br />
When frames are broken across lines, columns, or pages, we create<br />
multiple frames representing the multiple rectangles of the element.<br />
The first one is the primary frame, and the rest are its continuations<br />
(which are more likely to be destroyed and recreated during reflow).<br />
These frames are linked together as continuations: they have a<br />
doubly-linked list that can be used to traverse the continuations using<br />
nsIFrame::GetPrevContinuation and nsIFrame::GetNextContinuation.<br />
(Currently continuations always have the same style data, though we may<br />
at some point want to break that invariant.)<br />
<br />
Continuations are sometimes siblings of each other, and sometimes not.<br />
For example, if a paragraph contains a span which contains a link, and<br />
the link is split across lines, then the continuations of the span are<br />
siblings (since they are both children of the paragraph), but the<br />
continuations of the link are not siblings (since each continuation of<br />
the link is descended from a different continuation of the span).<br />
Traversing the entire frame tree does '''not''' require considering<br />
continuations, since all of the continuations are descendants of the<br />
element containing the break.<br />
<br />
We also use continuations for cases (most importantly, bidi reordering,<br />
where left-to-right text and right-to-left text need to be separated<br />
into different continuations since they may not form a contiguous<br />
rectangle) where the continuations should not be rewrapped during<br />
reflow: we call these continuations fixed rather than fluid.<br />
nsIFrame::GetNextInFlow and nsIFrame::GetPrevInFlow traverse only the<br />
fluid continuations and do not cross fixed continuation boundaries.<br />
<br />
If an inline frame has non-inline children, then we split the original <br />
inline frame into parts. The original inline's children are <br />
distributed into these parts like so- The children of the original <br />
inline are grouped into runs of inline and non-inline and runs of <br />
inline get an inline parent while runs of non-inline get an anonymous <br />
block parent. This is 'ib-splitting' or block-inside-inline-splitting. <br />
This splitting proceeds recursively up the frame tree until all <br />
non-inlines inside inlines are ancestors of a block frame with anonymous <br />
block wrappers in between. This splitting maintains the relative order<br />
between these child frames and the relationship between the parts of a <br />
split inline is maintained using an ib-sibling chain. It is important <br />
to note that any wrappers created during frame construction (such as <br />
for tables) may not be included in the ib-sibling chain depending on <br />
when this wrapper creation takes place. <br />
<br />
TODO: nsBox craziness from https://bugzilla.mozilla.org/show_bug.cgi?id=524925#c64<br />
<br />
TODO: link to documentation of block and inline layout<br />
<br />
TODO: link to documentation of scrollframes<br />
<br />
TODO: link to documentation of XUL frame classes<br />
<br />
Code (note that most files in base and generic have useful one line descriptions at the top that show up in DXR):<br />
* [http://dxr.mozilla.org/mozilla-central/source/layout/base/ layout/base/] contains objects that coordinate everything and a bunch of other miscellaneous things<br />
* [http://dxr.mozilla.org/mozilla-central/source/layout/generic/ layout/generic/] contains the basic frame classes as well as support code for their reflow methods (ReflowInput, ReflowOutput)<br />
* [http://dxr.mozilla.org/mozilla-central/source/layout/forms/ layout/forms/] contains frame classes for HTML form controls<br />
* [http://dxr.mozilla.org/mozilla-central/source/layout/tables/ layout/tables/] contains frame classes for CSS/HTML tables<br />
* [http://dxr.mozilla.org/mozilla-central/source/layout/mathml/ layout/mathml/] contains frame classes for MathML<br />
* [http://dxr.mozilla.org/mozilla-central/source/layout/svg/ layout/svg/] contains frame classes for SVG<br />
* [http://dxr.mozilla.org/mozilla-central/source/layout/xul/ layout/xul/] contains frame classes for the XUL box model and for various XUL widgets<br />
<br />
Bugzilla:<br />
* All of the components whose names begin with "Layout" in the "Core" product<br />
<br />
Further documentation:<br />
* Talk: [https://air.mozilla.org/introduction-to-graphics-layout-architecture/ Introduction to graphics/layout architecture] (Robert O'Callahan, 2014-04-18)<br />
* Talk: [https://air.mozilla.org/bz-layout-and-styles/ Layout and Styles] (Boris Zbarsky, 2014-10-14)<br />
<br />
<br />
==== Frame Construction ====<br />
<br />
Frame construction is the process of creating frames. This is done when styles change in ways that require frames to be created or recreated or when nodes are inserted into the document. The content tree and the frame tree don't have quite the same shape, and the frame construction process does some of the work of creating the right shape for the frame tree. It handles the aspects of creating the right shape that don't depend on layout information. So for example, frame construction handles the work needed to implement [http://www.w3.org/TR/CSS21/tables.html#anonymous-boxes table anonymous objects] but does not handle frames that need to be created when an element is broken across lines or pages.<br />
<br />
The basic unit of frame construction is a run of contiguous children of a single parent element. When asked to construct frames for such a run of children, the frame constructor first determines, based on the siblings and parent of the nodes involved, where in the frame tree the new frames should be inserted. Then the frame constructor walks through the list of content nodes involved and for each one creates a temporary data structure called a '''frame construction item'''. The frame construction item encapsulates various information needed to create the frames for the content node: its style data, some metadata about how one would create a frame for this node based on its namespace, tag name, and styles, and some data about what sort of frame will be created. This list of frame construction items is then analyzed to see whether constructing frames based on it and inserting them at the chosen insertion point will produce a valid frame tree. If it will not, the frame constructor either fixes up the list of frame construction items so that the resulting frame tree would be valid or throws away the list of frame construction items and requests the destruction and re-creation of the frame for the parent element so that it has a chance to create a list of frame construction items that it <em>can</em> fix up.<br />
<br />
Once the frame constructor has a list of frame construction items and an insertion point that would lead to a valid frame tree, it goes ahead and creates frames based on those items. Creation of a non-leaf frame recursively attempts to create frames for the children of that frame's element, so in effect frames are created in a depth-first traversal of the content tree.<br />
<br />
The vast majority of the code in the frame constructor, therefore, falls into one of these categories:<br />
* Code to determine the correct insertion point in the frame tree for new frames.<br />
* Code to create, for a given content node, frame construction items. This involves some searches through static data tables for metadata about the frame to be created.<br />
* Code to analyze the list of frame construction items.<br />
* Code to fix up the list of frame construction items.<br />
* Code to create frames from frame construction items.<br />
<br />
Code: [http://dxr.mozilla.org/mozilla-central/source/layout/base/nsCSSFrameConstructor.h layout/base/nsCSSFrameConstructor.h] and [http://dxr.mozilla.org/mozilla-central/source/layout/base/nsCSSFrameConstructor.cpp layout/base/nsCSSFrameConstructor.cpp]<br />
<br />
==== Reflow ====<br />
<br />
Reflow is the process of computing the positions and sizes of frames. (After all,<br />
frames represent rectangles, and at some point we need to figure out<br />
exactly *what* rectangle.) Reflow is done recursively, with each<br />
frame's Reflow method calling the Reflow methods on that frame's<br />
descendants.<br />
<br />
In many cases, the correct results are defined by CSS specifications<br />
(particularly [http://www.w3.org/TR/CSS21/visudet.html CSS 2.1]). In some cases, the details are not defined by<br />
CSS, though in some (but not all) of those cases we are constrained by<br />
Web compatibility. When the details are defined by CSS, however, the<br />
code to compute the layout is generally structured somewhat differently<br />
from the way it is described in the CSS specifications, since the CSS<br />
specifications are generally written in terms of constraints, whereas<br />
our layout code consists of algorithms optimized for incremental<br />
recomputation.<br />
<br />
The reflow generally starts from the root of the frame tree, though some other<br />
types of frame can act as reflow roots and start a reflow from them.<br />
Reflow roots must obey the invariant that a change inside one of their<br />
descendants never changes their rect or overflow areas (though currently<br />
scrollbars are reflow roots but don't quite obey this invariant).<br />
<br />
In many cases, we want to reflow a part of the frame tree, and we want<br />
this reflow to be efficient. For example, when content is added or<br />
removed from the document tree or when styles change, we want the amount<br />
of work we need to redo to be proportional to the amount of content. We<br />
also want to efficiently handle a series of changes to the same content.<br />
<br />
To do this, we maintain two bits on frames:<br />
[http://dxr.mozilla.org/mozilla-central/search?q=var%3ANS_FRAME_IS_DIRTY&case=true&redirect=true NS_FRAME_IS_DIRTY]<br />
indicates that a frame and all of its descendants require reflow.<br />
[http://dxr.mozilla.org/mozilla-central/search?q=var%3ANS_FRAME_HAS_DIRTY_CHILDREN&case=true&redirect=true NS_FRAME_HAS_DIRTY_CHILDREN]<br />
indicates that a frame has a descendant that<br />
is dirty or has had a descendant removed (i.e., that it has a child that<br />
has NS_FRAME_IS_DIRTY or NS_FRAME_HAS_DIRTY_CHILDREN or it had a child<br />
removed). These bits allow coalescing of multiple updates; this<br />
coalescing is done in nsPresShell, which tracks the set of reflow roots<br />
that require reflow. The bits are set during calls to<br />
nsPresShell::FrameNeedsReflow and are cleared during reflow.<br />
<br />
The layout algorithms used by many of the frame classes are those<br />
specified in CSS, which are based on the traditional document formatting<br />
model, where widths are input and heights are output.<br />
<br />
In some cases, however, widths need to be determined based on the<br />
content. This depends on two ''intrinsic widths'': the minimum<br />
intrinsic width (see [http://dxr.mozilla.org/search?q=type%3AnsIFrame%20function%3AGetMinWidth&tree=mozilla-central nsIFrame::GetMinWidth]) and the preferred intrinsic<br />
width (see [http://dxr.mozilla.org/search?q=type%3AnsIFrame%20function%3AGetPrefWidth&tree=mozilla-central nsIFrame::GetPrefWidth]). The concept of what these widths<br />
represent is best explained by describing what they are on a paragraph<br />
containing only text: in such a paragraph the minimum intrinsic width<br />
is the width of the longest word, and the preferred intrinsic width is<br />
the width of the entire paragraph laid out on one line.<br />
<br />
Intrinsic widths are invalidated separately from the dirty bits<br />
described above. When a caller informs the pres shell that a frame<br />
needs reflow (nsIPresShell::FrameNeedsReflow), it passes one of three<br />
options:<br />
* eResize indicates that no intrinsic widths are dirty<br />
* eTreeChange indicates that intrinsic widths on it and its ancestors are dirty (which happens, for example, if new children are added to it)<br />
* eStyleChange indicates that intrinsic widths on it, its ancestors, and its descendants are dirty (for example, if the font-size changes)<br />
<br />
Reflow is the area where the XUL frame classes (those that inherit from<br />
nsBoxFrame or nsLeafBoxFrame) are most different from the rest. Instead<br />
of using nsIFrame::Reflow, they do their layout computations using<br />
intrinsic size methods called GetMinSize, GetPrefSize, and GetMaxSize<br />
(which report intrinsic sizes in two dimensions) and a final layout<br />
method called Layout. In many cases these methods defer some of the<br />
computation to a separate object called a layout manager.<br />
<br />
When an individual frame's Reflow method is called, most of the input is<br />
provided on an object called ReflowInput and the output is filled<br />
in to an object called ReflowOutput. After reflow, the caller<br />
(usually the parent) is responsible for setting the frame's size based<br />
on the metrics reported. (This can make some computations during reflow<br />
difficult, since the new size is found in either the reflow state or the<br />
metrics, but the frame's size is still the old size. However, it's<br />
useful for invalidating the correct areas that need to be repainted.)<br />
<br />
One major difference worth noting is that in XUL layout, the size of the<br />
child is set prior to its parent calling its Layout method. (Once<br />
invalidation uses display lists and is no longer tangled up in Reflow,<br />
it may be worth switching non-XUL layout to work this way as well.)<br />
<br />
==== Painting ====<br />
<br />
TODO: display lists (and event handling)<br />
<br />
TODO: layers<br />
<br />
==== Pagination ====<br />
<br />
The concepts behind pagination (also known as fragmentation) are a bit complicated, so for now we've split them off into a separate document: [[Gecko:Continuation_Model]]. This code is used for printing, print-preview, and multicolumn frames.<br />
<br />
=== Dynamic change handling along the rendering pipeline ===<br />
<br />
The ability to make changes to the DOM from script is a major feature of the Web platform. Web authors rely on the concept (though there are a few exceptions, such as animations) that changing the DOM from script leads to the same rendering that would have resulted from starting from that DOM tree. They also rely on the performance characteristics of these changes: small changes to the DOM that have small effects should have proportionally small processing time. This means that Gecko needs to efficiently propagate changes from the content tree to style, the frame tree, the geometry of the frame tree, and the screen.<br />
<br />
For many types of changes, however, there is substantial overhead to processing a change, no matter how small. For example, reflow must propagate from the top of the frame tree down to the frames that are dirty, no matter how small the change. One very common way around this is to batch up changes. We batch up changes in lots of ways, for example:<br />
* The content sink adds multiple nodes to the DOM tree before notifying listeners that they've been added. This allows notifying once about an ancestor rather than for each of its descendants, or notifying about a group of descendants all at once, which speeds up the processing of those notifications.<br />
* We batch up nodes that require style reresolution (recomputation of selector matching and processing the resulting style changes). This batching is tree based, so it not only merges multiple notifications on the same element, but also merges a notification on an ancestor with a notification on its descendant (since ''some'' of these notifications imply that style reresolution is required on all descendants).<br />
* We wait to reconstruct frames that require reconstruction (after destroying frames eagerly). This, like the tree-based style reresolution batching, avoids duplication both for same-element notifications and ancestor-descendant notifications, even though it doesn't actually do any tree-based caching.<br />
* We postpone doing reflows until needed. As for style reresolution, this maintains tree-based dirty bits (see the description of NS_FRAME_IS_DIRTY and NS_FRAME_HAS_DIRTY_CHILDREN under Reflow).<br />
* We allow the OS to queue up multiple invalidates before repainting (though we will likely switch to controlling that ourselves). This leads to a single repaint of some set of pixels where there might otherwise have been multiple (though it may also lead to more pixels being repainted if multiple rectangles are merged to a single one).<br />
<br />
Having changes buffered up means, however, that various pieces of information (layout, style, etc.) may not be up-to-date. Some things require up-to-date information: for example, we don't want to expose the details of our buffering to Web page script since the programming model of Web page script assumes that DOM changes take effect "immediately", i.e., that the script shouldn't be able to detect any buffering. Many Web pages depend on this.<br />
<br />
We therefore have ways to flush these different sorts of buffers. There are methods called FlushPendingNotifications on nsIDocument and nsIPresShell, that take an argument of what things to flush:<br />
* Flush_Content: create all the content nodes from data buffered in the parser<br />
* Flush_ContentAndNotify: the above, plus notify document observers about the creation of all nodes created so far<br />
* Flush_Style: the above, plus make sure style data are up-to-date<br />
* Flush_Frames: the above, plus make sure all frame construction has happened (currently the same as Flush_Style)<br />
* Flush_InterruptibleLayout: the above, plus perform layout (Reflow), but allow interrupting layout if it takes too long<br />
* Flush_Layout: the above, plus ensure layout (Reflow) runs to completion<br />
* Flush_Display (should never be used): the above, plus ensure repainting happens<br />
<br />
The major way that notifications of changes propagate from the content code to layout and other areas of code is through the nsIDocumentObserver and nsIMutationObserver interfaces. Classes can implement this interface to listen to notifications of changes for an entire document or for a subtree of the content tree.<br />
<br />
WRITE ME: ... layout document observer implementations<br />
<br />
TODO: how style system optimizes away rerunning selector matching<br />
<br />
TODO: style changes and nsChangeHint<br />
<br />
=== Refresh driver ===<br />
<br />
== Graphics ==<br />
[https://wiki.mozilla.org/Platform/GFX Wiki page] | [https://wiki.mozilla.org/index.php?title=Platform/GFX/Contribute contribute]<br />
<br />
Further documentation:<br />
* Talk: [https://air.mozilla.org/introduction-to-graphics-layout-architecture/ Introduction to graphics/layout architecture] (Robert O'Callahan, 2014-04-18)<br />
* Talk: [https://air.mozilla.org/bjacob-gfx-overview/ An overview of Gecko's graphics stack] (Benoit Jacob, 2014-08-12)<br />
* Talk: [https://air.mozilla.org/jeff-muizelaar-2d-graphics/ 2D Graphics] (Jeff Muizelaar, 2014-10-14)<br />
<br />
==== Painting/Rasterizing ====<br />
<br />
Painting/rendering/rasterizing is the step where graphical primitives (such as a command to fill an [https://developer.mozilla.org/en-US/docs/Web/SVG SVG] circle, or a [https://developer.mozilla.org/en-US/docs/Web/Guide/Graphics/Drawing_graphics_with_canvas canvas] command to stroke a path between x, y, z, or the internally produced command to draw the edge of an HTML div's border) are used to color in the pixels of a surface so that the surface "displays" those rasterized primitives.<br />
<br />
The platform independent library that gecko uses to render is [http://dxr.mozilla.org/mozilla-central/source/gfx/2d/2D.h Moz2D]. Gecko code paints into Moz2D DrawTarget objects (the DrawTarget baseclass having multiple platform dependent subclasses). (At least this is where gecko is going - for now there is still significant amounts of code that uses [http://dxr.mozilla.org/mozilla-central/source/gfx/thebes/gfxContext.h Thebes gfxContext] objects or the even older nsRenderingContext objects. Objects of these types now always wrap a DrawTarget so all painting does now go through Moz2D, but conversion to use the wrapped DrawTargets directly is taking time since consumer code can sometimes need to be radically rewritten to fit the Moz2D API and immediate mode paradigm.)<br />
<br />
==== Compositing ====<br />
<br />
The compositing stage of the rendering pipeline is operated by the [http://dxr.mozilla.org/mozilla-central/source/gfx/layers/ gfx/layers] module.<br />
<br />
Different parts of a web page can sometimes be painted into intermediate surfaces retained by layers. It can be convenient to think of layers as the layers in image manipulation programs like The Gimp or Photoshop. Layers are organized as a tree. Layers are primarily used to minimize invalidating and repainting when elements are being animated independently of one another in a way that can be optimized using layers (e.g. opacity or transform animations), and to enable some effects (such as transparency and 3D transforms).<br />
<br />
Compositing is the action of flattening the layers into the final image that is shown on the screen.<br />
<br />
On some platform, compositing happens on the Content thread. However, on other platforms we composite on a separate thread (Off-main-thread compositing, or OMTC). OMTC is at the moment the default behavior on mobile platforms, but the goal is to do it on all platforms in the long run.<br />
<br />
The Layers architecture is built on the following notions:<br />
* Compositor: an object that can draw quads on the screen (or on an off-screen render target).<br />
* Texture: an object that contains image data.<br />
* Compositable: an object that can manipulate one or several textures, and knows how to present them to the compositor<br />
* Layer: an element of the layer tree. A layer usually doesn't know much about compositing: it uses a compositable to do the work. Layers are mostly nodes of the layer tree.<br />
<br />
[[File:LayersRefactoring.png|thumb|650px|New layers architecture, with OGL backend]]<br />
<br />
The above abstractions are sufficient to perform compositing on the main thread, but on the OMTC case, we need a mechanism to synchronize a client layer tree that is constructed on the content thread, and a host layer tree that is used for compositing on the compositor thread.<br />
This synchronization process must ensure that the host layer tree reflects the state of the current layer tree while remaining in a consistent state, and must transfer texture data from a thread to the other. Moreover, on some platforms the content and compositor threads may live in separate processes.<br />
<br />
To perform this synchronization, we use the IPDL IPC framework. IPDL lets us describe communications protocols and actors in a domain specific language. for more information about IPDL, read https://wiki.mozilla.org/IPDL<br />
<br />
When the client layer tree is modified, we record modifications into messages that are sent together to the host side within a transaction. A transaction is basically a list of modifications to the layer tree that have to be applied all at once to preserve consistency in the state of the host layer tree.<br />
<br />
Texture transfer is done by synchronizing texture objects across processes/threads using a couple TextureClient/TextureHost that wrap shared data and provide access to it on both sides. TextureHosts provide access to one or several TextureSource, which has the necessary API to actually composite the texture (TextureClient/Host being more about IPC synchronization than actual compositing.<br />
The logic behind texture transfer (as in single/double/triple buffering, texture tiling, etc) is operated by the CompositableClient and CompositableHost.<br />
<br />
It is important to understand the separation between layers and compositables. Compositables handle all the logic around texture transfer, while layers define the shape of the layer tree. a Compositable is created independently from a layer and attached to it on both sides. While layers transactions can only originate from the content thread, this separation makes it possible for us to have separate compositable transactions between any thread and the compositor thread. We use the ImageBridge IPDL protocol to that end. The Idea of ImageBridge is to create a Compositable that is manipulated on the ImageBridgeThread, and that can transfer/synchronize textures without using the content thread at all. This is very useful for smooth Video compositing: video frames are decoded and passed into the ImageBridge without ever touching the content thread, which could be busy processing reflows or heavy javascript workloads.<br />
<br />
It is worth reading the inline code documentation in the following files:<br />
* [http://dxr.mozilla.org/mozilla-central/source/gfx/layers/Compositor.h gfx/layers/Compositor.h]<br />
* [http://dxr.mozilla.org/mozilla-central/source/gfx/layers/ShadowLayers.h gfx/layers/ShadowLayers.h]<br />
* [http://dxr.mozilla.org/mozilla-central/source/gfx/layers/Layers.h gfx/layers/Layers.h]<br />
* [http://dxr.mozilla.org/mozilla-central/source/gfx/layers/host/TextureHost.h gfx/layers/host/TextureHost.h]<br />
* [http://dxr.mozilla.org/mozilla-central/source/gfx/layers/client/CompositableClient.h gfx/layers/client/CompositableClient.h]<br />
<br />
To visualize how a web page is layered, turn on the pref "layers.draw-borders" in about:config. When this pref is on, the borders of layers and tiles are displayed on top of the content. This only works when using the new Compositor API, that is when off-main-thread compositing is activated. OMTC is activated by default on all mobile platforms, and will progressively get activated on desktop platforms (not yet, though). On platforms where OMTC is not used, this pref has no effect. <br />
<br />
Blog posts with information on Layers that should be integrated here:<br />
<br />
* [http://www.basschouten.com/blog1.php/layers-cross-platform-acceleration Layers: Cross-Platform Acceleration]<br />
* [http://robert.ocallahan.org/2010/04/layers_01.html Layers]<br />
* [http://robert.ocallahan.org/2010/07/retained-layers_16.html Retained Layers]<br />
* [http://chrislord.net/index.php/2011/07/25/shadow-layers-and-learning-by-failing/ Shadow Layers, and learning by failing]<br />
* [http://chrislord.net/index.php/2011/08/16/accelerated-layer-rendering-and-learning-by-some-success/ Accelerated layer-rendering, and learning by (some) success]<br />
* [http://featherweightmusings.blogspot.co.uk/2012/05/mask-layers_26.html Mask Layers]<br />
* [http://featherweightmusings.blogspot.co.uk/2012/05/building-mask-layer.html Building a mask layer]<br />
* [http://featherweightmusings.blogspot.co.uk/2012/06/mask-layers-on-direct3d-backends.html Mask Layers on the Direct3D backends]<br />
* [http://robert.ocallahan.org/2011/09/graphics-api-design.html Graphics API Design]<br />
<br />
==== Async Panning and Zooming ====<br />
<br />
On some of our mobile platforms we have some code that allows the user to do asynchronous (i.e. off-main-thread) panning and zooming of content. This code is the Async Pan/Zoom module (APZ) code and is further documented at [[Platform/GFX/APZ]].<br />
<br />
== Scripting ==<br />
<br />
=== JavaScript Engine ===<br />
<br />
Gecko embeds the SpiderMonkey JavaScript engine (located in js/src). The JS engine includes a number of Just-In-Time compilers (or JITs). SpiderMonkey provides a powerful and extensive embedding API (called the JSAPI). Because of its complexity, using the JSAPI directly is frowned upon, and a number of abstractions have been built in Gecko to allow interacting with the JS engine without using JSAPI directly. Some JSAPI concepts are important for Gecko developers to understand, and they are listed below:<br />
<br />
* Global object: The '''global object''' is the object on which all global variables/properties/methods live. In a web page this is the 'window' object. In other things such as XPCOM components or sandboxes XPConnect creates a global object with a small number of builtin APIs.<br />
* Compartments: A '''compartment''' is a subdivision of the JS heap. The mapping from global objects to compartments is one-to-one; that is, every global object has a compartment associated with it, and no compartment is associated with more than one global object. (NB: There are compartments associated with no global object, but they aren't very interesting). When JS code is running SpiderMonkey has a concept of a "current" compartment. New objects that are created will be created in the "current" compartment and associated with the global object of that compartment.<br />
* When objects in one compartment can see objects in another compartment (via e.g. iframe.contentWindow.foo) '''cross-compartment wrappers''' or '''CCWs''' mediate the interaction between the two compartments. By default CCWs ensure that the current compartment is kept up-to-date when execution crosses a compartment boundary. SpiderMonkey also allows embeddings to extend wrappers with custom behavior to implement security policies, which Gecko uses extensively (see the Security section for more information).<br />
<br />
=== XPConnect ===<br />
<br />
'''XPConnect''' is a bridge between C++ and JS used by XPCOM components exposed to or implemented in JavaScript. XPConnect allows two XPCOM components to talk to each other without knowing or caring which language they are implemented in. XPConnect allows JS code to call XPCOM components by exposing XPCOM interfaces as JS objects, and mapping function calls and attributes from JS into virtual method calls on the underlying C++ object. It also allows JS code to implement an XPCOM component that can be called from C++ by faking the vtable of an interface and translating calls on the interface into JS calls. XPConnect accomplishes this using the vtable data stored in XPCOM TypeLibs (or XPT files) by the XPIDL compiler and a small layer of platform specific code called [https://developer.mozilla.org/en-US/docs/xptcall_FAQ xptcall] that knows how to interact with and impersonate vtables of XPCOM interfaces.<br />
<br />
XPConnect is also used for a small (and decreasing) number of legacy DOM objects. At one time all of the DOM used XPConnect to talk to JS, but we have been replacing XPConnect with the WebIDL bindings (see the next section for more information). Arbitrary XPCOM components are not exposed to web content. XPCOM components that want to be accessible to web content must provide class info (that is, they must QI to nsIClassInfo) and must be marked with the nsIClassInfo::DOM_OBJECT flag. Most of these objects also are listed in dom/base/nsDOMClassInfo.cpp, where the interfaces that should be visible to the web are enumerated. This file also houses some "scriptable helpers" (classes ending in "SH" and implementing nsIXPCScriptable), which are a set of optional hooks that can be used by XPConnect objects to implement more exotic behaviors (such as indexed getters or setters, lazily resolved properties, etc). This is all legacy code, and any new DOM code should use the WebIDL bindings.<br />
<br />
=== WebIDL Bindings ===<br />
<br />
The '''WebIDL bindings''' are a separate bridge between C++ and JS that is specifically designed for use by DOM code. We intend to replace all uses of XPConnect to interface with content JavaScript with the WebIDL bindings. [https://developer.mozilla.org/en-US/docs/Mozilla/WebIDL_bindings Extensive documentation] on the WebIDL bindings is available, but the basic idea is that a binding generator takes WebIDL files from web standards and some configuration data provided by us and generates at build time C++ glue code that sits between the JS engine and the DOM object. This setup allows us to produce faster, more specialized code for better performance at the cost of increased codesize.<br />
<br />
The WebIDL bindings also implement all of the behavior specified in WebIDL, making it possible for new additions to the DOM to behave correctly "out of the box". The binding layer also provides C++ abstractions for types that would otherwise require direct JSAPI calls to handle, such as typed arrays. <br />
<br />
=== Security ===<br />
<br />
Gecko's JS security model is based on the concept of compartments. Every compartment has a '''principal''' associated with it that contains security information such as the '''origin''' of the compartment, whether or not it has system privileges, etc. For the following discussion, '''wrappee''' refers to the underlying object being wrapped, '''scope''' refers to the compartment the object is being wrapped for use in, and '''wrapper''' refers to the object created in '''scope''' that allows it to interact with '''wrappee'''. "Chrome" refers to JS that is built in to the browser or part of an extension, which runs with full privileges, and is contrasted with "content", which is web provided script that is subject to security restrictions and the same origin policy.<br />
<br />
* Xray wrappers: Xray wrappers are used when the scope has chrome privileges and the wrappee is the JS reflection of an underlying DOM object. Beyond the usual CCW duties of making sure that content code does not run with chrome privileges, Xray wrappers also ensure that calling methods or accessing attributes on the wrappee has the "expected" effect. For example, a web page could replace the <code>close</code> method on its window with a JS function that does something completely different. (e.g. <code>window.close = function() { alert("This isn't what you wanted!") };</code>). Overwriting methods in this way (or creating entirely new ones) is referred to as '''expando''' properties. Xrays see through expando properties, invoking the original method/getter/setter if the expando overwrites a builtin or seeing undefined in the expando creates a new property. This allows chrome code to call methods on content DOM objects without worrying about how the page has changed the object.<br />
* Waived xray wrappers: The xray behavior is not always desirable. It is possible for chrome to "waive" the xray behavior and see the actual JS object. The wrapper still guarantees that code runs with the correct privileges, but methods/getters/setters may not behave as expected. This is equivalent to the behavior chrome sees when it looks at non-DOM content JS objects.<br />
* For more information, see the [https://developer.mozilla.org/en-US/docs/Mozilla/Gecko/Script_security MDN page]<br />
* bholley's [https://air.mozilla.org/enter-the-compartment/ Enter the Compartment] talk also provides an overview of our compartment architecture.<br />
<br />
== Images ==<br />
<br />
== Plugins ==<br />
<br />
== Platform-specific layers ==<br />
<br />
* widget<br />
* native theme<br />
* files, networking, other low-level things<br />
* Accessibility APIs<br />
* Input. Touch-input stuff is somewhat described at [[Platform/Input/Touch]].<br />
<br />
== Editor ==<br />
<br />
== Base layers ==<br />
<br />
=== NSPR ===<br />
<br />
NSPR is a library for providing cross-platform APIs for various<br />
platform-specific functions. We tend to be trying to use it as little<br />
as possible, although there are a number of areas (particularly some<br />
network-related APIs and threading/locking primitives) where we use it<br />
quite a bit.<br />
<br />
=== XPCOM ===<br />
<br />
XPCOM is a cross-platform modularity library, modeled on Microsoft COM. It<br />
is an object system in which all objects inherit from the <code>nsISupports</code> interface.<br />
<br />
components and services, contract IDs and CIDs<br />
<br />
prior overuse of XPCOM; littering with XPCOM does not produce modularity<br />
<br />
Base headers (part of xpcom/base/) and data structures. See also mfbt.<br />
<br />
Threading<br />
<br />
xptcall, proxies<br />
<br />
reference counting, cycle collection<br />
<br />
Further documentation:<br />
* XPCOM and Internal Strings in Gecko (talk by David Baron, 2014-03-20): [https://air.mozilla.org/xpcom-and-internal-strings-in-gecko/ video], [https://dbaron.org/talks/2014-03-20-xpcom-string-taipei/speaking-notes speaking notes]<br />
<br />
=== String ===<br />
<br />
XPCOM has string classes for representing sequences of characters. Typical C++ string classes have the goals of encapsulating the memory management of buffers and the issues needed to avoid buffer overruns common in traditional C string handling. Mozilla's string classes have these goals, and also the goal of reducing copying of strings.<br />
<br />
(There is a second set of string classes in xpcom/glue for callers outside of libxul; these classes are partially source-compatible but have different (worse) performance characteristics. This discussion does not cover those classes.)<br />
<br />
We have two parallel sets of classes, one for strings with 1-byte units (<code>char</code>, which may be signed or unsigned), and one for strings with 2-byte units (<code>char16_t</code>, always unsigned). The classes are named such that the class for 2-byte characters ends with <code>String</code> and the corresponding class for 1-byte characters ends with <code>CString</code>. 2-byte strings are almost always used to encode [http://en.wikipedia.org/wiki/UTF-16 UTF-16]. 1-byte strings are usually used to encode either [http://en.wikipedia.org/wiki/ASCII ASCII] or [http://en.wikipedia.org/wiki/UTF-8 UTF-8], but are sometimes also used to hold data in some other encoding or just byte sequences.<br />
<br />
The string classes distinguish, as part of the type hierarchy, between strings that must have a null-terminator at the end of their buffer (<code>ns[C]String</code>) and strings that are not required to have a null-terminator (<code>ns[C]Substring</code>). <code>ns[C]Substring</code> is the base of the string classes (since it imposes fewer requirements) and <code>ns[C]String</code> is a class derived from it. Functions taking strings as parameters should generally take one of these four types.<br />
<br />
In order to avoid unnecessary copying of string data (which can have significant performance cost), the string classes support different ownership models. All string classes support the following three ownership models dynamically:<br />
* reference counted, copy-on-write, buffers (the default)<br />
* adopted buffers (a buffer that the string class owns, but is not reference counted, because it came from somewhere else)<br />
* dependent buffers, that is, an underlying buffer that the string class does not own, but that the caller that constructed the string guarantees will outlive the string instance<br />
In addition, there is a special string class, <code>nsAuto[C]String</code>, that ''additionally'' contains an internal 64-unit buffer (intended primarily for use on the stack), leading to a fourth ownership model:<br />
* storage within an auto string's stack buffer<br />
Auto strings will prefer reference counting an existing reference-counted buffer over their stack buffer, but will otherwise use their stack buffer for anything that will fit in it.<br />
<br />
There are a number of additional string classes, particularly <code>nsDependent[C]String</code>, <code>nsDependent[C]Substring</code>, and the <code>NS_LITERAL_[C]STRING</code> macros which construct an <code>nsLiteral[C]String</code> which exist primarily as constructors for the other types. These types are really just convenient notation for constructing an <code>ns[C]S[ubs]tring</code> with a non-default ownership mode; they should not be thought of as different types. (The <code>Substring</code>, <code>StringHead</code>, and <code>StringTail</code> functions are also constructors for dependent [sub]strings.) Non-default ownership modes can also be set up using the <code>Rebind</code> and <code>Adopt</code> methods, although the <code>Rebind</code> methods actually live on the derived types, which is probably a mistake (although moving them up would require some care to avoid making an API that easily allows assigning a non-null-terminated buffer to a string whose static type indicates that it is null-terminated).<br />
<br />
Note that the presence of all of these classes imposes some awkwardness in terms of distinctions being available as both static type distinctions and dynamic type distinctions. In general, the only distinctions that should be made statically are 1-byte vs. 2-byte sequences (<code>CString</code> vs <code>String</code>) and whether the buffer is null-terminated or not (<code>Substring</code> vs <code>String</code>). (Does the code actually do a good job of dynamically enforcing the <code>Substring</code> vs. <code>String</code> restriction?)<br />
<br />
TODO: buffer growth, concatenation optimizations<br />
<br />
TODO: encoding conversion, what's validated and what isn't<br />
<br />
TODO: "string API", nsAString (historical)<br />
<br />
* Code: xpcom/string/<br />
* Bugzilla: Core::String<br />
<br />
Further documentation:<br />
* XPCOM and Internal Strings in Gecko (talk by David Baron, 2014-03-20): [https://air.mozilla.org/xpcom-and-internal-strings-in-gecko/ video], [https://dbaron.org/talks/2014-03-20-xpcom-string-taipei/speaking-notes speaking notes]</div>Dbaronhttps://wiki.mozilla.org/index.php?title=Gecko:Overview&diff=1193205Gecko:Overview2018-05-02T21:27:49Z<p>Dbaron: /* Graphics */ link to videos</p>
<hr />
<div>This document attempts to give an overview of the different parts of<br />
Gecko, what they do, and why they do it, say where the code for them is<br />
within the repository, and link to more specific documentation (when<br />
available) covering the details of that code. '''It is not yet complete.''' Maintainers of these<br />
areas of code should correct errors, add information, and add links to<br />
more detailed documentation (since this document is intended to remain<br />
an overview, not complete documentation).<br />
<br />
__TOC__<br />
<br />
== Browsers, Frames, and Document Navigation ==<br />
<br />
=== Docshell ===<br />
<br />
The user of a Web browser can change the page shown in that browser in<br />
many ways: by clicking a link, loading a new URL, using the forward and<br />
back buttons, or other ways. This can happen inside a space we'll call<br />
a '''browsing context'''; this space can be a browser window, a tab, or a frame<br />
or iframe within a document. The toplevel data structures within Gecko<br />
represent this browsing context; they contain other data structures<br />
representing the individual pages displayed inside of it (most<br />
importantly, the current one). In terms of implementation, these two<br />
types of navigation, the top level of a browser and the frames within<br />
it, largely use the same data structures.<br />
<br />
In Gecko, the '''docshell''' is the toplevel object responsible for<br />
managing a single browsing context. It, and the associated '''session history''' code, <br />
manage the navigation between pages inside of a<br />
docshell. (Note the difference between session history, which is a<br />
sequence of pages in a single browser session, used for recording information<br />
for back and forward navigation, and global history, which is the<br />
history of pages visited and associated times, regardless of browser<br />
session, used for things like link coloring and address autocompletion.)<br />
<br />
There are relatively few objects in Gecko that are associated with a<br />
docshell rather than being associated with a particular one of the pages<br />
inside of it. Most such objects are attached to the docshell. An important object associated with the docshell is the nsGlobalWindowOuter which is what the HTML5 spec refers to as a WindowProxy (into which Window objects, as implemented by nsGlobalWindowInner, are loaded). See the DOM section below for more information on<br />
this.<br />
<br />
The most toplevel object for managing the contents of a particular page<br />
being displayed within a docshell is a document viewer (see layout).<br />
Other important objects associated with this presentation are the<br />
document (see DOM) and the pres(entation) shell and pres(entation)<br />
context (see layout).<br />
<br />
[[File:WebNavigation.png|thumb|400px|<xul:browser>, frameloader and docshell in single process configuration]]<br />
<br />
Docshells are organized into a tree. If a docshell has a non-null parent, then it corresponds to a subframe in whatever page is currently loaded in the parent docshell, and the corresponding subframe element (for example, an iframe) is called a '''browsing context container'''. In Gecko, a browsing context container would implement <code>[https://dxr.mozilla.org/mozilla-central/rev/f9a5e9ed62103c84e4cde915f4d08f1ce71be83e/dom/base/nsIFrameLoader.idl#271 nsIFrameLoaderOwner]</code> to hold a '''frameloader''', which holds and manages the docshell. <br />
<br />
One of the most interfaces docshell implemented is <code>[https://dxr.mozilla.org/mozilla-central/source/docshell/base/nsIWebNavigation.idl nsIWebNavigation]</code>. It defines major functions of a browsing context, such as <code>loadURI</code> / <code>goBack</code> / <code>goForward</code> and <code>reload</code>. In single process configuration of desktop Firefox, <code><xul:browser></code> (which represents a tab) operates on docshell through <code>nsIWebNavigation</code>, as shown in the right figure.<br />
<br />
* code: mozilla/docshell/<br />
* bugzilla: Core::Document Navigation<br />
* documentation: [[DocShell:Home Page]]<br />
<br />
=== Session History ===<br />
<br />
In order to keep the session history of subframes after the root document is unloaded and docshells of subframes are destroyed, only the root docshell of a docshell tree manages the session history (this does not match the conceptual model in the HTML5 spec and may be subject to change).<br />
<br />
As an example to explain the structure of session history implementation in Gecko, consider there's a tab A, which loads document 1; in document 1, there are iframe B & C, which loads document 2 & 3, respectively. Later, an user navigates iframe B to document 4. The following figures show the conceptual model of the example, and the corresponding session history structure.<br />
<br />
{| <br />
| [[File:BrowsingContextExample1.png|thumb|190px|Conceptual model representation; color denotes current visible active documents]]<br />
| [[File:SHistoryExample1.png|thumb|180px|Session history structure; color denotes current transaction / entries]]<br />
|}<br />
<br />
In Gecko, a [https://dxr.mozilla.org/mozilla-central/source/docshell/shistory/nsSHistory.h session history] object holds a list of [https://dxr.mozilla.org/mozilla-central/source/docshell/shistory/nsSHTransaction.h transactions] (denoted as T1 & T2 in the figure); each transaction points to a tree of [https://dxr.mozilla.org/mozilla-central/source/docshell/shistory/nsSHEntry.h entries]; each entry records the docshell it associated to, and a URL. Now that if we navigate the tab to a different root document 5, which includes an iframe D with document 6, then it becomes:<br />
<br />
{| <br />
| [[File:BrowsingContextExample2.png|thumb|275px|Conceptual model representation]]<br />
| [[File:SHistoryExample2.png|thumb|250px|Session history structure]]<br />
|}<br />
<br />
=== Embedding ===<br />
<br />
To be written (and maybe rewritten if we get an IPC embedding API).<br />
<br />
[[File:WebNavigationE10S.png|thumb|500px|<xul:remote-browser>, frameloader and docshell in multiprocess configuration. The horizontal dash-lines represent inter-process communication]]<br />
<br />
=== Multi-process and IPC ===<br />
<br />
In a multi-process desktop Firefox, a tab is managed by <code>[https://dxr.mozilla.org/mozilla-central/source/toolkit/content/widgets/remote-browser.xml <xul:remote-browser>]</code>. It still operates on nsIWebNavigation, but in this case the docshell is in a remote process and can not be accessed directly. The encapsulation of remote nsIWebNavigation is done by the javascript-implemented <code>[https://dxr.mozilla.org/mozilla-central/source/toolkit/components/remotebrowserutils/RemoteWebNavigation.js RemoteWebNavigation]</code>.<br />
<br />
In this configuration, the frameloader of a root docshell lives in parent process, so it can not access docshell directly either. Instead, it holds a <code>[https://dxr.mozilla.org/mozilla-central/source/dom/ipc/TabParent.h TabParent]</code> instance to interact with <code>[https://dxr.mozilla.org/mozilla-central/source/dom/ipc/TabChild.h TabChild]</code> in child-process. At C/C++ level, the communication across processes for a single tab is through the '''PBrowser''' IPC protocol implemented by TabParent and TabChild, while at the javascript level it's done by '''message manager''' (which is ontop of PBrowser). RemoteWebNavigation, for example, sends messages to <code>[https://dxr.mozilla.org/mozilla-central/source/toolkit/content/browser-child.js browser-child.js]</code> in content process through message manager.<br />
<br />
== Networking ==<br />
<br />
The network library Gecko uses is called Necko. Necko APIs are largely organized around three concepts: '''URI objects''', '''protocol handlers''', and '''channels'''.<br />
<br />
=== Protocol handlers ===<br />
A '''protocol handler''' is an XPCOM service associated with a particular URI scheme or network protocol. Necko includes protocol handlers for HTTP, FTP, the data: URI scheme, and various others. Extensions can implement protocol handlers of their own.<br />
<br />
A protocol handler implements the <code>[https://dxr.mozilla.org/mozilla-central/source/netwerk/base/nsIProtocolHandler.idl nsIProtocolHandler]</code> API, which serves three primary purposes:<br />
# Providing metadata about the protocol (its security characteristics, whether it requires actual network access, what the corresponding URI scheme is, what TCP port the protocol uses by default).<br />
# Creating URI objects for the protocol's scheme.<br />
# Creating channel objects for the protocol's URI objects<br />
<br />
Typically, the built-in I/O service (<code>[https://dxr.mozilla.org/mozilla-central/source/netwerk/base/nsIIOService2.idl nsIIOService]</code>) is responsible for finding the right protocol handler for URI object creation and channel creation, while a variety of consumers queries protocol metadata. Querying protocol metadata is the recommended way to handle any sort of code that needs to have different behavior for different URI schemes. In particular, unlike whitelists or blacklists, it correctly handles the addition of new protocols.<br />
<br />
A service can register itself as a protocol handler by registering for the contract ID <code>"@mozilla.org/network/protocol;1?name=SSSSS"</code> where <code>SSSS</code> is the URI scheme for the protocol (e.g. "http", "ftp", and so forth).<br />
<br />
=== URI objects ===<br />
URI objects, which implement the <code>[https://dxr.mozilla.org/mozilla-central/source/netwerk/base/nsIURI.idl nsIURI]</code> API, are a way of representing URIs and IRIs. Their main advantage over strings is that they do basic syntax checking and canonicalization on the URI string that they're provided with. They also provide various accessors to extract particular parts of the URI and provide URI equality comparisons. URIs that correspond to hierarchical schemes implement the additional <code>[https://dxr.mozilla.org/mozilla-central/source/netwerk/base/nsIURL.idl nsIURL]</code> interface, which exposes even more accessors for breaking out parts of the URI.<br />
<br />
URI objects are typically created by calling the <code>newURI</code> method on the I/O service, or in C++ by calling the <code>NS_NewURI</code> utility function. This makes sure to create the URI object using the right protocol handler, which ensures that the right kind of object is created. Direct creation of URIs via <code>createInstance</code> is reserved for protocol handler implementations.<br />
<br />
=== Channels ===<br />
[https://dxr.mozilla.org/mozilla-central/source/netwerk/base/nsIChannel.idl Channels] are the Necko representation of a single request/response interaction with a server. A channel is created by calling the <code>newChannel</code> method on the [https://dxr.mozilla.org/mozilla-central/source/netwerk/base/nsIIOService.idl I/O service], or in C++ by calling the <code>[https://dxr.mozilla.org/mozilla-central/search?q=function%3ANS_NewChannel&case=true NS_NewChannel]</code> utility function. The channel can then be configured as needed, and finally its <code>asyncOpen</code> method can be called. This method takes an <code>[https://dxr.mozilla.org/mozilla-central/source/netwerk/base/nsIStreamListener.idl nsIStreamListener]</code> as an argument.<br />
<br />
If <code>asyncOpen</code> has returned successfully, the channel guarantees that it will asynchronously call the <code>onStartRequest</code> and <code>onStopRequest</code> methods on its stream listener. This will happen even if there are network errors that prevent Necko from actually performing the requests. Such errors will be reported in the channel's status and in the <code>status</code> argument to <code>onStopRequest</code>.<br />
<br />
If the channel ends up being able to provide data, it will make one or more <code>onDataAvailable</code> on its listener after calling <code>onStartRequest</code> and before calling <code>onStopRequest</code>. For each call, the listener is responsible for either returning an error or reading the entire data stream passed in to the call.<br />
<br />
If an error is returned from either <code>onStartRequest</code> or <code>onDataAvailable</code>, the channel must act as if it has been canceled with the corresponding error code.<br />
<br />
A channel has two URI objects associated with it. The <code>originalURI</code> of the channel is the URI that was originally passed to <code>newChannel</code> to create the channel that then had <code>asyncOpen</code> called on it. The <code>URI</code> is the URI from which the channel is reading data. These can be different in various cases involving protocol handlers that forward network access to other protocol handlers, as well as in situations in which a redirect occurs (e.g. following an HTTP 3xx response). In redirect situations, a new channel object will be created, but the originalURI will be propagated from the old channel to the new channel.<br />
<br />
Note that the <code>nsIRequest</code> that's passed to onStartRequest must match the one passed to onDataAvailable and onStopRequest, but need not be the original channel that asyncOpen was called on. In particular, when an HTTP redirect happens the request argument to the callbacks will be the post-redirect channel.<br />
<br />
TODO: crypto?<br />
<br />
== Document rendering pipeline ==<br />
<br />
Some of the major components of Gecko can be described as steps on the<br />
path from an HTML document coming in from the network to the graphics<br />
commands needed to render that document. An HTML document is a<br />
serialization of a tree structure. (FIXME: add diagram) The HTML<br />
parser and content sink create an in-memory representation of this tree,<br />
which we call the '''DOM tree''' or '''content tree'''.<br />
Many JavaScript APIs operate on the content tree. Then, in<br />
layout, we create a second tree, the '''frame tree''' (or<br />
'''rendering tree''') that is a similar shape to the content tree,<br />
but where each node in the tree represents a rectangle (except in SVG<br />
where they represent other shapes). We then compute the positions of<br />
the nodes in the frame tree (called '''frames''') and paint them<br />
using our cross-platform graphics APIs (which, underneath, map to<br />
platform-specific graphics APIs).<br />
<br />
See [http://dbaron.org/talks/ David Baron's "Fast CSS: How Browsers Lay Out Web Pages" talk] for an overview of the pipeline in a presentation format.<br />
<br />
=== Parser ===<br />
<br />
The parser's job is to transform a character stream into a tree<br />
structure, with the help of the content sink classes.<br />
<br />
HTML is parsed using a parser implementing the parsing algorithm in the<br />
HTML specification (starting with HTML5). Much of this parser is<br />
translated from Java, and changes are made to the Java version. This<br />
parser in parser/html/. The parser is driven by the output of the networking layer (see nsHtml5StreamParser::OnDataAvailable). The HTML5 parser is capable of parsing off the main thread which is the normal case. It also parses on the main thread to be able to synchronously handle things such as innerHTML modifications.<br />
<br />
The codebase still has the previous generation HTML parser, which is<br />
still used for a small number of things, though we hope to be able to<br />
remove it entirely soon. This parser is in parser/htmlparser/.<br />
<br />
XML is parsed using the expat library (parser/expat/) and code that<br />
wraps it (parser/xml/). This is a non-validating parser; however, it<br />
loads certain DTDs to support XUL localization.<br />
<br />
=== DOM / Content ===<br />
<br />
The content tree or DOM tree is the central data structure for Web<br />
pages. It is a tree structure, initially created from the tree<br />
structure expressed in the HTML or XML markup. The nodes in the tree<br />
implement major parts of the DOM (Document Object Model) specifications.<br />
The nodes themselves are part of a class hierarchy rooted at<br />
<code>nsINode</code>; different derived classes are used for things such<br />
as text nodes, the document itself, HTML elements, SVG elements, etc.,<br />
with further subclasses of many of these types (e.g., for specific HTML<br />
elements). Many of the APIs available to script running in Web pages<br />
are associated with these nodes. The tree structure persists while the<br />
Web pages is displayed, since it stores much of state associated with<br />
the Web page. The code for these nodes lives in the content/ directory.<br />
<br />
The DOM APIs are not threadsafe. DOM nodes can be accessed only from<br />
the main thread (also known as the UI thread (user interface thread)) of<br />
the application.<br />
<br />
There are also many other APIs available to Web pages that are not APIs<br />
on the nodes in the DOM tree. Many of these other APIs also live in the<br />
same directories, though some live in content/ and some in dom/. These<br />
include APIs such as the DOM event model.<br />
<br />
The dom/ directory also includes some of the code needed to expose Web<br />
APIs to JavaScript (in other words, the glue code between JavaScript and<br />
these APIs). For an overview, see [https://ask.mozilla.org/question/390/how-is-the-web-exposed-dom-implemented/ DOM API Implementation]. See [[#Scripting|Scripting]] below for details of the JS engine.<br />
<br />
TODO: Internal APIs vs. DOM APIs.<br />
<br />
TODO: Mutation observers / document observers.<br />
<br />
TODO: Reference counting and cycle collection.<br />
<br />
TODO: specification links<br />
<br />
=== Style System ===<br />
<br />
==== Quantum CSS (Stylo) ====<br />
<br />
Starting with Firefox 57 and later, Gecko makes use of the parallel style system written in Rust that comes from Servo. There's an [https://hacks.mozilla.org/2017/08/inside-a-super-fast-css-engine-quantum-css-aka-stylo/ overview] of this with graphics to help explain what's going on. The [https://github.com/servo/servo/wiki/Layout-Overview Servo wiki] has some more details.<br />
<br />
==== Gecko ====<br />
<br />
The rest of the style section section describes the Gecko style system used in Firefox 56 and earlier. Some bits may still apply, but it likely needs revising.<br />
<br />
In order to display the content, Gecko needs to compute the styles<br />
relevant to each DOM node. It does this based on the model described in<br />
the CSS specifications: this model applies to style specified in CSS<br />
(e.g. by a 'style' element, an 'xml-stylesheet' processing instruction<br />
or a 'style' attribute),<br />
style specified by presentation attributes, and the default style<br />
specified by our own user agent style sheets. There are two major<br />
sets of data structures within the style system:<br />
* first, data structures that represent sources of style data, such as CSS style sheets or data from stylistic HTML attributes<br />
* second, data structures that represent computed style for a given DOM node.<br />
These sets of data structures are mostly distinct (for example, they<br />
store values in different ways).<br />
<br />
The loading of CSS style sheets from the network is managed by the <br />
[https://dxr.mozilla.org/mozilla-central/source/layout/style/Loader.h CSS loader]; <br />
they are then tokenized by the <br />
[https://dxr.mozilla.org/mozilla-central/source/layout/style/nsCSSScanner.h CSS scanner] <br />
and parsed by the <br />
[https://dxr.mozilla.org/mozilla-central/source/layout/style/nsCSSParser.h CSS parser]. <br />
Those that are attached to the document also expose APIs to<br />
script that are known as the CSS Object Model, or CSSOM.<br />
<br />
The style sheets that apply to a document are managed by a class called<br />
the [https://dxr.mozilla.org/mozilla-central/source/layout/style/nsStyleSet.h style set].<br />
The style set interacts with the different types of<br />
style sheets (representing CSS style sheets, presentational<br />
attributes, and 'style' attributes) through two interfaces:<br />
[http://dxr.mozilla.org/mozilla-central/source/layout/style/nsIStyleSheet.h nsIStyleSheet] for basic management of style sheets and<br />
[http://dxr.mozilla.org/mozilla-central/source/layout/style/nsIStyleRuleProcessor.h nsIStyleRuleProcessor] for getting the style data out of them. Usually<br />
the same object implements both interfaces, except in the most important<br />
case, CSS style sheets, where there is a single rule processor for all<br />
of the CSS style sheets in each origin (user/UA/author) of the CSS cascade.<br />
<br />
The computed style data for an element/frame are exposed to the rest of<br />
Gecko through the class mozilla::ComputedStyle (previously called<br />
nsStyleContext). Rather than having a member variable for each<br />
CSS property, it breaks up the properties into groups of related<br />
properties called style structs. These style structs obey the rule that<br />
all of the properties in a single struct either inherit by default (what<br />
the CSS specifications call "Inherited: yes" in the definition of<br />
properties; we call these inherited structs) or all are not inherited by<br />
default (we call these reset structs). Separating the properties in<br />
this way improves the ability to share the structs between similar<br />
ComputedStyle objects and reduce the amount of memory needed to store<br />
the style data. The ComputedStyle API exposes a method for getting each<br />
struct, so you'll see code like<br />
<code>sc->GetStyleText()->mTextAlign</code> for getting the value of the<br />
text-align CSS property. (Frames (see the Layout section below) also<br />
have the same<br />
GetStyle* methods, which just forward the call to the frame's<br />
ComputedStyle.)<br />
<br />
The ComputedStyles form a tree structure, in a shape somewhat like the<br />
content tree (except that we coalesce identical sibling ComputedStyles<br />
rather than keeping two of them around; if the parents have been<br />
coalesced then this can apply recursively and coalasce cousins, etc.;<br />
we do not coalesce parent/child ComputedStyles).<br />
The parent of a ComputedStyle has the style data that the ComputedStyle<br />
inherits from when CSS inheritance occurs. This means that the parent<br />
of the ComputedStyle for a DOM element is generally the ComputedStyle<br />
for that DOM element's parent, since that's how CSS says inheritance<br />
works.<br />
<br />
The process of turning the style sheets into computed style data goes<br />
through three main steps, the first two of which closely relate to the<br />
[http://dxr.mozilla.org/mozilla-central/source/layout/style/nsIStyleRule.h nsIStyleRule] interface, which represents an immutable source of style<br />
data, conceptually representing (and for CSS style rules, directly<br />
storing) a set of property:value pairs. (It is similar to the idea of a<br />
CSS style rule, except that it is immutable; this immutability allows<br />
for significant optimization. When a CSS style rule is changed through<br />
script, we create a new style rule.)<br />
<br />
The first step of going from style sheets to computed style data is<br />
finding the ordered sequence of style rules that apply to an element.<br />
The order represents which rules override which other rules: if two<br />
rules have a value for the same property, the higher ranking one wins.<br />
(Note that there's another difference from CSS style rules: declarations<br />
with !important are represented using a separate style rule.) This is<br />
done by calling one of the nsIStyleRuleProcessor::RulesMatching methods.<br />
The ordered sequence is stored in a<br />
[http://en.wikipedia.org/wiki/Trie trie] called the rule tree: the path<br />
from the root of the rule tree to any (leaf or non-leaf) node in the<br />
rule tree represents a sequence of rules, with the highest ranking<br />
farthest from the root. Each rule node (except for the root) has a<br />
pointer to a rule, but since a rule may appear in many sequences, there<br />
are sometimes many rule nodes pointing to the same rule. Once we have<br />
this list we create a ComputedStyle (or find an appropriate existing<br />
sibling) with the correct parent pointer (for inheritance) and rule node<br />
pointer (for the list of rules), and a few other pieces of information<br />
(like the pseudo-element).<br />
<br />
The second step of going from style sheets to computed style data is<br />
getting the winning property:value pairs from the rules. (This only<br />
provides property:value pairs for some of the properties; the remaining<br />
properties will fall back to inheritance or to their initial values<br />
depending on whether the property is inherited by default.) We do this<br />
step (and the third) for each style struct, the first time it is needed.<br />
This is done in nsRuleNode::WalkRuleTree, where we ask each style rule<br />
to fill in its property:value pairs by calling its MapRuleInfoInto<br />
function. When called, the rule fills in only those pairs that haven't<br />
been filled in already, since we're calling from the highest priority<br />
rule to the lowest (since in many cases this allows us to stop before<br />
going through the whole list, or to do partial computation that just<br />
adds to data cached higher in the rule tree).<br />
<br />
The third step of going from style sheets to computed style data (which<br />
various caching optimizations allow us to skip in many cases) is<br />
actually doing the computation; this generally means we transform the<br />
style data into the data type described in the "Computed Value" line in<br />
the property's definition in the CSS specifications. This<br />
transformation happens in functions called nsRuleNode::Compute*Data,<br />
where the * in the middle represents the name of the style struct. This<br />
is where the transformation from the style sheet value storage format to<br />
the computed value storage format happens.<br />
<br />
Once we have the computed style data, we then store it: if a style struct<br />
in the computed style data doesn't<br />
depend on inherited values or on data from other style structs, then we<br />
can cache it in the rule tree (and then reuse it, without recomputing<br />
it, for any ComputedStyles pointing to that rule node). Otherwise, we<br />
store it on the ComputedStyle (in which case it may be shared<br />
with the ComputedStyle's descendant ComputedStyles).<br />
This is where keeping inherited and<br />
non-inherited properties separate is useful: in the common case of<br />
relatively few properties being specified, we can generally cache the<br />
non-inherited structs in the rule tree, and we can generally share the<br />
inherited structs up and down the ComputedStyle tree.<br />
<br />
The ownership models in style sheet structures are a mix of reference<br />
counted structures (for things accessible from script) and directly<br />
owned structures. ComputedStyles are reference counted, and own their<br />
parents (from which they inherit), and rule nodes are garbage collected<br />
with a simple mark and sweep collector (which often never needs to run).<br />
<br />
* code: [http://dxr.mozilla.org/mozilla-central/source/layout/style/ layout/style/], where most files have useful one line descriptions at the top that show up in DXR<br />
* Bugzilla: Style System (CSS)<br />
* specifications<br />
** [http://www.w3.org/TR/CSS21/ CSS 2.1]<br />
** [http://www.w3.org/TR/css-2010/ CSS 2010, listing stable css3 modules]<br />
** [http://dev.w3.org/csswg/ CSS WG editors drafts] (often more current, but sometimes more unstable than the drafts on the technical reports page)<br />
** [http://dbaron.org/mozilla/visited-privacy Preventing attacks on a user's history through CSS :visited selectors]<br />
* documentation<br />
** [http://www-archive.mozilla.org/newlayout/doc/style-system.html style system documentation] (somewhat out of date)<br />
<br />
=== Layout ===<br />
<br />
Much of the layout code deals with operations on the frame tree (or<br />
rendering tree). In the frame tree, each node represents a rectangle<br />
(or, for SVG, other shapes). The frame tree has a shape similar to the<br />
content tree, since many content nodes have one corresponding frame,<br />
though it differs in a few ways, since some content nodes have more than<br />
one frame or don't have any frames at all. When elements are<br />
display:none in CSS or undisplayed for certain other reasons, they won't<br />
have any frames. When elements are broken across lines or pages, they<br />
have multiple frames; elements may also have multiple frames when<br />
multiple frames nested inside each other are needed to display a single<br />
element (for example, a table, a table cell, or many types of form<br />
controls).<br />
<br />
Each node in the frame tree is an instance of a class derived from<br />
<code>nsIFrame</code>. As with the content tree, there is a substantial<br />
type hierarchy, but the type hierarchy is very different: it includes<br />
types like text frames, blocks and inlines, the various parts of tables,<br />
and the various types of HTML form controls.<br />
<br />
Frames are allocated within an arena owned by the pres shell. Each<br />
frame is owned by its parent; frames are not reference counted, and code<br />
must not hold on to pointers to frames. To mitigate potential security<br />
bugs when pointers to destroyed frames, we use<br />
[http://robert.ocallahan.org/2010/10/mitigating-dangling-pointer-bugs-using_15.html frame poisoning], which takes two parts. When a frame is destroyed<br />
other than at the end of life of the presentation, we fill its memory<br />
with a pattern consisting of a repeated pointer to inaccessible memory,<br />
and then put the memory on a per-frame-class freelist. This means that<br />
if code accesses the memory through a dangling pointer, it will either<br />
crash quickly by dereferencing the poison pattern or it will find a<br />
valid frame.<br />
<br />
Like the content tree, frames must be accessed only from the UI thread.<br />
<br />
The frame tree should not store any important data. While it does<br />
usually persist while a page is being displayed, frames are often<br />
destroyed and recreated in response to certain style changes, and in the<br />
future we may do the same to reduce memory use for pages that are<br />
currently inactive. There were a number of cases where this rule was<br />
violated in the past and we stored important data in the frame tree;<br />
however, most (though not quite all) such cases are now fixed.<br />
<br />
The rectangle represented by the frame is what CSS calls the element's<br />
border box. This is the outside edge of the border (or the inside edge<br />
of the margin). The margin lives outside the border; and the padding<br />
lives inside the border. In addition to nsIFrame::GetRect, we also have<br />
the APIs nsIFrame::GetPaddingRect to get the padding box (the outside<br />
edge of the padding, or inside edge of the border) and<br />
nsIFrame::GetContentRect to get the content box (the outside edge of the<br />
content, or inside edge of the padding). These APIs may produce out of<br />
date results when reflow is needed (or has not yet occurred).<br />
<br />
In addition to tracking a rectangle, frames also track two overflow<br />
areas: visual overflow and scrollable overflow. These overflow areas<br />
represent the union of the area needed by the frame and by all its<br />
descendants. The visual overflow is used for painting-related<br />
optimizations: it is a rectangle covering all of the area that might be<br />
painted when the frame and all of its descendants paint. The scrollable<br />
overflow represents the area that the user should be able to scroll to<br />
to see the frame and all of its descendants. In some cases differences<br />
between the frame's rect and its overflow happen because of descendants<br />
that stick out of the frame; in other cases they occur because of some<br />
characteristic of the frame itself. The two overflow areas are<br />
similar, but there are differences: for example, margins are part of<br />
scrollable overflow but not visual overflow, whereas text-shadows are<br />
part of visual overflow but not scrollable overflow.<br />
<br />
When frames are broken across lines, columns, or pages, we create<br />
multiple frames representing the multiple rectangles of the element.<br />
The first one is the primary frame, and the rest are its continuations<br />
(which are more likely to be destroyed and recreated during reflow).<br />
These frames are linked together as continuations: they have a<br />
doubly-linked list that can be used to traverse the continuations using<br />
nsIFrame::GetPrevContinuation and nsIFrame::GetNextContinuation.<br />
(Currently continuations always have the same style data, though we may<br />
at some point want to break that invariant.)<br />
<br />
Continuations are sometimes siblings of each other, and sometimes not.<br />
For example, if a paragraph contains a span which contains a link, and<br />
the link is split across lines, then the continuations of the span are<br />
siblings (since they are both children of the paragraph), but the<br />
continuations of the link are not siblings (since each continuation of<br />
the link is descended from a different continuation of the span).<br />
Traversing the entire frame tree does '''not''' require considering<br />
continuations, since all of the continuations are descendants of the<br />
element containing the break.<br />
<br />
We also use continuations for cases (most importantly, bidi reordering,<br />
where left-to-right text and right-to-left text need to be separated<br />
into different continuations since they may not form a contiguous<br />
rectangle) where the continuations should not be rewrapped during<br />
reflow: we call these continuations fixed rather than fluid.<br />
nsIFrame::GetNextInFlow and nsIFrame::GetPrevInFlow traverse only the<br />
fluid continuations and do not cross fixed continuation boundaries.<br />
<br />
If an inline frame has non-inline children, then we split the original <br />
inline frame into parts. The original inline's children are <br />
distributed into these parts like so- The children of the original <br />
inline are grouped into runs of inline and non-inline and runs of <br />
inline get an inline parent while runs of non-inline get an anonymous <br />
block parent. This is 'ib-splitting' or block-inside-inline-splitting. <br />
This splitting proceeds recursively up the frame tree until all <br />
non-inlines inside inlines are ancestors of a block frame with anonymous <br />
block wrappers in between. This splitting maintains the relative order<br />
between these child frames and the relationship between the parts of a <br />
split inline is maintained using an ib-sibling chain. It is important <br />
to note that any wrappers created during frame construction (such as <br />
for tables) may not be included in the ib-sibling chain depending on <br />
when this wrapper creation takes place. <br />
<br />
TODO: nsBox craziness from https://bugzilla.mozilla.org/show_bug.cgi?id=524925#c64<br />
<br />
TODO: link to documentation of block and inline layout<br />
<br />
TODO: link to documentation of scrollframes<br />
<br />
TODO: link to documentation of XUL frame classes<br />
<br />
Code (note that most files in base and generic have useful one line descriptions at the top that show up in DXR):<br />
* [http://dxr.mozilla.org/mozilla-central/source/layout/base/ layout/base/] contains objects that coordinate everything and a bunch of other miscellaneous things<br />
* [http://dxr.mozilla.org/mozilla-central/source/layout/generic/ layout/generic/] contains the basic frame classes as well as support code for their reflow methods (ReflowInput, ReflowOutput)<br />
* [http://dxr.mozilla.org/mozilla-central/source/layout/forms/ layout/forms/] contains frame classes for HTML form controls<br />
* [http://dxr.mozilla.org/mozilla-central/source/layout/tables/ layout/tables/] contains frame classes for CSS/HTML tables<br />
* [http://dxr.mozilla.org/mozilla-central/source/layout/mathml/ layout/mathml/] contains frame classes for MathML<br />
* [http://dxr.mozilla.org/mozilla-central/source/layout/svg/ layout/svg/] contains frame classes for SVG<br />
* [http://dxr.mozilla.org/mozilla-central/source/layout/xul/ layout/xul/] contains frame classes for the XUL box model and for various XUL widgets<br />
<br />
Bugzilla:<br />
* All of the components whose names begin with "Layout" in the "Core" product<br />
<br />
Further documentation:<br />
* Talk: [https://air.mozilla.org/introduction-to-graphics-layout-architecture/ Introduction to graphics/layout architecture] (Robert O'Callahan, 2014-04-18)<br />
* Talk: [https://air.mozilla.org/bz-layout-and-styles/ Layout and Styles] (Boris Zbarsky, 2014-10-14)<br />
<br />
<br />
==== Frame Construction ====<br />
<br />
Frame construction is the process of creating frames. This is done when styles change in ways that require frames to be created or recreated or when nodes are inserted into the document. The content tree and the frame tree don't have quite the same shape, and the frame construction process does some of the work of creating the right shape for the frame tree. It handles the aspects of creating the right shape that don't depend on layout information. So for example, frame construction handles the work needed to implement [http://www.w3.org/TR/CSS21/tables.html#anonymous-boxes table anonymous objects] but does not handle frames that need to be created when an element is broken across lines or pages.<br />
<br />
The basic unit of frame construction is a run of contiguous children of a single parent element. When asked to construct frames for such a run of children, the frame constructor first determines, based on the siblings and parent of the nodes involved, where in the frame tree the new frames should be inserted. Then the frame constructor walks through the list of content nodes involved and for each one creates a temporary data structure called a '''frame construction item'''. The frame construction item encapsulates various information needed to create the frames for the content node: its style data, some metadata about how one would create a frame for this node based on its namespace, tag name, and styles, and some data about what sort of frame will be created. This list of frame construction items is then analyzed to see whether constructing frames based on it and inserting them at the chosen insertion point will produce a valid frame tree. If it will not, the frame constructor either fixes up the list of frame construction items so that the resulting frame tree would be valid or throws away the list of frame construction items and requests the destruction and re-creation of the frame for the parent element so that it has a chance to create a list of frame construction items that it <em>can</em> fix up.<br />
<br />
Once the frame constructor has a list of frame construction items and an insertion point that would lead to a valid frame tree, it goes ahead and creates frames based on those items. Creation of a non-leaf frame recursively attempts to create frames for the children of that frame's element, so in effect frames are created in a depth-first traversal of the content tree.<br />
<br />
The vast majority of the code in the frame constructor, therefore, falls into one of these categories:<br />
* Code to determine the correct insertion point in the frame tree for new frames.<br />
* Code to create, for a given content node, frame construction items. This involves some searches through static data tables for metadata about the frame to be created.<br />
* Code to analyze the list of frame construction items.<br />
* Code to fix up the list of frame construction items.<br />
* Code to create frames from frame construction items.<br />
<br />
Code: [http://dxr.mozilla.org/mozilla-central/source/layout/base/nsCSSFrameConstructor.h layout/base/nsCSSFrameConstructor.h] and [http://dxr.mozilla.org/mozilla-central/source/layout/base/nsCSSFrameConstructor.cpp layout/base/nsCSSFrameConstructor.cpp]<br />
<br />
==== Reflow ====<br />
<br />
Reflow is the process of computing the positions and sizes of frames. (After all,<br />
frames represent rectangles, and at some point we need to figure out<br />
exactly *what* rectangle.) Reflow is done recursively, with each<br />
frame's Reflow method calling the Reflow methods on that frame's<br />
descendants.<br />
<br />
In many cases, the correct results are defined by CSS specifications<br />
(particularly [http://www.w3.org/TR/CSS21/visudet.html CSS 2.1]). In some cases, the details are not defined by<br />
CSS, though in some (but not all) of those cases we are constrained by<br />
Web compatibility. When the details are defined by CSS, however, the<br />
code to compute the layout is generally structured somewhat differently<br />
from the way it is described in the CSS specifications, since the CSS<br />
specifications are generally written in terms of constraints, whereas<br />
our layout code consists of algorithms optimized for incremental<br />
recomputation.<br />
<br />
The reflow generally starts from the root of the frame tree, though some other<br />
types of frame can act as reflow roots and start a reflow from them.<br />
Reflow roots must obey the invariant that a change inside one of their<br />
descendants never changes their rect or overflow areas (though currently<br />
scrollbars are reflow roots but don't quite obey this invariant).<br />
<br />
In many cases, we want to reflow a part of the frame tree, and we want<br />
this reflow to be efficient. For example, when content is added or<br />
removed from the document tree or when styles change, we want the amount<br />
of work we need to redo to be proportional to the amount of content. We<br />
also want to efficiently handle a series of changes to the same content.<br />
<br />
To do this, we maintain two bits on frames:<br />
[http://dxr.mozilla.org/mozilla-central/search?q=var%3ANS_FRAME_IS_DIRTY&case=true&redirect=true NS_FRAME_IS_DIRTY]<br />
indicates that a frame and all of its descendants require reflow.<br />
[http://dxr.mozilla.org/mozilla-central/search?q=var%3ANS_FRAME_HAS_DIRTY_CHILDREN&case=true&redirect=true NS_FRAME_HAS_DIRTY_CHILDREN]<br />
indicates that a frame has a descendant that<br />
is dirty or has had a descendant removed (i.e., that it has a child that<br />
has NS_FRAME_IS_DIRTY or NS_FRAME_HAS_DIRTY_CHILDREN or it had a child<br />
removed). These bits allow coalescing of multiple updates; this<br />
coalescing is done in nsPresShell, which tracks the set of reflow roots<br />
that require reflow. The bits are set during calls to<br />
nsPresShell::FrameNeedsReflow and are cleared during reflow.<br />
<br />
The layout algorithms used by many of the frame classes are those<br />
specified in CSS, which are based on the traditional document formatting<br />
model, where widths are input and heights are output.<br />
<br />
In some cases, however, widths need to be determined based on the<br />
content. This depends on two ''intrinsic widths'': the minimum<br />
intrinsic width (see [http://dxr.mozilla.org/search?q=type%3AnsIFrame%20function%3AGetMinWidth&tree=mozilla-central nsIFrame::GetMinWidth]) and the preferred intrinsic<br />
width (see [http://dxr.mozilla.org/search?q=type%3AnsIFrame%20function%3AGetPrefWidth&tree=mozilla-central nsIFrame::GetPrefWidth]). The concept of what these widths<br />
represent is best explained by describing what they are on a paragraph<br />
containing only text: in such a paragraph the minimum intrinsic width<br />
is the width of the longest word, and the preferred intrinsic width is<br />
the width of the entire paragraph laid out on one line.<br />
<br />
Intrinsic widths are invalidated separately from the dirty bits<br />
described above. When a caller informs the pres shell that a frame<br />
needs reflow (nsIPresShell::FrameNeedsReflow), it passes one of three<br />
options:<br />
* eResize indicates that no intrinsic widths are dirty<br />
* eTreeChange indicates that intrinsic widths on it and its ancestors are dirty (which happens, for example, if new children are added to it)<br />
* eStyleChange indicates that intrinsic widths on it, its ancestors, and its descendants are dirty (for example, if the font-size changes)<br />
<br />
Reflow is the area where the XUL frame classes (those that inherit from<br />
nsBoxFrame or nsLeafBoxFrame) are most different from the rest. Instead<br />
of using nsIFrame::Reflow, they do their layout computations using<br />
intrinsic size methods called GetMinSize, GetPrefSize, and GetMaxSize<br />
(which report intrinsic sizes in two dimensions) and a final layout<br />
method called Layout. In many cases these methods defer some of the<br />
computation to a separate object called a layout manager.<br />
<br />
When an individual frame's Reflow method is called, most of the input is<br />
provided on an object called ReflowInput and the output is filled<br />
in to an object called ReflowOutput. After reflow, the caller<br />
(usually the parent) is responsible for setting the frame's size based<br />
on the metrics reported. (This can make some computations during reflow<br />
difficult, since the new size is found in either the reflow state or the<br />
metrics, but the frame's size is still the old size. However, it's<br />
useful for invalidating the correct areas that need to be repainted.)<br />
<br />
One major difference worth noting is that in XUL layout, the size of the<br />
child is set prior to its parent calling its Layout method. (Once<br />
invalidation uses display lists and is no longer tangled up in Reflow,<br />
it may be worth switching non-XUL layout to work this way as well.)<br />
<br />
==== Painting ====<br />
<br />
TODO: display lists (and event handling)<br />
<br />
TODO: layers<br />
<br />
==== Pagination ====<br />
<br />
The concepts behind pagination (also known as fragmentation) are a bit complicated, so for now we've split them off into a separate document: [[Gecko:Continuation_Model]]. This code is used for printing, print-preview, and multicolumn frames.<br />
<br />
=== Dynamic change handling along the rendering pipeline ===<br />
<br />
The ability to make changes to the DOM from script is a major feature of the Web platform. Web authors rely on the concept (though there are a few exceptions, such as animations) that changing the DOM from script leads to the same rendering that would have resulted from starting from that DOM tree. They also rely on the performance characteristics of these changes: small changes to the DOM that have small effects should have proportionally small processing time. This means that Gecko needs to efficiently propagate changes from the content tree to style, the frame tree, the geometry of the frame tree, and the screen.<br />
<br />
For many types of changes, however, there is substantial overhead to processing a change, no matter how small. For example, reflow must propagate from the top of the frame tree down to the frames that are dirty, no matter how small the change. One very common way around this is to batch up changes. We batch up changes in lots of ways, for example:<br />
* The content sink adds multiple nodes to the DOM tree before notifying listeners that they've been added. This allows notifying once about an ancestor rather than for each of its descendants, or notifying about a group of descendants all at once, which speeds up the processing of those notifications.<br />
* We batch up nodes that require style reresolution (recomputation of selector matching and processing the resulting style changes). This batching is tree based, so it not only merges multiple notifications on the same element, but also merges a notification on an ancestor with a notification on its descendant (since ''some'' of these notifications imply that style reresolution is required on all descendants).<br />
* We wait to reconstruct frames that require reconstruction (after destroying frames eagerly). This, like the tree-based style reresolution batching, avoids duplication both for same-element notifications and ancestor-descendant notifications, even though it doesn't actually do any tree-based caching.<br />
* We postpone doing reflows until needed. As for style reresolution, this maintains tree-based dirty bits (see the description of NS_FRAME_IS_DIRTY and NS_FRAME_HAS_DIRTY_CHILDREN under Reflow).<br />
* We allow the OS to queue up multiple invalidates before repainting (though we will likely switch to controlling that ourselves). This leads to a single repaint of some set of pixels where there might otherwise have been multiple (though it may also lead to more pixels being repainted if multiple rectangles are merged to a single one).<br />
<br />
Having changes buffered up means, however, that various pieces of information (layout, style, etc.) may not be up-to-date. Some things require up-to-date information: for example, we don't want to expose the details of our buffering to Web page script since the programming model of Web page script assumes that DOM changes take effect "immediately", i.e., that the script shouldn't be able to detect any buffering. Many Web pages depend on this.<br />
<br />
We therefore have ways to flush these different sorts of buffers. There are methods called FlushPendingNotifications on nsIDocument and nsIPresShell, that take an argument of what things to flush:<br />
* Flush_Content: create all the content nodes from data buffered in the parser<br />
* Flush_ContentAndNotify: the above, plus notify document observers about the creation of all nodes created so far<br />
* Flush_Style: the above, plus make sure style data are up-to-date<br />
* Flush_Frames: the above, plus make sure all frame construction has happened (currently the same as Flush_Style)<br />
* Flush_InterruptibleLayout: the above, plus perform layout (Reflow), but allow interrupting layout if it takes too long<br />
* Flush_Layout: the above, plus ensure layout (Reflow) runs to completion<br />
* Flush_Display (should never be used): the above, plus ensure repainting happens<br />
<br />
The major way that notifications of changes propagate from the content code to layout and other areas of code is through the nsIDocumentObserver and nsIMutationObserver interfaces. Classes can implement this interface to listen to notifications of changes for an entire document or for a subtree of the content tree.<br />
<br />
WRITE ME: ... layout document observer implementations<br />
<br />
TODO: how style system optimizes away rerunning selector matching<br />
<br />
TODO: style changes and nsChangeHint<br />
<br />
=== Refresh driver ===<br />
<br />
== Graphics ==<br />
[https://wiki.mozilla.org/Platform/GFX Wiki page] | [https://wiki.mozilla.org/index.php?title=Platform/GFX/Contribute contribute]<br />
<br />
Further documentation:<br />
* Talk: [https://air.mozilla.org/introduction-to-graphics-layout-architecture/ Introduction to graphics/layout architecture] (Robert O'Callahan, 2014-04-18)<br />
* Talk: [https://air.mozilla.org/bjacob-gfx-overview/ An overview of Gecko's graphics stack] (Benoit Jacob, 2014-08-12)<br />
* Talk: [https://air.mozilla.org/jeff-muizelaar-2d-graphics/ 2D Graphics] (Jeff Muizelaar, 2014-10-14)<br />
<br />
==== Painting/Rasterizing ====<br />
<br />
Painting/rendering/rasterizing is the step where graphical primitives (such as a command to fill an [https://developer.mozilla.org/en-US/docs/Web/SVG SVG] circle, or a [https://developer.mozilla.org/en-US/docs/Web/Guide/Graphics/Drawing_graphics_with_canvas canvas] command to stroke a path between x, y, z, or the internally produced command to draw the edge of an HTML div's border) are used to color in the pixels of a surface so that the surface "displays" those rasterized primitives.<br />
<br />
The platform independent library that gecko uses to render is [http://dxr.mozilla.org/mozilla-central/source/gfx/2d/2D.h Moz2D]. Gecko code paints into Moz2D DrawTarget objects (the DrawTarget baseclass having multiple platform dependent subclasses). (At least this is where gecko is going - for now there is still significant amounts of code that uses [http://dxr.mozilla.org/mozilla-central/source/gfx/thebes/gfxContext.h Thebes gfxContext] objects or the even older nsRenderingContext objects. Objects of these types now always wrap a DrawTarget so all painting does now go through Moz2D, but conversion to use the wrapped DrawTargets directly is taking time since consumer code can sometimes need to be radically rewritten to fit the Moz2D API and immediate mode paradigm.)<br />
<br />
==== Compositing ====<br />
<br />
The compositing stage of the rendering pipeline is operated by the [http://dxr.mozilla.org/mozilla-central/source/gfx/layers/ gfx/layers] module.<br />
<br />
Different parts of a web page can sometimes be painted into intermediate surfaces retained by layers. It can be convenient to think of layers as the layers in image manipulation programs like The Gimp or Photoshop. Layers are organized as a tree. Layers are primarily used to minimize invalidating and repainting when elements are being animated independently of one another in a way that can be optimized using layers (e.g. opacity or transform animations), and to enable some effects (such as transparency and 3D transforms).<br />
<br />
Compositing is the action of flattening the layers into the final image that is shown on the screen.<br />
<br />
On some platform, compositing happens on the Content thread. However, on other platforms we composite on a separate thread (Off-main-thread compositing, or OMTC). OMTC is at the moment the default behavior on mobile platforms, but the goal is to do it on all platforms in the long run.<br />
<br />
The Layers architecture is built on the following notions:<br />
* Compositor: an object that can draw quads on the screen (or on an off-screen render target).<br />
* Texture: an object that contains image data.<br />
* Compositable: an object that can manipulate one or several textures, and knows how to present them to the compositor<br />
* Layer: an element of the layer tree. A layer usually doesn't know much about compositing: it uses a compositable to do the work. Layers are mostly nodes of the layer tree.<br />
<br />
[[File:LayersRefactoring.png|thumb|650px|New layers architecture, with OGL backend]]<br />
<br />
The above abstractions are sufficient to perform compositing on the main thread, but on the OMTC case, we need a mechanism to synchronize a client layer tree that is constructed on the content thread, and a host layer tree that is used for compositing on the compositor thread.<br />
This synchronization process must ensure that the host layer tree reflects the state of the current layer tree while remaining in a consistent state, and must transfer texture data from a thread to the other. Moreover, on some platforms the content and compositor threads may live in separate processes.<br />
<br />
To perform this synchronization, we use the IPDL IPC framework. IPDL lets us describe communications protocols and actors in a domain specific language. for more information about IPDL, read https://wiki.mozilla.org/IPDL<br />
<br />
When the client layer tree is modified, we record modifications into messages that are sent together to the host side within a transaction. A transaction is basically a list of modifications to the layer tree that have to be applied all at once to preserve consistency in the state of the host layer tree.<br />
<br />
Texture transfer is done by synchronizing texture objects across processes/threads using a couple TextureClient/TextureHost that wrap shared data and provide access to it on both sides. TextureHosts provide access to one or several TextureSource, which has the necessary API to actually composite the texture (TextureClient/Host being more about IPC synchronization than actual compositing.<br />
The logic behind texture transfer (as in single/double/triple buffering, texture tiling, etc) is operated by the CompositableClient and CompositableHost.<br />
<br />
It is important to understand the separation between layers and compositables. Compositables handle all the logic around texture transfer, while layers define the shape of the layer tree. a Compositable is created independently from a layer and attached to it on both sides. While layers transactions can only originate from the content thread, this separation makes it possible for us to have separate compositable transactions between any thread and the compositor thread. We use the ImageBridge IPDL protocol to that end. The Idea of ImageBridge is to create a Compositable that is manipulated on the ImageBridgeThread, and that can transfer/synchronize textures without using the content thread at all. This is very useful for smooth Video compositing: video frames are decoded and passed into the ImageBridge without ever touching the content thread, which could be busy processing reflows or heavy javascript workloads.<br />
<br />
It is worth reading the inline code documentation in the following files:<br />
* [http://dxr.mozilla.org/mozilla-central/source/gfx/layers/Compositor.h gfx/layers/Compositor.h]<br />
* [http://dxr.mozilla.org/mozilla-central/source/gfx/layers/ShadowLayers.h gfx/layers/ShadowLayers.h]<br />
* [http://dxr.mozilla.org/mozilla-central/source/gfx/layers/Layers.h gfx/layers/Layers.h]<br />
* [http://dxr.mozilla.org/mozilla-central/source/gfx/layers/host/TextureHost.h gfx/layers/host/TextureHost.h]<br />
* [http://dxr.mozilla.org/mozilla-central/source/gfx/layers/client/CompositableClient.h gfx/layers/client/CompositableClient.h]<br />
<br />
To visualize how a web page is layered, turn on the pref "layers.draw-borders" in about:config. When this pref is on, the borders of layers and tiles are displayed on top of the content. This only works when using the new Compositor API, that is when off-main-thread compositing is activated. OMTC is activated by default on all mobile platforms, and will progressively get activated on desktop platforms (not yet, though). On platforms where OMTC is not used, this pref has no effect. <br />
<br />
Blog posts with information on Layers that should be integrated here:<br />
<br />
* [http://www.basschouten.com/blog1.php/layers-cross-platform-acceleration Layers: Cross-Platform Acceleration]<br />
* [http://robert.ocallahan.org/2010/04/layers_01.html Layers]<br />
* [http://robert.ocallahan.org/2010/07/retained-layers_16.html Retained Layers]<br />
* [http://chrislord.net/index.php/2011/07/25/shadow-layers-and-learning-by-failing/ Shadow Layers, and learning by failing]<br />
* [http://chrislord.net/index.php/2011/08/16/accelerated-layer-rendering-and-learning-by-some-success/ Accelerated layer-rendering, and learning by (some) success]<br />
* [http://featherweightmusings.blogspot.co.uk/2012/05/mask-layers_26.html Mask Layers]<br />
* [http://featherweightmusings.blogspot.co.uk/2012/05/building-mask-layer.html Building a mask layer]<br />
* [http://featherweightmusings.blogspot.co.uk/2012/06/mask-layers-on-direct3d-backends.html Mask Layers on the Direct3D backends]<br />
* [http://robert.ocallahan.org/2011/09/graphics-api-design.html Graphics API Design]<br />
<br />
==== Async Panning and Zooming ====<br />
<br />
On some of our mobile platforms we have some code that allows the user to do asynchronous (i.e. off-main-thread) panning and zooming of content. This code is the Async Pan/Zoom module (APZ) code and is further documented at [[Platform/GFX/APZ]].<br />
<br />
== Scripting ==<br />
<br />
=== JavaScript Engine ===<br />
<br />
Gecko embeds the SpiderMonkey JavaScript engine (located in js/src). The JS engine includes a number of Just-In-Time compilers (or JITs). SpiderMonkey provides a powerful and extensive embedding API (called the JSAPI). Because of its complexity, using the JSAPI directly is frowned upon, and a number of abstractions have been built in Gecko to allow interacting with the JS engine without using JSAPI directly. Some JSAPI concepts are important for Gecko developers to understand, and they are listed below:<br />
<br />
* Global object: The '''global object''' is the object on which all global variables/properties/methods live. In a web page this is the 'window' object. In other things such as XPCOM components or sandboxes XPConnect creates a global object with a small number of builtin APIs.<br />
* Compartments: A '''compartment''' is a subdivision of the JS heap. The mapping from global objects to compartments is one-to-one; that is, every global object has a compartment associated with it, and no compartment is associated with more than one global object. (NB: There are compartments associated with no global object, but they aren't very interesting). When JS code is running SpiderMonkey has a concept of a "current" compartment. New objects that are created will be created in the "current" compartment and associated with the global object of that compartment.<br />
* When objects in one compartment can see objects in another compartment (via e.g. iframe.contentWindow.foo) '''cross-compartment wrappers''' or '''CCWs''' mediate the interaction between the two compartments. By default CCWs ensure that the current compartment is kept up-to-date when execution crosses a compartment boundary. SpiderMonkey also allows embeddings to extend wrappers with custom behavior to implement security policies, which Gecko uses extensively (see the Security section for more information).<br />
<br />
=== XPConnect ===<br />
<br />
'''XPConnect''' is a bridge between C++ and JS used by XPCOM components exposed to or implemented in JavaScript. XPConnect allows two XPCOM components to talk to each other without knowing or caring which language they are implemented in. XPConnect allows JS code to call XPCOM components by exposing XPCOM interfaces as JS objects, and mapping function calls and attributes from JS into virtual method calls on the underlying C++ object. It also allows JS code to implement an XPCOM component that can be called from C++ by faking the vtable of an interface and translating calls on the interface into JS calls. XPConnect accomplishes this using the vtable data stored in XPCOM TypeLibs (or XPT files) by the XPIDL compiler and a small layer of platform specific code called [https://developer.mozilla.org/en-US/docs/xptcall_FAQ xptcall] that knows how to interact with and impersonate vtables of XPCOM interfaces.<br />
<br />
XPConnect is also used for a small (and decreasing) number of legacy DOM objects. At one time all of the DOM used XPConnect to talk to JS, but we have been replacing XPConnect with the WebIDL bindings (see the next section for more information). Arbitrary XPCOM components are not exposed to web content. XPCOM components that want to be accessible to web content must provide class info (that is, they must QI to nsIClassInfo) and must be marked with the nsIClassInfo::DOM_OBJECT flag. Most of these objects also are listed in dom/base/nsDOMClassInfo.cpp, where the interfaces that should be visible to the web are enumerated. This file also houses some "scriptable helpers" (classes ending in "SH" and implementing nsIXPCScriptable), which are a set of optional hooks that can be used by XPConnect objects to implement more exotic behaviors (such as indexed getters or setters, lazily resolved properties, etc). This is all legacy code, and any new DOM code should use the WebIDL bindings.<br />
<br />
=== WebIDL Bindings ===<br />
<br />
The '''WebIDL bindings''' are a separate bridge between C++ and JS that is specifically designed for use by DOM code. We intend to replace all uses of XPConnect to interface with content JavaScript with the WebIDL bindings. [https://developer.mozilla.org/en-US/docs/Mozilla/WebIDL_bindings Extensive documentation] on the WebIDL bindings is available, but the basic idea is that a binding generator takes WebIDL files from web standards and some configuration data provided by us and generates at build time C++ glue code that sits between the JS engine and the DOM object. This setup allows us to produce faster, more specialized code for better performance at the cost of increased codesize.<br />
<br />
The WebIDL bindings also implement all of the behavior specified in WebIDL, making it possible for new additions to the DOM to behave correctly "out of the box". The binding layer also provides C++ abstractions for types that would otherwise require direct JSAPI calls to handle, such as typed arrays. <br />
<br />
=== Security ===<br />
<br />
Gecko's JS security model is based on the concept of compartments. Every compartment has a '''principal''' associated with it that contains security information such as the '''origin''' of the compartment, whether or not it has system privileges, etc. For the following discussion, '''wrappee''' refers to the underlying object being wrapped, '''scope''' refers to the compartment the object is being wrapped for use in, and '''wrapper''' refers to the object created in '''scope''' that allows it to interact with '''wrappee'''. "Chrome" refers to JS that is built in to the browser or part of an extension, which runs with full privileges, and is contrasted with "content", which is web provided script that is subject to security restrictions and the same origin policy.<br />
<br />
* Xray wrappers: Xray wrappers are used when the scope has chrome privileges and the wrappee is the JS reflection of an underlying DOM object. Beyond the usual CCW duties of making sure that content code does not run with chrome privileges, Xray wrappers also ensure that calling methods or accessing attributes on the wrappee has the "expected" effect. For example, a web page could replace the <code>close</code> method on its window with a JS function that does something completely different. (e.g. <code>window.close = function() { alert("This isn't what you wanted!") };</code>). Overwriting methods in this way (or creating entirely new ones) is referred to as '''expando''' properties. Xrays see through expando properties, invoking the original method/getter/setter if the expando overwrites a builtin or seeing undefined in the expando creates a new property. This allows chrome code to call methods on content DOM objects without worrying about how the page has changed the object.<br />
* Waived xray wrappers: The xray behavior is not always desirable. It is possible for chrome to "waive" the xray behavior and see the actual JS object. The wrapper still guarantees that code runs with the correct privileges, but methods/getters/setters may not behave as expected. This is equivalent to the behavior chrome sees when it looks at non-DOM content JS objects.<br />
* For more information, see the [https://developer.mozilla.org/en-US/docs/Mozilla/Gecko/Script_security MDN page]<br />
* bholley's [https://air.mozilla.org/enter-the-compartment/ Enter the Compartment] talk also provides an overview of our compartment architecture.<br />
<br />
== Images ==<br />
<br />
== Plugins ==<br />
<br />
== Platform-specific layers ==<br />
<br />
* widget<br />
* native theme<br />
* files, networking, other low-level things<br />
* Accessibility APIs<br />
* Input. Touch-input stuff is somewhat described at [[Platform/Input/Touch]].<br />
<br />
== Editor ==<br />
<br />
== Base layers ==<br />
<br />
=== NSPR ===<br />
<br />
NSPR is a library for providing cross-platform APIs for various<br />
platform-specific functions. We tend to be trying to use it as little<br />
as possible, although there are a number of areas (particularly some<br />
network-related APIs and threading/locking primitives) where we use it<br />
quite a bit.<br />
<br />
=== XPCOM ===<br />
<br />
XPCOM is a cross-platform modularity library, modeled on Microsoft COM. It<br />
is an object system in which all objects inherit from the <code>nsISupports</code> interface.<br />
<br />
components and services, contract IDs and CIDs<br />
<br />
prior overuse of XPCOM; littering with XPCOM does not produce modularity<br />
<br />
Base headers (part of xpcom/base/) and data structures. See also mfbt.<br />
<br />
Threading<br />
<br />
xptcall, proxies<br />
<br />
reference counting, cycle collection<br />
<br />
Further documentation:<br />
* XPCOM and Internal Strings in Gecko (talk by David Baron, 2014-03-20): [https://air.mozilla.org/xpcom-and-internal-strings-in-gecko/ video], [https://dbaron.org/talks/2014-03-20-xpcom-string-taipei/speaking-notes speaking notes]<br />
<br />
=== String ===<br />
<br />
XPCOM has string classes for representing sequences of characters. Typical C++ string classes have the goals of encapsulating the memory management of buffers and the issues needed to avoid buffer overruns common in traditional C string handling. Mozilla's string classes have these goals, and also the goal of reducing copying of strings.<br />
<br />
(There is a second set of string classes in xpcom/glue for callers outside of libxul; these classes are partially source-compatible but have different (worse) performance characteristics. This discussion does not cover those classes.)<br />
<br />
We have two parallel sets of classes, one for strings with 1-byte units (<code>char</code>, which may be signed or unsigned), and one for strings with 2-byte units (<code>char16_t</code>, always unsigned). The classes are named such that the class for 2-byte characters ends with <code>String</code> and the corresponding class for 1-byte characters ends with <code>CString</code>. 2-byte strings are almost always used to encode [http://en.wikipedia.org/wiki/UTF-16 UTF-16]. 1-byte strings are usually used to encode either [http://en.wikipedia.org/wiki/ASCII ASCII] or [http://en.wikipedia.org/wiki/UTF-8 UTF-8], but are sometimes also used to hold data in some other encoding or just byte sequences.<br />
<br />
The string classes distinguish, as part of the type hierarchy, between strings that must have a null-terminator at the end of their buffer (<code>ns[C]String</code>) and strings that are not required to have a null-terminator (<code>ns[C]Substring</code>). <code>ns[C]Substring</code> is the base of the string classes (since it imposes fewer requirements) and <code>ns[C]String</code> is a class derived from it. Functions taking strings as parameters should generally take one of these four types.<br />
<br />
In order to avoid unnecessary copying of string data (which can have significant performance cost), the string classes support different ownership models. All string classes support the following three ownership models dynamically:<br />
* reference counted, copy-on-write, buffers (the default)<br />
* adopted buffers (a buffer that the string class owns, but is not reference counted, because it came from somewhere else)<br />
* dependent buffers, that is, an underlying buffer that the string class does not own, but that the caller that constructed the string guarantees will outlive the string instance<br />
In addition, there is a special string class, <code>nsAuto[C]String</code>, that ''additionally'' contains an internal 64-unit buffer (intended primarily for use on the stack), leading to a fourth ownership model:<br />
* storage within an auto string's stack buffer<br />
Auto strings will prefer reference counting an existing reference-counted buffer over their stack buffer, but will otherwise use their stack buffer for anything that will fit in it.<br />
<br />
There are a number of additional string classes, particularly <code>nsDependent[C]String</code>, <code>nsDependent[C]Substring</code>, and the <code>NS_LITERAL_[C]STRING</code> macros which construct an <code>nsLiteral[C]String</code> which exist primarily as constructors for the other types. These types are really just convenient notation for constructing an <code>ns[C]S[ubs]tring</code> with a non-default ownership mode; they should not be thought of as different types. (The <code>Substring</code>, <code>StringHead</code>, and <code>StringTail</code> functions are also constructors for dependent [sub]strings.) Non-default ownership modes can also be set up using the <code>Rebind</code> and <code>Adopt</code> methods, although the <code>Rebind</code> methods actually live on the derived types, which is probably a mistake (although moving them up would require some care to avoid making an API that easily allows assigning a non-null-terminated buffer to a string whose static type indicates that it is null-terminated).<br />
<br />
Note that the presence of all of these classes imposes some awkwardness in terms of distinctions being available as both static type distinctions and dynamic type distinctions. In general, the only distinctions that should be made statically are 1-byte vs. 2-byte sequences (<code>CString</code> vs <code>String</code>) and whether the buffer is null-terminated or not (<code>Substring</code> vs <code>String</code>). (Does the code actually do a good job of dynamically enforcing the <code>Substring</code> vs. <code>String</code> restriction?)<br />
<br />
TODO: buffer growth, concatenation optimizations<br />
<br />
TODO: encoding conversion, what's validated and what isn't<br />
<br />
TODO: "string API", nsAString (historical)<br />
<br />
* Code: xpcom/string/<br />
* Bugzilla: Core::String<br />
<br />
Further documentation:<br />
* XPCOM and Internal Strings in Gecko (talk by David Baron, 2014-03-20): [https://air.mozilla.org/xpcom-and-internal-strings-in-gecko/ video], [https://dbaron.org/talks/2014-03-20-xpcom-string-taipei/speaking-notes speaking notes]</div>Dbaronhttps://wiki.mozilla.org/index.php?title=Gecko:Overview&diff=1193204Gecko:Overview2018-05-02T21:25:46Z<p>Dbaron: /* Layout */ fix bad delimeter</p>
<hr />
<div>This document attempts to give an overview of the different parts of<br />
Gecko, what they do, and why they do it, say where the code for them is<br />
within the repository, and link to more specific documentation (when<br />
available) covering the details of that code. '''It is not yet complete.''' Maintainers of these<br />
areas of code should correct errors, add information, and add links to<br />
more detailed documentation (since this document is intended to remain<br />
an overview, not complete documentation).<br />
<br />
__TOC__<br />
<br />
== Browsers, Frames, and Document Navigation ==<br />
<br />
=== Docshell ===<br />
<br />
The user of a Web browser can change the page shown in that browser in<br />
many ways: by clicking a link, loading a new URL, using the forward and<br />
back buttons, or other ways. This can happen inside a space we'll call<br />
a '''browsing context'''; this space can be a browser window, a tab, or a frame<br />
or iframe within a document. The toplevel data structures within Gecko<br />
represent this browsing context; they contain other data structures<br />
representing the individual pages displayed inside of it (most<br />
importantly, the current one). In terms of implementation, these two<br />
types of navigation, the top level of a browser and the frames within<br />
it, largely use the same data structures.<br />
<br />
In Gecko, the '''docshell''' is the toplevel object responsible for<br />
managing a single browsing context. It, and the associated '''session history''' code, <br />
manage the navigation between pages inside of a<br />
docshell. (Note the difference between session history, which is a<br />
sequence of pages in a single browser session, used for recording information<br />
for back and forward navigation, and global history, which is the<br />
history of pages visited and associated times, regardless of browser<br />
session, used for things like link coloring and address autocompletion.)<br />
<br />
There are relatively few objects in Gecko that are associated with a<br />
docshell rather than being associated with a particular one of the pages<br />
inside of it. Most such objects are attached to the docshell. An important object associated with the docshell is the nsGlobalWindowOuter which is what the HTML5 spec refers to as a WindowProxy (into which Window objects, as implemented by nsGlobalWindowInner, are loaded). See the DOM section below for more information on<br />
this.<br />
<br />
The most toplevel object for managing the contents of a particular page<br />
being displayed within a docshell is a document viewer (see layout).<br />
Other important objects associated with this presentation are the<br />
document (see DOM) and the pres(entation) shell and pres(entation)<br />
context (see layout).<br />
<br />
[[File:WebNavigation.png|thumb|400px|<xul:browser>, frameloader and docshell in single process configuration]]<br />
<br />
Docshells are organized into a tree. If a docshell has a non-null parent, then it corresponds to a subframe in whatever page is currently loaded in the parent docshell, and the corresponding subframe element (for example, an iframe) is called a '''browsing context container'''. In Gecko, a browsing context container would implement <code>[https://dxr.mozilla.org/mozilla-central/rev/f9a5e9ed62103c84e4cde915f4d08f1ce71be83e/dom/base/nsIFrameLoader.idl#271 nsIFrameLoaderOwner]</code> to hold a '''frameloader''', which holds and manages the docshell. <br />
<br />
One of the most interfaces docshell implemented is <code>[https://dxr.mozilla.org/mozilla-central/source/docshell/base/nsIWebNavigation.idl nsIWebNavigation]</code>. It defines major functions of a browsing context, such as <code>loadURI</code> / <code>goBack</code> / <code>goForward</code> and <code>reload</code>. In single process configuration of desktop Firefox, <code><xul:browser></code> (which represents a tab) operates on docshell through <code>nsIWebNavigation</code>, as shown in the right figure.<br />
<br />
* code: mozilla/docshell/<br />
* bugzilla: Core::Document Navigation<br />
* documentation: [[DocShell:Home Page]]<br />
<br />
=== Session History ===<br />
<br />
In order to keep the session history of subframes after the root document is unloaded and docshells of subframes are destroyed, only the root docshell of a docshell tree manages the session history (this does not match the conceptual model in the HTML5 spec and may be subject to change).<br />
<br />
As an example to explain the structure of session history implementation in Gecko, consider there's a tab A, which loads document 1; in document 1, there are iframe B & C, which loads document 2 & 3, respectively. Later, an user navigates iframe B to document 4. The following figures show the conceptual model of the example, and the corresponding session history structure.<br />
<br />
{| <br />
| [[File:BrowsingContextExample1.png|thumb|190px|Conceptual model representation; color denotes current visible active documents]]<br />
| [[File:SHistoryExample1.png|thumb|180px|Session history structure; color denotes current transaction / entries]]<br />
|}<br />
<br />
In Gecko, a [https://dxr.mozilla.org/mozilla-central/source/docshell/shistory/nsSHistory.h session history] object holds a list of [https://dxr.mozilla.org/mozilla-central/source/docshell/shistory/nsSHTransaction.h transactions] (denoted as T1 & T2 in the figure); each transaction points to a tree of [https://dxr.mozilla.org/mozilla-central/source/docshell/shistory/nsSHEntry.h entries]; each entry records the docshell it associated to, and a URL. Now that if we navigate the tab to a different root document 5, which includes an iframe D with document 6, then it becomes:<br />
<br />
{| <br />
| [[File:BrowsingContextExample2.png|thumb|275px|Conceptual model representation]]<br />
| [[File:SHistoryExample2.png|thumb|250px|Session history structure]]<br />
|}<br />
<br />
=== Embedding ===<br />
<br />
To be written (and maybe rewritten if we get an IPC embedding API).<br />
<br />
[[File:WebNavigationE10S.png|thumb|500px|<xul:remote-browser>, frameloader and docshell in multiprocess configuration. The horizontal dash-lines represent inter-process communication]]<br />
<br />
=== Multi-process and IPC ===<br />
<br />
In a multi-process desktop Firefox, a tab is managed by <code>[https://dxr.mozilla.org/mozilla-central/source/toolkit/content/widgets/remote-browser.xml <xul:remote-browser>]</code>. It still operates on nsIWebNavigation, but in this case the docshell is in a remote process and can not be accessed directly. The encapsulation of remote nsIWebNavigation is done by the javascript-implemented <code>[https://dxr.mozilla.org/mozilla-central/source/toolkit/components/remotebrowserutils/RemoteWebNavigation.js RemoteWebNavigation]</code>.<br />
<br />
In this configuration, the frameloader of a root docshell lives in parent process, so it can not access docshell directly either. Instead, it holds a <code>[https://dxr.mozilla.org/mozilla-central/source/dom/ipc/TabParent.h TabParent]</code> instance to interact with <code>[https://dxr.mozilla.org/mozilla-central/source/dom/ipc/TabChild.h TabChild]</code> in child-process. At C/C++ level, the communication across processes for a single tab is through the '''PBrowser''' IPC protocol implemented by TabParent and TabChild, while at the javascript level it's done by '''message manager''' (which is ontop of PBrowser). RemoteWebNavigation, for example, sends messages to <code>[https://dxr.mozilla.org/mozilla-central/source/toolkit/content/browser-child.js browser-child.js]</code> in content process through message manager.<br />
<br />
== Networking ==<br />
<br />
The network library Gecko uses is called Necko. Necko APIs are largely organized around three concepts: '''URI objects''', '''protocol handlers''', and '''channels'''.<br />
<br />
=== Protocol handlers ===<br />
A '''protocol handler''' is an XPCOM service associated with a particular URI scheme or network protocol. Necko includes protocol handlers for HTTP, FTP, the data: URI scheme, and various others. Extensions can implement protocol handlers of their own.<br />
<br />
A protocol handler implements the <code>[https://dxr.mozilla.org/mozilla-central/source/netwerk/base/nsIProtocolHandler.idl nsIProtocolHandler]</code> API, which serves three primary purposes:<br />
# Providing metadata about the protocol (its security characteristics, whether it requires actual network access, what the corresponding URI scheme is, what TCP port the protocol uses by default).<br />
# Creating URI objects for the protocol's scheme.<br />
# Creating channel objects for the protocol's URI objects<br />
<br />
Typically, the built-in I/O service (<code>[https://dxr.mozilla.org/mozilla-central/source/netwerk/base/nsIIOService2.idl nsIIOService]</code>) is responsible for finding the right protocol handler for URI object creation and channel creation, while a variety of consumers queries protocol metadata. Querying protocol metadata is the recommended way to handle any sort of code that needs to have different behavior for different URI schemes. In particular, unlike whitelists or blacklists, it correctly handles the addition of new protocols.<br />
<br />
A service can register itself as a protocol handler by registering for the contract ID <code>"@mozilla.org/network/protocol;1?name=SSSSS"</code> where <code>SSSS</code> is the URI scheme for the protocol (e.g. "http", "ftp", and so forth).<br />
<br />
=== URI objects ===<br />
URI objects, which implement the <code>[https://dxr.mozilla.org/mozilla-central/source/netwerk/base/nsIURI.idl nsIURI]</code> API, are a way of representing URIs and IRIs. Their main advantage over strings is that they do basic syntax checking and canonicalization on the URI string that they're provided with. They also provide various accessors to extract particular parts of the URI and provide URI equality comparisons. URIs that correspond to hierarchical schemes implement the additional <code>[https://dxr.mozilla.org/mozilla-central/source/netwerk/base/nsIURL.idl nsIURL]</code> interface, which exposes even more accessors for breaking out parts of the URI.<br />
<br />
URI objects are typically created by calling the <code>newURI</code> method on the I/O service, or in C++ by calling the <code>NS_NewURI</code> utility function. This makes sure to create the URI object using the right protocol handler, which ensures that the right kind of object is created. Direct creation of URIs via <code>createInstance</code> is reserved for protocol handler implementations.<br />
<br />
=== Channels ===<br />
[https://dxr.mozilla.org/mozilla-central/source/netwerk/base/nsIChannel.idl Channels] are the Necko representation of a single request/response interaction with a server. A channel is created by calling the <code>newChannel</code> method on the [https://dxr.mozilla.org/mozilla-central/source/netwerk/base/nsIIOService.idl I/O service], or in C++ by calling the <code>[https://dxr.mozilla.org/mozilla-central/search?q=function%3ANS_NewChannel&case=true NS_NewChannel]</code> utility function. The channel can then be configured as needed, and finally its <code>asyncOpen</code> method can be called. This method takes an <code>[https://dxr.mozilla.org/mozilla-central/source/netwerk/base/nsIStreamListener.idl nsIStreamListener]</code> as an argument.<br />
<br />
If <code>asyncOpen</code> has returned successfully, the channel guarantees that it will asynchronously call the <code>onStartRequest</code> and <code>onStopRequest</code> methods on its stream listener. This will happen even if there are network errors that prevent Necko from actually performing the requests. Such errors will be reported in the channel's status and in the <code>status</code> argument to <code>onStopRequest</code>.<br />
<br />
If the channel ends up being able to provide data, it will make one or more <code>onDataAvailable</code> on its listener after calling <code>onStartRequest</code> and before calling <code>onStopRequest</code>. For each call, the listener is responsible for either returning an error or reading the entire data stream passed in to the call.<br />
<br />
If an error is returned from either <code>onStartRequest</code> or <code>onDataAvailable</code>, the channel must act as if it has been canceled with the corresponding error code.<br />
<br />
A channel has two URI objects associated with it. The <code>originalURI</code> of the channel is the URI that was originally passed to <code>newChannel</code> to create the channel that then had <code>asyncOpen</code> called on it. The <code>URI</code> is the URI from which the channel is reading data. These can be different in various cases involving protocol handlers that forward network access to other protocol handlers, as well as in situations in which a redirect occurs (e.g. following an HTTP 3xx response). In redirect situations, a new channel object will be created, but the originalURI will be propagated from the old channel to the new channel.<br />
<br />
Note that the <code>nsIRequest</code> that's passed to onStartRequest must match the one passed to onDataAvailable and onStopRequest, but need not be the original channel that asyncOpen was called on. In particular, when an HTTP redirect happens the request argument to the callbacks will be the post-redirect channel.<br />
<br />
TODO: crypto?<br />
<br />
== Document rendering pipeline ==<br />
<br />
Some of the major components of Gecko can be described as steps on the<br />
path from an HTML document coming in from the network to the graphics<br />
commands needed to render that document. An HTML document is a<br />
serialization of a tree structure. (FIXME: add diagram) The HTML<br />
parser and content sink create an in-memory representation of this tree,<br />
which we call the '''DOM tree''' or '''content tree'''.<br />
Many JavaScript APIs operate on the content tree. Then, in<br />
layout, we create a second tree, the '''frame tree''' (or<br />
'''rendering tree''') that is a similar shape to the content tree,<br />
but where each node in the tree represents a rectangle (except in SVG<br />
where they represent other shapes). We then compute the positions of<br />
the nodes in the frame tree (called '''frames''') and paint them<br />
using our cross-platform graphics APIs (which, underneath, map to<br />
platform-specific graphics APIs).<br />
<br />
See [http://dbaron.org/talks/ David Baron's "Fast CSS: How Browsers Lay Out Web Pages" talk] for an overview of the pipeline in a presentation format.<br />
<br />
=== Parser ===<br />
<br />
The parser's job is to transform a character stream into a tree<br />
structure, with the help of the content sink classes.<br />
<br />
HTML is parsed using a parser implementing the parsing algorithm in the<br />
HTML specification (starting with HTML5). Much of this parser is<br />
translated from Java, and changes are made to the Java version. This<br />
parser in parser/html/. The parser is driven by the output of the networking layer (see nsHtml5StreamParser::OnDataAvailable). The HTML5 parser is capable of parsing off the main thread which is the normal case. It also parses on the main thread to be able to synchronously handle things such as innerHTML modifications.<br />
<br />
The codebase still has the previous generation HTML parser, which is<br />
still used for a small number of things, though we hope to be able to<br />
remove it entirely soon. This parser is in parser/htmlparser/.<br />
<br />
XML is parsed using the expat library (parser/expat/) and code that<br />
wraps it (parser/xml/). This is a non-validating parser; however, it<br />
loads certain DTDs to support XUL localization.<br />
<br />
=== DOM / Content ===<br />
<br />
The content tree or DOM tree is the central data structure for Web<br />
pages. It is a tree structure, initially created from the tree<br />
structure expressed in the HTML or XML markup. The nodes in the tree<br />
implement major parts of the DOM (Document Object Model) specifications.<br />
The nodes themselves are part of a class hierarchy rooted at<br />
<code>nsINode</code>; different derived classes are used for things such<br />
as text nodes, the document itself, HTML elements, SVG elements, etc.,<br />
with further subclasses of many of these types (e.g., for specific HTML<br />
elements). Many of the APIs available to script running in Web pages<br />
are associated with these nodes. The tree structure persists while the<br />
Web pages is displayed, since it stores much of state associated with<br />
the Web page. The code for these nodes lives in the content/ directory.<br />
<br />
The DOM APIs are not threadsafe. DOM nodes can be accessed only from<br />
the main thread (also known as the UI thread (user interface thread)) of<br />
the application.<br />
<br />
There are also many other APIs available to Web pages that are not APIs<br />
on the nodes in the DOM tree. Many of these other APIs also live in the<br />
same directories, though some live in content/ and some in dom/. These<br />
include APIs such as the DOM event model.<br />
<br />
The dom/ directory also includes some of the code needed to expose Web<br />
APIs to JavaScript (in other words, the glue code between JavaScript and<br />
these APIs). For an overview, see [https://ask.mozilla.org/question/390/how-is-the-web-exposed-dom-implemented/ DOM API Implementation]. See [[#Scripting|Scripting]] below for details of the JS engine.<br />
<br />
TODO: Internal APIs vs. DOM APIs.<br />
<br />
TODO: Mutation observers / document observers.<br />
<br />
TODO: Reference counting and cycle collection.<br />
<br />
TODO: specification links<br />
<br />
=== Style System ===<br />
<br />
==== Quantum CSS (Stylo) ====<br />
<br />
Starting with Firefox 57 and later, Gecko makes use of the parallel style system written in Rust that comes from Servo. There's an [https://hacks.mozilla.org/2017/08/inside-a-super-fast-css-engine-quantum-css-aka-stylo/ overview] of this with graphics to help explain what's going on. The [https://github.com/servo/servo/wiki/Layout-Overview Servo wiki] has some more details.<br />
<br />
==== Gecko ====<br />
<br />
The rest of the style section section describes the Gecko style system used in Firefox 56 and earlier. Some bits may still apply, but it likely needs revising.<br />
<br />
In order to display the content, Gecko needs to compute the styles<br />
relevant to each DOM node. It does this based on the model described in<br />
the CSS specifications: this model applies to style specified in CSS<br />
(e.g. by a 'style' element, an 'xml-stylesheet' processing instruction<br />
or a 'style' attribute),<br />
style specified by presentation attributes, and the default style<br />
specified by our own user agent style sheets. There are two major<br />
sets of data structures within the style system:<br />
* first, data structures that represent sources of style data, such as CSS style sheets or data from stylistic HTML attributes<br />
* second, data structures that represent computed style for a given DOM node.<br />
These sets of data structures are mostly distinct (for example, they<br />
store values in different ways).<br />
<br />
The loading of CSS style sheets from the network is managed by the <br />
[https://dxr.mozilla.org/mozilla-central/source/layout/style/Loader.h CSS loader]; <br />
they are then tokenized by the <br />
[https://dxr.mozilla.org/mozilla-central/source/layout/style/nsCSSScanner.h CSS scanner] <br />
and parsed by the <br />
[https://dxr.mozilla.org/mozilla-central/source/layout/style/nsCSSParser.h CSS parser]. <br />
Those that are attached to the document also expose APIs to<br />
script that are known as the CSS Object Model, or CSSOM.<br />
<br />
The style sheets that apply to a document are managed by a class called<br />
the [https://dxr.mozilla.org/mozilla-central/source/layout/style/nsStyleSet.h style set].<br />
The style set interacts with the different types of<br />
style sheets (representing CSS style sheets, presentational<br />
attributes, and 'style' attributes) through two interfaces:<br />
[http://dxr.mozilla.org/mozilla-central/source/layout/style/nsIStyleSheet.h nsIStyleSheet] for basic management of style sheets and<br />
[http://dxr.mozilla.org/mozilla-central/source/layout/style/nsIStyleRuleProcessor.h nsIStyleRuleProcessor] for getting the style data out of them. Usually<br />
the same object implements both interfaces, except in the most important<br />
case, CSS style sheets, where there is a single rule processor for all<br />
of the CSS style sheets in each origin (user/UA/author) of the CSS cascade.<br />
<br />
The computed style data for an element/frame are exposed to the rest of<br />
Gecko through the class mozilla::ComputedStyle (previously called<br />
nsStyleContext). Rather than having a member variable for each<br />
CSS property, it breaks up the properties into groups of related<br />
properties called style structs. These style structs obey the rule that<br />
all of the properties in a single struct either inherit by default (what<br />
the CSS specifications call "Inherited: yes" in the definition of<br />
properties; we call these inherited structs) or all are not inherited by<br />
default (we call these reset structs). Separating the properties in<br />
this way improves the ability to share the structs between similar<br />
ComputedStyle objects and reduce the amount of memory needed to store<br />
the style data. The ComputedStyle API exposes a method for getting each<br />
struct, so you'll see code like<br />
<code>sc->GetStyleText()->mTextAlign</code> for getting the value of the<br />
text-align CSS property. (Frames (see the Layout section below) also<br />
have the same<br />
GetStyle* methods, which just forward the call to the frame's<br />
ComputedStyle.)<br />
<br />
The ComputedStyles form a tree structure, in a shape somewhat like the<br />
content tree (except that we coalesce identical sibling ComputedStyles<br />
rather than keeping two of them around; if the parents have been<br />
coalesced then this can apply recursively and coalasce cousins, etc.;<br />
we do not coalesce parent/child ComputedStyles).<br />
The parent of a ComputedStyle has the style data that the ComputedStyle<br />
inherits from when CSS inheritance occurs. This means that the parent<br />
of the ComputedStyle for a DOM element is generally the ComputedStyle<br />
for that DOM element's parent, since that's how CSS says inheritance<br />
works.<br />
<br />
The process of turning the style sheets into computed style data goes<br />
through three main steps, the first two of which closely relate to the<br />
[http://dxr.mozilla.org/mozilla-central/source/layout/style/nsIStyleRule.h nsIStyleRule] interface, which represents an immutable source of style<br />
data, conceptually representing (and for CSS style rules, directly<br />
storing) a set of property:value pairs. (It is similar to the idea of a<br />
CSS style rule, except that it is immutable; this immutability allows<br />
for significant optimization. When a CSS style rule is changed through<br />
script, we create a new style rule.)<br />
<br />
The first step of going from style sheets to computed style data is<br />
finding the ordered sequence of style rules that apply to an element.<br />
The order represents which rules override which other rules: if two<br />
rules have a value for the same property, the higher ranking one wins.<br />
(Note that there's another difference from CSS style rules: declarations<br />
with !important are represented using a separate style rule.) This is<br />
done by calling one of the nsIStyleRuleProcessor::RulesMatching methods.<br />
The ordered sequence is stored in a<br />
[http://en.wikipedia.org/wiki/Trie trie] called the rule tree: the path<br />
from the root of the rule tree to any (leaf or non-leaf) node in the<br />
rule tree represents a sequence of rules, with the highest ranking<br />
farthest from the root. Each rule node (except for the root) has a<br />
pointer to a rule, but since a rule may appear in many sequences, there<br />
are sometimes many rule nodes pointing to the same rule. Once we have<br />
this list we create a ComputedStyle (or find an appropriate existing<br />
sibling) with the correct parent pointer (for inheritance) and rule node<br />
pointer (for the list of rules), and a few other pieces of information<br />
(like the pseudo-element).<br />
<br />
The second step of going from style sheets to computed style data is<br />
getting the winning property:value pairs from the rules. (This only<br />
provides property:value pairs for some of the properties; the remaining<br />
properties will fall back to inheritance or to their initial values<br />
depending on whether the property is inherited by default.) We do this<br />
step (and the third) for each style struct, the first time it is needed.<br />
This is done in nsRuleNode::WalkRuleTree, where we ask each style rule<br />
to fill in its property:value pairs by calling its MapRuleInfoInto<br />
function. When called, the rule fills in only those pairs that haven't<br />
been filled in already, since we're calling from the highest priority<br />
rule to the lowest (since in many cases this allows us to stop before<br />
going through the whole list, or to do partial computation that just<br />
adds to data cached higher in the rule tree).<br />
<br />
The third step of going from style sheets to computed style data (which<br />
various caching optimizations allow us to skip in many cases) is<br />
actually doing the computation; this generally means we transform the<br />
style data into the data type described in the "Computed Value" line in<br />
the property's definition in the CSS specifications. This<br />
transformation happens in functions called nsRuleNode::Compute*Data,<br />
where the * in the middle represents the name of the style struct. This<br />
is where the transformation from the style sheet value storage format to<br />
the computed value storage format happens.<br />
<br />
Once we have the computed style data, we then store it: if a style struct<br />
in the computed style data doesn't<br />
depend on inherited values or on data from other style structs, then we<br />
can cache it in the rule tree (and then reuse it, without recomputing<br />
it, for any ComputedStyles pointing to that rule node). Otherwise, we<br />
store it on the ComputedStyle (in which case it may be shared<br />
with the ComputedStyle's descendant ComputedStyles).<br />
This is where keeping inherited and<br />
non-inherited properties separate is useful: in the common case of<br />
relatively few properties being specified, we can generally cache the<br />
non-inherited structs in the rule tree, and we can generally share the<br />
inherited structs up and down the ComputedStyle tree.<br />
<br />
The ownership models in style sheet structures are a mix of reference<br />
counted structures (for things accessible from script) and directly<br />
owned structures. ComputedStyles are reference counted, and own their<br />
parents (from which they inherit), and rule nodes are garbage collected<br />
with a simple mark and sweep collector (which often never needs to run).<br />
<br />
* code: [http://dxr.mozilla.org/mozilla-central/source/layout/style/ layout/style/], where most files have useful one line descriptions at the top that show up in DXR<br />
* Bugzilla: Style System (CSS)<br />
* specifications<br />
** [http://www.w3.org/TR/CSS21/ CSS 2.1]<br />
** [http://www.w3.org/TR/css-2010/ CSS 2010, listing stable css3 modules]<br />
** [http://dev.w3.org/csswg/ CSS WG editors drafts] (often more current, but sometimes more unstable than the drafts on the technical reports page)<br />
** [http://dbaron.org/mozilla/visited-privacy Preventing attacks on a user's history through CSS :visited selectors]<br />
* documentation<br />
** [http://www-archive.mozilla.org/newlayout/doc/style-system.html style system documentation] (somewhat out of date)<br />
<br />
=== Layout ===<br />
<br />
Much of the layout code deals with operations on the frame tree (or<br />
rendering tree). In the frame tree, each node represents a rectangle<br />
(or, for SVG, other shapes). The frame tree has a shape similar to the<br />
content tree, since many content nodes have one corresponding frame,<br />
though it differs in a few ways, since some content nodes have more than<br />
one frame or don't have any frames at all. When elements are<br />
display:none in CSS or undisplayed for certain other reasons, they won't<br />
have any frames. When elements are broken across lines or pages, they<br />
have multiple frames; elements may also have multiple frames when<br />
multiple frames nested inside each other are needed to display a single<br />
element (for example, a table, a table cell, or many types of form<br />
controls).<br />
<br />
Each node in the frame tree is an instance of a class derived from<br />
<code>nsIFrame</code>. As with the content tree, there is a substantial<br />
type hierarchy, but the type hierarchy is very different: it includes<br />
types like text frames, blocks and inlines, the various parts of tables,<br />
and the various types of HTML form controls.<br />
<br />
Frames are allocated within an arena owned by the pres shell. Each<br />
frame is owned by its parent; frames are not reference counted, and code<br />
must not hold on to pointers to frames. To mitigate potential security<br />
bugs when pointers to destroyed frames, we use<br />
[http://robert.ocallahan.org/2010/10/mitigating-dangling-pointer-bugs-using_15.html frame poisoning], which takes two parts. When a frame is destroyed<br />
other than at the end of life of the presentation, we fill its memory<br />
with a pattern consisting of a repeated pointer to inaccessible memory,<br />
and then put the memory on a per-frame-class freelist. This means that<br />
if code accesses the memory through a dangling pointer, it will either<br />
crash quickly by dereferencing the poison pattern or it will find a<br />
valid frame.<br />
<br />
Like the content tree, frames must be accessed only from the UI thread.<br />
<br />
The frame tree should not store any important data. While it does<br />
usually persist while a page is being displayed, frames are often<br />
destroyed and recreated in response to certain style changes, and in the<br />
future we may do the same to reduce memory use for pages that are<br />
currently inactive. There were a number of cases where this rule was<br />
violated in the past and we stored important data in the frame tree;<br />
however, most (though not quite all) such cases are now fixed.<br />
<br />
The rectangle represented by the frame is what CSS calls the element's<br />
border box. This is the outside edge of the border (or the inside edge<br />
of the margin). The margin lives outside the border; and the padding<br />
lives inside the border. In addition to nsIFrame::GetRect, we also have<br />
the APIs nsIFrame::GetPaddingRect to get the padding box (the outside<br />
edge of the padding, or inside edge of the border) and<br />
nsIFrame::GetContentRect to get the content box (the outside edge of the<br />
content, or inside edge of the padding). These APIs may produce out of<br />
date results when reflow is needed (or has not yet occurred).<br />
<br />
In addition to tracking a rectangle, frames also track two overflow<br />
areas: visual overflow and scrollable overflow. These overflow areas<br />
represent the union of the area needed by the frame and by all its<br />
descendants. The visual overflow is used for painting-related<br />
optimizations: it is a rectangle covering all of the area that might be<br />
painted when the frame and all of its descendants paint. The scrollable<br />
overflow represents the area that the user should be able to scroll to<br />
to see the frame and all of its descendants. In some cases differences<br />
between the frame's rect and its overflow happen because of descendants<br />
that stick out of the frame; in other cases they occur because of some<br />
characteristic of the frame itself. The two overflow areas are<br />
similar, but there are differences: for example, margins are part of<br />
scrollable overflow but not visual overflow, whereas text-shadows are<br />
part of visual overflow but not scrollable overflow.<br />
<br />
When frames are broken across lines, columns, or pages, we create<br />
multiple frames representing the multiple rectangles of the element.<br />
The first one is the primary frame, and the rest are its continuations<br />
(which are more likely to be destroyed and recreated during reflow).<br />
These frames are linked together as continuations: they have a<br />
doubly-linked list that can be used to traverse the continuations using<br />
nsIFrame::GetPrevContinuation and nsIFrame::GetNextContinuation.<br />
(Currently continuations always have the same style data, though we may<br />
at some point want to break that invariant.)<br />
<br />
Continuations are sometimes siblings of each other, and sometimes not.<br />
For example, if a paragraph contains a span which contains a link, and<br />
the link is split across lines, then the continuations of the span are<br />
siblings (since they are both children of the paragraph), but the<br />
continuations of the link are not siblings (since each continuation of<br />
the link is descended from a different continuation of the span).<br />
Traversing the entire frame tree does '''not''' require considering<br />
continuations, since all of the continuations are descendants of the<br />
element containing the break.<br />
<br />
We also use continuations for cases (most importantly, bidi reordering,<br />
where left-to-right text and right-to-left text need to be separated<br />
into different continuations since they may not form a contiguous<br />
rectangle) where the continuations should not be rewrapped during<br />
reflow: we call these continuations fixed rather than fluid.<br />
nsIFrame::GetNextInFlow and nsIFrame::GetPrevInFlow traverse only the<br />
fluid continuations and do not cross fixed continuation boundaries.<br />
<br />
If an inline frame has non-inline children, then we split the original <br />
inline frame into parts. The original inline's children are <br />
distributed into these parts like so- The children of the original <br />
inline are grouped into runs of inline and non-inline and runs of <br />
inline get an inline parent while runs of non-inline get an anonymous <br />
block parent. This is 'ib-splitting' or block-inside-inline-splitting. <br />
This splitting proceeds recursively up the frame tree until all <br />
non-inlines inside inlines are ancestors of a block frame with anonymous <br />
block wrappers in between. This splitting maintains the relative order<br />
between these child frames and the relationship between the parts of a <br />
split inline is maintained using an ib-sibling chain. It is important <br />
to note that any wrappers created during frame construction (such as <br />
for tables) may not be included in the ib-sibling chain depending on <br />
when this wrapper creation takes place. <br />
<br />
TODO: nsBox craziness from https://bugzilla.mozilla.org/show_bug.cgi?id=524925#c64<br />
<br />
TODO: link to documentation of block and inline layout<br />
<br />
TODO: link to documentation of scrollframes<br />
<br />
TODO: link to documentation of XUL frame classes<br />
<br />
Code (note that most files in base and generic have useful one line descriptions at the top that show up in DXR):<br />
* [http://dxr.mozilla.org/mozilla-central/source/layout/base/ layout/base/] contains objects that coordinate everything and a bunch of other miscellaneous things<br />
* [http://dxr.mozilla.org/mozilla-central/source/layout/generic/ layout/generic/] contains the basic frame classes as well as support code for their reflow methods (ReflowInput, ReflowOutput)<br />
* [http://dxr.mozilla.org/mozilla-central/source/layout/forms/ layout/forms/] contains frame classes for HTML form controls<br />
* [http://dxr.mozilla.org/mozilla-central/source/layout/tables/ layout/tables/] contains frame classes for CSS/HTML tables<br />
* [http://dxr.mozilla.org/mozilla-central/source/layout/mathml/ layout/mathml/] contains frame classes for MathML<br />
* [http://dxr.mozilla.org/mozilla-central/source/layout/svg/ layout/svg/] contains frame classes for SVG<br />
* [http://dxr.mozilla.org/mozilla-central/source/layout/xul/ layout/xul/] contains frame classes for the XUL box model and for various XUL widgets<br />
<br />
Bugzilla:<br />
* All of the components whose names begin with "Layout" in the "Core" product<br />
<br />
Further documentation:<br />
* Talk: [https://air.mozilla.org/introduction-to-graphics-layout-architecture/ Introduction to graphics/layout architecture] (Robert O'Callahan, 2014-04-18)<br />
* Talk: [https://air.mozilla.org/bz-layout-and-styles/ Layout and Styles] (Boris Zbarsky, 2014-10-14)<br />
<br />
<br />
==== Frame Construction ====<br />
<br />
Frame construction is the process of creating frames. This is done when styles change in ways that require frames to be created or recreated or when nodes are inserted into the document. The content tree and the frame tree don't have quite the same shape, and the frame construction process does some of the work of creating the right shape for the frame tree. It handles the aspects of creating the right shape that don't depend on layout information. So for example, frame construction handles the work needed to implement [http://www.w3.org/TR/CSS21/tables.html#anonymous-boxes table anonymous objects] but does not handle frames that need to be created when an element is broken across lines or pages.<br />
<br />
The basic unit of frame construction is a run of contiguous children of a single parent element. When asked to construct frames for such a run of children, the frame constructor first determines, based on the siblings and parent of the nodes involved, where in the frame tree the new frames should be inserted. Then the frame constructor walks through the list of content nodes involved and for each one creates a temporary data structure called a '''frame construction item'''. The frame construction item encapsulates various information needed to create the frames for the content node: its style data, some metadata about how one would create a frame for this node based on its namespace, tag name, and styles, and some data about what sort of frame will be created. This list of frame construction items is then analyzed to see whether constructing frames based on it and inserting them at the chosen insertion point will produce a valid frame tree. If it will not, the frame constructor either fixes up the list of frame construction items so that the resulting frame tree would be valid or throws away the list of frame construction items and requests the destruction and re-creation of the frame for the parent element so that it has a chance to create a list of frame construction items that it <em>can</em> fix up.<br />
<br />
Once the frame constructor has a list of frame construction items and an insertion point that would lead to a valid frame tree, it goes ahead and creates frames based on those items. Creation of a non-leaf frame recursively attempts to create frames for the children of that frame's element, so in effect frames are created in a depth-first traversal of the content tree.<br />
<br />
The vast majority of the code in the frame constructor, therefore, falls into one of these categories:<br />
* Code to determine the correct insertion point in the frame tree for new frames.<br />
* Code to create, for a given content node, frame construction items. This involves some searches through static data tables for metadata about the frame to be created.<br />
* Code to analyze the list of frame construction items.<br />
* Code to fix up the list of frame construction items.<br />
* Code to create frames from frame construction items.<br />
<br />
Code: [http://dxr.mozilla.org/mozilla-central/source/layout/base/nsCSSFrameConstructor.h layout/base/nsCSSFrameConstructor.h] and [http://dxr.mozilla.org/mozilla-central/source/layout/base/nsCSSFrameConstructor.cpp layout/base/nsCSSFrameConstructor.cpp]<br />
<br />
==== Reflow ====<br />
<br />
Reflow is the process of computing the positions and sizes of frames. (After all,<br />
frames represent rectangles, and at some point we need to figure out<br />
exactly *what* rectangle.) Reflow is done recursively, with each<br />
frame's Reflow method calling the Reflow methods on that frame's<br />
descendants.<br />
<br />
In many cases, the correct results are defined by CSS specifications<br />
(particularly [http://www.w3.org/TR/CSS21/visudet.html CSS 2.1]). In some cases, the details are not defined by<br />
CSS, though in some (but not all) of those cases we are constrained by<br />
Web compatibility. When the details are defined by CSS, however, the<br />
code to compute the layout is generally structured somewhat differently<br />
from the way it is described in the CSS specifications, since the CSS<br />
specifications are generally written in terms of constraints, whereas<br />
our layout code consists of algorithms optimized for incremental<br />
recomputation.<br />
<br />
The reflow generally starts from the root of the frame tree, though some other<br />
types of frame can act as reflow roots and start a reflow from them.<br />
Reflow roots must obey the invariant that a change inside one of their<br />
descendants never changes their rect or overflow areas (though currently<br />
scrollbars are reflow roots but don't quite obey this invariant).<br />
<br />
In many cases, we want to reflow a part of the frame tree, and we want<br />
this reflow to be efficient. For example, when content is added or<br />
removed from the document tree or when styles change, we want the amount<br />
of work we need to redo to be proportional to the amount of content. We<br />
also want to efficiently handle a series of changes to the same content.<br />
<br />
To do this, we maintain two bits on frames:<br />
[http://dxr.mozilla.org/mozilla-central/search?q=var%3ANS_FRAME_IS_DIRTY&case=true&redirect=true NS_FRAME_IS_DIRTY]<br />
indicates that a frame and all of its descendants require reflow.<br />
[http://dxr.mozilla.org/mozilla-central/search?q=var%3ANS_FRAME_HAS_DIRTY_CHILDREN&case=true&redirect=true NS_FRAME_HAS_DIRTY_CHILDREN]<br />
indicates that a frame has a descendant that<br />
is dirty or has had a descendant removed (i.e., that it has a child that<br />
has NS_FRAME_IS_DIRTY or NS_FRAME_HAS_DIRTY_CHILDREN or it had a child<br />
removed). These bits allow coalescing of multiple updates; this<br />
coalescing is done in nsPresShell, which tracks the set of reflow roots<br />
that require reflow. The bits are set during calls to<br />
nsPresShell::FrameNeedsReflow and are cleared during reflow.<br />
<br />
The layout algorithms used by many of the frame classes are those<br />
specified in CSS, which are based on the traditional document formatting<br />
model, where widths are input and heights are output.<br />
<br />
In some cases, however, widths need to be determined based on the<br />
content. This depends on two ''intrinsic widths'': the minimum<br />
intrinsic width (see [http://dxr.mozilla.org/search?q=type%3AnsIFrame%20function%3AGetMinWidth&tree=mozilla-central nsIFrame::GetMinWidth]) and the preferred intrinsic<br />
width (see [http://dxr.mozilla.org/search?q=type%3AnsIFrame%20function%3AGetPrefWidth&tree=mozilla-central nsIFrame::GetPrefWidth]). The concept of what these widths<br />
represent is best explained by describing what they are on a paragraph<br />
containing only text: in such a paragraph the minimum intrinsic width<br />
is the width of the longest word, and the preferred intrinsic width is<br />
the width of the entire paragraph laid out on one line.<br />
<br />
Intrinsic widths are invalidated separately from the dirty bits<br />
described above. When a caller informs the pres shell that a frame<br />
needs reflow (nsIPresShell::FrameNeedsReflow), it passes one of three<br />
options:<br />
* eResize indicates that no intrinsic widths are dirty<br />
* eTreeChange indicates that intrinsic widths on it and its ancestors are dirty (which happens, for example, if new children are added to it)<br />
* eStyleChange indicates that intrinsic widths on it, its ancestors, and its descendants are dirty (for example, if the font-size changes)<br />
<br />
Reflow is the area where the XUL frame classes (those that inherit from<br />
nsBoxFrame or nsLeafBoxFrame) are most different from the rest. Instead<br />
of using nsIFrame::Reflow, they do their layout computations using<br />
intrinsic size methods called GetMinSize, GetPrefSize, and GetMaxSize<br />
(which report intrinsic sizes in two dimensions) and a final layout<br />
method called Layout. In many cases these methods defer some of the<br />
computation to a separate object called a layout manager.<br />
<br />
When an individual frame's Reflow method is called, most of the input is<br />
provided on an object called ReflowInput and the output is filled<br />
in to an object called ReflowOutput. After reflow, the caller<br />
(usually the parent) is responsible for setting the frame's size based<br />
on the metrics reported. (This can make some computations during reflow<br />
difficult, since the new size is found in either the reflow state or the<br />
metrics, but the frame's size is still the old size. However, it's<br />
useful for invalidating the correct areas that need to be repainted.)<br />
<br />
One major difference worth noting is that in XUL layout, the size of the<br />
child is set prior to its parent calling its Layout method. (Once<br />
invalidation uses display lists and is no longer tangled up in Reflow,<br />
it may be worth switching non-XUL layout to work this way as well.)<br />
<br />
==== Painting ====<br />
<br />
TODO: display lists (and event handling)<br />
<br />
TODO: layers<br />
<br />
==== Pagination ====<br />
<br />
The concepts behind pagination (also known as fragmentation) are a bit complicated, so for now we've split them off into a separate document: [[Gecko:Continuation_Model]]. This code is used for printing, print-preview, and multicolumn frames.<br />
<br />
=== Dynamic change handling along the rendering pipeline ===<br />
<br />
The ability to make changes to the DOM from script is a major feature of the Web platform. Web authors rely on the concept (though there are a few exceptions, such as animations) that changing the DOM from script leads to the same rendering that would have resulted from starting from that DOM tree. They also rely on the performance characteristics of these changes: small changes to the DOM that have small effects should have proportionally small processing time. This means that Gecko needs to efficiently propagate changes from the content tree to style, the frame tree, the geometry of the frame tree, and the screen.<br />
<br />
For many types of changes, however, there is substantial overhead to processing a change, no matter how small. For example, reflow must propagate from the top of the frame tree down to the frames that are dirty, no matter how small the change. One very common way around this is to batch up changes. We batch up changes in lots of ways, for example:<br />
* The content sink adds multiple nodes to the DOM tree before notifying listeners that they've been added. This allows notifying once about an ancestor rather than for each of its descendants, or notifying about a group of descendants all at once, which speeds up the processing of those notifications.<br />
* We batch up nodes that require style reresolution (recomputation of selector matching and processing the resulting style changes). This batching is tree based, so it not only merges multiple notifications on the same element, but also merges a notification on an ancestor with a notification on its descendant (since ''some'' of these notifications imply that style reresolution is required on all descendants).<br />
* We wait to reconstruct frames that require reconstruction (after destroying frames eagerly). This, like the tree-based style reresolution batching, avoids duplication both for same-element notifications and ancestor-descendant notifications, even though it doesn't actually do any tree-based caching.<br />
* We postpone doing reflows until needed. As for style reresolution, this maintains tree-based dirty bits (see the description of NS_FRAME_IS_DIRTY and NS_FRAME_HAS_DIRTY_CHILDREN under Reflow).<br />
* We allow the OS to queue up multiple invalidates before repainting (though we will likely switch to controlling that ourselves). This leads to a single repaint of some set of pixels where there might otherwise have been multiple (though it may also lead to more pixels being repainted if multiple rectangles are merged to a single one).<br />
<br />
Having changes buffered up means, however, that various pieces of information (layout, style, etc.) may not be up-to-date. Some things require up-to-date information: for example, we don't want to expose the details of our buffering to Web page script since the programming model of Web page script assumes that DOM changes take effect "immediately", i.e., that the script shouldn't be able to detect any buffering. Many Web pages depend on this.<br />
<br />
We therefore have ways to flush these different sorts of buffers. There are methods called FlushPendingNotifications on nsIDocument and nsIPresShell, that take an argument of what things to flush:<br />
* Flush_Content: create all the content nodes from data buffered in the parser<br />
* Flush_ContentAndNotify: the above, plus notify document observers about the creation of all nodes created so far<br />
* Flush_Style: the above, plus make sure style data are up-to-date<br />
* Flush_Frames: the above, plus make sure all frame construction has happened (currently the same as Flush_Style)<br />
* Flush_InterruptibleLayout: the above, plus perform layout (Reflow), but allow interrupting layout if it takes too long<br />
* Flush_Layout: the above, plus ensure layout (Reflow) runs to completion<br />
* Flush_Display (should never be used): the above, plus ensure repainting happens<br />
<br />
The major way that notifications of changes propagate from the content code to layout and other areas of code is through the nsIDocumentObserver and nsIMutationObserver interfaces. Classes can implement this interface to listen to notifications of changes for an entire document or for a subtree of the content tree.<br />
<br />
WRITE ME: ... layout document observer implementations<br />
<br />
TODO: how style system optimizes away rerunning selector matching<br />
<br />
TODO: style changes and nsChangeHint<br />
<br />
=== Refresh driver ===<br />
<br />
== Graphics ==<br />
[https://wiki.mozilla.org/Platform/GFX Wiki page] | [https://wiki.mozilla.org/index.php?title=Platform/GFX/Contribute contribute]<br />
<br />
==== Painting/Rasterizing ====<br />
<br />
Painting/rendering/rasterizing is the step where graphical primitives (such as a command to fill an [https://developer.mozilla.org/en-US/docs/Web/SVG SVG] circle, or a [https://developer.mozilla.org/en-US/docs/Web/Guide/Graphics/Drawing_graphics_with_canvas canvas] command to stroke a path between x, y, z, or the internally produced command to draw the edge of an HTML div's border) are used to color in the pixels of a surface so that the surface "displays" those rasterized primitives.<br />
<br />
The platform independent library that gecko uses to render is [http://dxr.mozilla.org/mozilla-central/source/gfx/2d/2D.h Moz2D]. Gecko code paints into Moz2D DrawTarget objects (the DrawTarget baseclass having multiple platform dependent subclasses). (At least this is where gecko is going - for now there is still significant amounts of code that uses [http://dxr.mozilla.org/mozilla-central/source/gfx/thebes/gfxContext.h Thebes gfxContext] objects or the even older nsRenderingContext objects. Objects of these types now always wrap a DrawTarget so all painting does now go through Moz2D, but conversion to use the wrapped DrawTargets directly is taking time since consumer code can sometimes need to be radically rewritten to fit the Moz2D API and immediate mode paradigm.)<br />
<br />
==== Compositing ====<br />
<br />
The compositing stage of the rendering pipeline is operated by the [http://dxr.mozilla.org/mozilla-central/source/gfx/layers/ gfx/layers] module.<br />
<br />
Different parts of a web page can sometimes be painted into intermediate surfaces retained by layers. It can be convenient to think of layers as the layers in image manipulation programs like The Gimp or Photoshop. Layers are organized as a tree. Layers are primarily used to minimize invalidating and repainting when elements are being animated independently of one another in a way that can be optimized using layers (e.g. opacity or transform animations), and to enable some effects (such as transparency and 3D transforms).<br />
<br />
Compositing is the action of flattening the layers into the final image that is shown on the screen.<br />
<br />
On some platform, compositing happens on the Content thread. However, on other platforms we composite on a separate thread (Off-main-thread compositing, or OMTC). OMTC is at the moment the default behavior on mobile platforms, but the goal is to do it on all platforms in the long run.<br />
<br />
The Layers architecture is built on the following notions:<br />
* Compositor: an object that can draw quads on the screen (or on an off-screen render target).<br />
* Texture: an object that contains image data.<br />
* Compositable: an object that can manipulate one or several textures, and knows how to present them to the compositor<br />
* Layer: an element of the layer tree. A layer usually doesn't know much about compositing: it uses a compositable to do the work. Layers are mostly nodes of the layer tree.<br />
<br />
[[File:LayersRefactoring.png|thumb|650px|New layers architecture, with OGL backend]]<br />
<br />
The above abstractions are sufficient to perform compositing on the main thread, but on the OMTC case, we need a mechanism to synchronize a client layer tree that is constructed on the content thread, and a host layer tree that is used for compositing on the compositor thread.<br />
This synchronization process must ensure that the host layer tree reflects the state of the current layer tree while remaining in a consistent state, and must transfer texture data from a thread to the other. Moreover, on some platforms the content and compositor threads may live in separate processes.<br />
<br />
To perform this synchronization, we use the IPDL IPC framework. IPDL lets us describe communications protocols and actors in a domain specific language. for more information about IPDL, read https://wiki.mozilla.org/IPDL<br />
<br />
When the client layer tree is modified, we record modifications into messages that are sent together to the host side within a transaction. A transaction is basically a list of modifications to the layer tree that have to be applied all at once to preserve consistency in the state of the host layer tree.<br />
<br />
Texture transfer is done by synchronizing texture objects across processes/threads using a couple TextureClient/TextureHost that wrap shared data and provide access to it on both sides. TextureHosts provide access to one or several TextureSource, which has the necessary API to actually composite the texture (TextureClient/Host being more about IPC synchronization than actual compositing.<br />
The logic behind texture transfer (as in single/double/triple buffering, texture tiling, etc) is operated by the CompositableClient and CompositableHost.<br />
<br />
It is important to understand the separation between layers and compositables. Compositables handle all the logic around texture transfer, while layers define the shape of the layer tree. a Compositable is created independently from a layer and attached to it on both sides. While layers transactions can only originate from the content thread, this separation makes it possible for us to have separate compositable transactions between any thread and the compositor thread. We use the ImageBridge IPDL protocol to that end. The Idea of ImageBridge is to create a Compositable that is manipulated on the ImageBridgeThread, and that can transfer/synchronize textures without using the content thread at all. This is very useful for smooth Video compositing: video frames are decoded and passed into the ImageBridge without ever touching the content thread, which could be busy processing reflows or heavy javascript workloads.<br />
<br />
It is worth reading the inline code documentation in the following files:<br />
* [http://dxr.mozilla.org/mozilla-central/source/gfx/layers/Compositor.h gfx/layers/Compositor.h]<br />
* [http://dxr.mozilla.org/mozilla-central/source/gfx/layers/ShadowLayers.h gfx/layers/ShadowLayers.h]<br />
* [http://dxr.mozilla.org/mozilla-central/source/gfx/layers/Layers.h gfx/layers/Layers.h]<br />
* [http://dxr.mozilla.org/mozilla-central/source/gfx/layers/host/TextureHost.h gfx/layers/host/TextureHost.h]<br />
* [http://dxr.mozilla.org/mozilla-central/source/gfx/layers/client/CompositableClient.h gfx/layers/client/CompositableClient.h]<br />
<br />
To visualize how a web page is layered, turn on the pref "layers.draw-borders" in about:config. When this pref is on, the borders of layers and tiles are displayed on top of the content. This only works when using the new Compositor API, that is when off-main-thread compositing is activated. OMTC is activated by default on all mobile platforms, and will progressively get activated on desktop platforms (not yet, though). On platforms where OMTC is not used, this pref has no effect. <br />
<br />
Blog posts with information on Layers that should be integrated here:<br />
<br />
* [http://www.basschouten.com/blog1.php/layers-cross-platform-acceleration Layers: Cross-Platform Acceleration]<br />
* [http://robert.ocallahan.org/2010/04/layers_01.html Layers]<br />
* [http://robert.ocallahan.org/2010/07/retained-layers_16.html Retained Layers]<br />
* [http://chrislord.net/index.php/2011/07/25/shadow-layers-and-learning-by-failing/ Shadow Layers, and learning by failing]<br />
* [http://chrislord.net/index.php/2011/08/16/accelerated-layer-rendering-and-learning-by-some-success/ Accelerated layer-rendering, and learning by (some) success]<br />
* [http://featherweightmusings.blogspot.co.uk/2012/05/mask-layers_26.html Mask Layers]<br />
* [http://featherweightmusings.blogspot.co.uk/2012/05/building-mask-layer.html Building a mask layer]<br />
* [http://featherweightmusings.blogspot.co.uk/2012/06/mask-layers-on-direct3d-backends.html Mask Layers on the Direct3D backends]<br />
* [http://robert.ocallahan.org/2011/09/graphics-api-design.html Graphics API Design]<br />
<br />
==== Async Panning and Zooming ====<br />
<br />
On some of our mobile platforms we have some code that allows the user to do asynchronous (i.e. off-main-thread) panning and zooming of content. This code is the Async Pan/Zoom module (APZ) code and is further documented at [[Platform/GFX/APZ]].<br />
<br />
== Scripting ==<br />
<br />
=== JavaScript Engine ===<br />
<br />
Gecko embeds the SpiderMonkey JavaScript engine (located in js/src). The JS engine includes a number of Just-In-Time compilers (or JITs). SpiderMonkey provides a powerful and extensive embedding API (called the JSAPI). Because of its complexity, using the JSAPI directly is frowned upon, and a number of abstractions have been built in Gecko to allow interacting with the JS engine without using JSAPI directly. Some JSAPI concepts are important for Gecko developers to understand, and they are listed below:<br />
<br />
* Global object: The '''global object''' is the object on which all global variables/properties/methods live. In a web page this is the 'window' object. In other things such as XPCOM components or sandboxes XPConnect creates a global object with a small number of builtin APIs.<br />
* Compartments: A '''compartment''' is a subdivision of the JS heap. The mapping from global objects to compartments is one-to-one; that is, every global object has a compartment associated with it, and no compartment is associated with more than one global object. (NB: There are compartments associated with no global object, but they aren't very interesting). When JS code is running SpiderMonkey has a concept of a "current" compartment. New objects that are created will be created in the "current" compartment and associated with the global object of that compartment.<br />
* When objects in one compartment can see objects in another compartment (via e.g. iframe.contentWindow.foo) '''cross-compartment wrappers''' or '''CCWs''' mediate the interaction between the two compartments. By default CCWs ensure that the current compartment is kept up-to-date when execution crosses a compartment boundary. SpiderMonkey also allows embeddings to extend wrappers with custom behavior to implement security policies, which Gecko uses extensively (see the Security section for more information).<br />
<br />
=== XPConnect ===<br />
<br />
'''XPConnect''' is a bridge between C++ and JS used by XPCOM components exposed to or implemented in JavaScript. XPConnect allows two XPCOM components to talk to each other without knowing or caring which language they are implemented in. XPConnect allows JS code to call XPCOM components by exposing XPCOM interfaces as JS objects, and mapping function calls and attributes from JS into virtual method calls on the underlying C++ object. It also allows JS code to implement an XPCOM component that can be called from C++ by faking the vtable of an interface and translating calls on the interface into JS calls. XPConnect accomplishes this using the vtable data stored in XPCOM TypeLibs (or XPT files) by the XPIDL compiler and a small layer of platform specific code called [https://developer.mozilla.org/en-US/docs/xptcall_FAQ xptcall] that knows how to interact with and impersonate vtables of XPCOM interfaces.<br />
<br />
XPConnect is also used for a small (and decreasing) number of legacy DOM objects. At one time all of the DOM used XPConnect to talk to JS, but we have been replacing XPConnect with the WebIDL bindings (see the next section for more information). Arbitrary XPCOM components are not exposed to web content. XPCOM components that want to be accessible to web content must provide class info (that is, they must QI to nsIClassInfo) and must be marked with the nsIClassInfo::DOM_OBJECT flag. Most of these objects also are listed in dom/base/nsDOMClassInfo.cpp, where the interfaces that should be visible to the web are enumerated. This file also houses some "scriptable helpers" (classes ending in "SH" and implementing nsIXPCScriptable), which are a set of optional hooks that can be used by XPConnect objects to implement more exotic behaviors (such as indexed getters or setters, lazily resolved properties, etc). This is all legacy code, and any new DOM code should use the WebIDL bindings.<br />
<br />
=== WebIDL Bindings ===<br />
<br />
The '''WebIDL bindings''' are a separate bridge between C++ and JS that is specifically designed for use by DOM code. We intend to replace all uses of XPConnect to interface with content JavaScript with the WebIDL bindings. [https://developer.mozilla.org/en-US/docs/Mozilla/WebIDL_bindings Extensive documentation] on the WebIDL bindings is available, but the basic idea is that a binding generator takes WebIDL files from web standards and some configuration data provided by us and generates at build time C++ glue code that sits between the JS engine and the DOM object. This setup allows us to produce faster, more specialized code for better performance at the cost of increased codesize.<br />
<br />
The WebIDL bindings also implement all of the behavior specified in WebIDL, making it possible for new additions to the DOM to behave correctly "out of the box". The binding layer also provides C++ abstractions for types that would otherwise require direct JSAPI calls to handle, such as typed arrays. <br />
<br />
=== Security ===<br />
<br />
Gecko's JS security model is based on the concept of compartments. Every compartment has a '''principal''' associated with it that contains security information such as the '''origin''' of the compartment, whether or not it has system privileges, etc. For the following discussion, '''wrappee''' refers to the underlying object being wrapped, '''scope''' refers to the compartment the object is being wrapped for use in, and '''wrapper''' refers to the object created in '''scope''' that allows it to interact with '''wrappee'''. "Chrome" refers to JS that is built in to the browser or part of an extension, which runs with full privileges, and is contrasted with "content", which is web provided script that is subject to security restrictions and the same origin policy.<br />
<br />
* Xray wrappers: Xray wrappers are used when the scope has chrome privileges and the wrappee is the JS reflection of an underlying DOM object. Beyond the usual CCW duties of making sure that content code does not run with chrome privileges, Xray wrappers also ensure that calling methods or accessing attributes on the wrappee has the "expected" effect. For example, a web page could replace the <code>close</code> method on its window with a JS function that does something completely different. (e.g. <code>window.close = function() { alert("This isn't what you wanted!") };</code>). Overwriting methods in this way (or creating entirely new ones) is referred to as '''expando''' properties. Xrays see through expando properties, invoking the original method/getter/setter if the expando overwrites a builtin or seeing undefined in the expando creates a new property. This allows chrome code to call methods on content DOM objects without worrying about how the page has changed the object.<br />
* Waived xray wrappers: The xray behavior is not always desirable. It is possible for chrome to "waive" the xray behavior and see the actual JS object. The wrapper still guarantees that code runs with the correct privileges, but methods/getters/setters may not behave as expected. This is equivalent to the behavior chrome sees when it looks at non-DOM content JS objects.<br />
* For more information, see the [https://developer.mozilla.org/en-US/docs/Mozilla/Gecko/Script_security MDN page]<br />
* bholley's [https://air.mozilla.org/enter-the-compartment/ Enter the Compartment] talk also provides an overview of our compartment architecture.<br />
<br />
== Images ==<br />
<br />
== Plugins ==<br />
<br />
== Platform-specific layers ==<br />
<br />
* widget<br />
* native theme<br />
* files, networking, other low-level things<br />
* Accessibility APIs<br />
* Input. Touch-input stuff is somewhat described at [[Platform/Input/Touch]].<br />
<br />
== Editor ==<br />
<br />
== Base layers ==<br />
<br />
=== NSPR ===<br />
<br />
NSPR is a library for providing cross-platform APIs for various<br />
platform-specific functions. We tend to be trying to use it as little<br />
as possible, although there are a number of areas (particularly some<br />
network-related APIs and threading/locking primitives) where we use it<br />
quite a bit.<br />
<br />
=== XPCOM ===<br />
<br />
XPCOM is a cross-platform modularity library, modeled on Microsoft COM. It<br />
is an object system in which all objects inherit from the <code>nsISupports</code> interface.<br />
<br />
components and services, contract IDs and CIDs<br />
<br />
prior overuse of XPCOM; littering with XPCOM does not produce modularity<br />
<br />
Base headers (part of xpcom/base/) and data structures. See also mfbt.<br />
<br />
Threading<br />
<br />
xptcall, proxies<br />
<br />
reference counting, cycle collection<br />
<br />
Further documentation:<br />
* XPCOM and Internal Strings in Gecko (talk by David Baron, 2014-03-20): [https://air.mozilla.org/xpcom-and-internal-strings-in-gecko/ video], [https://dbaron.org/talks/2014-03-20-xpcom-string-taipei/speaking-notes speaking notes]<br />
<br />
=== String ===<br />
<br />
XPCOM has string classes for representing sequences of characters. Typical C++ string classes have the goals of encapsulating the memory management of buffers and the issues needed to avoid buffer overruns common in traditional C string handling. Mozilla's string classes have these goals, and also the goal of reducing copying of strings.<br />
<br />
(There is a second set of string classes in xpcom/glue for callers outside of libxul; these classes are partially source-compatible but have different (worse) performance characteristics. This discussion does not cover those classes.)<br />
<br />
We have two parallel sets of classes, one for strings with 1-byte units (<code>char</code>, which may be signed or unsigned), and one for strings with 2-byte units (<code>char16_t</code>, always unsigned). The classes are named such that the class for 2-byte characters ends with <code>String</code> and the corresponding class for 1-byte characters ends with <code>CString</code>. 2-byte strings are almost always used to encode [http://en.wikipedia.org/wiki/UTF-16 UTF-16]. 1-byte strings are usually used to encode either [http://en.wikipedia.org/wiki/ASCII ASCII] or [http://en.wikipedia.org/wiki/UTF-8 UTF-8], but are sometimes also used to hold data in some other encoding or just byte sequences.<br />
<br />
The string classes distinguish, as part of the type hierarchy, between strings that must have a null-terminator at the end of their buffer (<code>ns[C]String</code>) and strings that are not required to have a null-terminator (<code>ns[C]Substring</code>). <code>ns[C]Substring</code> is the base of the string classes (since it imposes fewer requirements) and <code>ns[C]String</code> is a class derived from it. Functions taking strings as parameters should generally take one of these four types.<br />
<br />
In order to avoid unnecessary copying of string data (which can have significant performance cost), the string classes support different ownership models. All string classes support the following three ownership models dynamically:<br />
* reference counted, copy-on-write, buffers (the default)<br />
* adopted buffers (a buffer that the string class owns, but is not reference counted, because it came from somewhere else)<br />
* dependent buffers, that is, an underlying buffer that the string class does not own, but that the caller that constructed the string guarantees will outlive the string instance<br />
In addition, there is a special string class, <code>nsAuto[C]String</code>, that ''additionally'' contains an internal 64-unit buffer (intended primarily for use on the stack), leading to a fourth ownership model:<br />
* storage within an auto string's stack buffer<br />
Auto strings will prefer reference counting an existing reference-counted buffer over their stack buffer, but will otherwise use their stack buffer for anything that will fit in it.<br />
<br />
There are a number of additional string classes, particularly <code>nsDependent[C]String</code>, <code>nsDependent[C]Substring</code>, and the <code>NS_LITERAL_[C]STRING</code> macros which construct an <code>nsLiteral[C]String</code> which exist primarily as constructors for the other types. These types are really just convenient notation for constructing an <code>ns[C]S[ubs]tring</code> with a non-default ownership mode; they should not be thought of as different types. (The <code>Substring</code>, <code>StringHead</code>, and <code>StringTail</code> functions are also constructors for dependent [sub]strings.) Non-default ownership modes can also be set up using the <code>Rebind</code> and <code>Adopt</code> methods, although the <code>Rebind</code> methods actually live on the derived types, which is probably a mistake (although moving them up would require some care to avoid making an API that easily allows assigning a non-null-terminated buffer to a string whose static type indicates that it is null-terminated).<br />
<br />
Note that the presence of all of these classes imposes some awkwardness in terms of distinctions being available as both static type distinctions and dynamic type distinctions. In general, the only distinctions that should be made statically are 1-byte vs. 2-byte sequences (<code>CString</code> vs <code>String</code>) and whether the buffer is null-terminated or not (<code>Substring</code> vs <code>String</code>). (Does the code actually do a good job of dynamically enforcing the <code>Substring</code> vs. <code>String</code> restriction?)<br />
<br />
TODO: buffer growth, concatenation optimizations<br />
<br />
TODO: encoding conversion, what's validated and what isn't<br />
<br />
TODO: "string API", nsAString (historical)<br />
<br />
* Code: xpcom/string/<br />
* Bugzilla: Core::String<br />
<br />
Further documentation:<br />
* XPCOM and Internal Strings in Gecko (talk by David Baron, 2014-03-20): [https://air.mozilla.org/xpcom-and-internal-strings-in-gecko/ video], [https://dbaron.org/talks/2014-03-20-xpcom-string-taipei/speaking-notes speaking notes]</div>Dbaronhttps://wiki.mozilla.org/index.php?title=Gecko:Overview&diff=1193203Gecko:Overview2018-05-02T21:24:45Z<p>Dbaron: /* Layout */ link to talks</p>
<hr />
<div>This document attempts to give an overview of the different parts of<br />
Gecko, what they do, and why they do it, say where the code for them is<br />
within the repository, and link to more specific documentation (when<br />
available) covering the details of that code. '''It is not yet complete.''' Maintainers of these<br />
areas of code should correct errors, add information, and add links to<br />
more detailed documentation (since this document is intended to remain<br />
an overview, not complete documentation).<br />
<br />
__TOC__<br />
<br />
== Browsers, Frames, and Document Navigation ==<br />
<br />
=== Docshell ===<br />
<br />
The user of a Web browser can change the page shown in that browser in<br />
many ways: by clicking a link, loading a new URL, using the forward and<br />
back buttons, or other ways. This can happen inside a space we'll call<br />
a '''browsing context'''; this space can be a browser window, a tab, or a frame<br />
or iframe within a document. The toplevel data structures within Gecko<br />
represent this browsing context; they contain other data structures<br />
representing the individual pages displayed inside of it (most<br />
importantly, the current one). In terms of implementation, these two<br />
types of navigation, the top level of a browser and the frames within<br />
it, largely use the same data structures.<br />
<br />
In Gecko, the '''docshell''' is the toplevel object responsible for<br />
managing a single browsing context. It, and the associated '''session history''' code, <br />
manage the navigation between pages inside of a<br />
docshell. (Note the difference between session history, which is a<br />
sequence of pages in a single browser session, used for recording information<br />
for back and forward navigation, and global history, which is the<br />
history of pages visited and associated times, regardless of browser<br />
session, used for things like link coloring and address autocompletion.)<br />
<br />
There are relatively few objects in Gecko that are associated with a<br />
docshell rather than being associated with a particular one of the pages<br />
inside of it. Most such objects are attached to the docshell. An important object associated with the docshell is the nsGlobalWindowOuter which is what the HTML5 spec refers to as a WindowProxy (into which Window objects, as implemented by nsGlobalWindowInner, are loaded). See the DOM section below for more information on<br />
this.<br />
<br />
The most toplevel object for managing the contents of a particular page<br />
being displayed within a docshell is a document viewer (see layout).<br />
Other important objects associated with this presentation are the<br />
document (see DOM) and the pres(entation) shell and pres(entation)<br />
context (see layout).<br />
<br />
[[File:WebNavigation.png|thumb|400px|<xul:browser>, frameloader and docshell in single process configuration]]<br />
<br />
Docshells are organized into a tree. If a docshell has a non-null parent, then it corresponds to a subframe in whatever page is currently loaded in the parent docshell, and the corresponding subframe element (for example, an iframe) is called a '''browsing context container'''. In Gecko, a browsing context container would implement <code>[https://dxr.mozilla.org/mozilla-central/rev/f9a5e9ed62103c84e4cde915f4d08f1ce71be83e/dom/base/nsIFrameLoader.idl#271 nsIFrameLoaderOwner]</code> to hold a '''frameloader''', which holds and manages the docshell. <br />
<br />
One of the most interfaces docshell implemented is <code>[https://dxr.mozilla.org/mozilla-central/source/docshell/base/nsIWebNavigation.idl nsIWebNavigation]</code>. It defines major functions of a browsing context, such as <code>loadURI</code> / <code>goBack</code> / <code>goForward</code> and <code>reload</code>. In single process configuration of desktop Firefox, <code><xul:browser></code> (which represents a tab) operates on docshell through <code>nsIWebNavigation</code>, as shown in the right figure.<br />
<br />
* code: mozilla/docshell/<br />
* bugzilla: Core::Document Navigation<br />
* documentation: [[DocShell:Home Page]]<br />
<br />
=== Session History ===<br />
<br />
In order to keep the session history of subframes after the root document is unloaded and docshells of subframes are destroyed, only the root docshell of a docshell tree manages the session history (this does not match the conceptual model in the HTML5 spec and may be subject to change).<br />
<br />
As an example to explain the structure of session history implementation in Gecko, consider there's a tab A, which loads document 1; in document 1, there are iframe B & C, which loads document 2 & 3, respectively. Later, an user navigates iframe B to document 4. The following figures show the conceptual model of the example, and the corresponding session history structure.<br />
<br />
{| <br />
| [[File:BrowsingContextExample1.png|thumb|190px|Conceptual model representation; color denotes current visible active documents]]<br />
| [[File:SHistoryExample1.png|thumb|180px|Session history structure; color denotes current transaction / entries]]<br />
|}<br />
<br />
In Gecko, a [https://dxr.mozilla.org/mozilla-central/source/docshell/shistory/nsSHistory.h session history] object holds a list of [https://dxr.mozilla.org/mozilla-central/source/docshell/shistory/nsSHTransaction.h transactions] (denoted as T1 & T2 in the figure); each transaction points to a tree of [https://dxr.mozilla.org/mozilla-central/source/docshell/shistory/nsSHEntry.h entries]; each entry records the docshell it associated to, and a URL. Now that if we navigate the tab to a different root document 5, which includes an iframe D with document 6, then it becomes:<br />
<br />
{| <br />
| [[File:BrowsingContextExample2.png|thumb|275px|Conceptual model representation]]<br />
| [[File:SHistoryExample2.png|thumb|250px|Session history structure]]<br />
|}<br />
<br />
=== Embedding ===<br />
<br />
To be written (and maybe rewritten if we get an IPC embedding API).<br />
<br />
[[File:WebNavigationE10S.png|thumb|500px|<xul:remote-browser>, frameloader and docshell in multiprocess configuration. The horizontal dash-lines represent inter-process communication]]<br />
<br />
=== Multi-process and IPC ===<br />
<br />
In a multi-process desktop Firefox, a tab is managed by <code>[https://dxr.mozilla.org/mozilla-central/source/toolkit/content/widgets/remote-browser.xml <xul:remote-browser>]</code>. It still operates on nsIWebNavigation, but in this case the docshell is in a remote process and can not be accessed directly. The encapsulation of remote nsIWebNavigation is done by the javascript-implemented <code>[https://dxr.mozilla.org/mozilla-central/source/toolkit/components/remotebrowserutils/RemoteWebNavigation.js RemoteWebNavigation]</code>.<br />
<br />
In this configuration, the frameloader of a root docshell lives in parent process, so it can not access docshell directly either. Instead, it holds a <code>[https://dxr.mozilla.org/mozilla-central/source/dom/ipc/TabParent.h TabParent]</code> instance to interact with <code>[https://dxr.mozilla.org/mozilla-central/source/dom/ipc/TabChild.h TabChild]</code> in child-process. At C/C++ level, the communication across processes for a single tab is through the '''PBrowser''' IPC protocol implemented by TabParent and TabChild, while at the javascript level it's done by '''message manager''' (which is ontop of PBrowser). RemoteWebNavigation, for example, sends messages to <code>[https://dxr.mozilla.org/mozilla-central/source/toolkit/content/browser-child.js browser-child.js]</code> in content process through message manager.<br />
<br />
== Networking ==<br />
<br />
The network library Gecko uses is called Necko. Necko APIs are largely organized around three concepts: '''URI objects''', '''protocol handlers''', and '''channels'''.<br />
<br />
=== Protocol handlers ===<br />
A '''protocol handler''' is an XPCOM service associated with a particular URI scheme or network protocol. Necko includes protocol handlers for HTTP, FTP, the data: URI scheme, and various others. Extensions can implement protocol handlers of their own.<br />
<br />
A protocol handler implements the <code>[https://dxr.mozilla.org/mozilla-central/source/netwerk/base/nsIProtocolHandler.idl nsIProtocolHandler]</code> API, which serves three primary purposes:<br />
# Providing metadata about the protocol (its security characteristics, whether it requires actual network access, what the corresponding URI scheme is, what TCP port the protocol uses by default).<br />
# Creating URI objects for the protocol's scheme.<br />
# Creating channel objects for the protocol's URI objects<br />
<br />
Typically, the built-in I/O service (<code>[https://dxr.mozilla.org/mozilla-central/source/netwerk/base/nsIIOService2.idl nsIIOService]</code>) is responsible for finding the right protocol handler for URI object creation and channel creation, while a variety of consumers queries protocol metadata. Querying protocol metadata is the recommended way to handle any sort of code that needs to have different behavior for different URI schemes. In particular, unlike whitelists or blacklists, it correctly handles the addition of new protocols.<br />
<br />
A service can register itself as a protocol handler by registering for the contract ID <code>"@mozilla.org/network/protocol;1?name=SSSSS"</code> where <code>SSSS</code> is the URI scheme for the protocol (e.g. "http", "ftp", and so forth).<br />
<br />
=== URI objects ===<br />
URI objects, which implement the <code>[https://dxr.mozilla.org/mozilla-central/source/netwerk/base/nsIURI.idl nsIURI]</code> API, are a way of representing URIs and IRIs. Their main advantage over strings is that they do basic syntax checking and canonicalization on the URI string that they're provided with. They also provide various accessors to extract particular parts of the URI and provide URI equality comparisons. URIs that correspond to hierarchical schemes implement the additional <code>[https://dxr.mozilla.org/mozilla-central/source/netwerk/base/nsIURL.idl nsIURL]</code> interface, which exposes even more accessors for breaking out parts of the URI.<br />
<br />
URI objects are typically created by calling the <code>newURI</code> method on the I/O service, or in C++ by calling the <code>NS_NewURI</code> utility function. This makes sure to create the URI object using the right protocol handler, which ensures that the right kind of object is created. Direct creation of URIs via <code>createInstance</code> is reserved for protocol handler implementations.<br />
<br />
=== Channels ===<br />
[https://dxr.mozilla.org/mozilla-central/source/netwerk/base/nsIChannel.idl Channels] are the Necko representation of a single request/response interaction with a server. A channel is created by calling the <code>newChannel</code> method on the [https://dxr.mozilla.org/mozilla-central/source/netwerk/base/nsIIOService.idl I/O service], or in C++ by calling the <code>[https://dxr.mozilla.org/mozilla-central/search?q=function%3ANS_NewChannel&case=true NS_NewChannel]</code> utility function. The channel can then be configured as needed, and finally its <code>asyncOpen</code> method can be called. This method takes an <code>[https://dxr.mozilla.org/mozilla-central/source/netwerk/base/nsIStreamListener.idl nsIStreamListener]</code> as an argument.<br />
<br />
If <code>asyncOpen</code> has returned successfully, the channel guarantees that it will asynchronously call the <code>onStartRequest</code> and <code>onStopRequest</code> methods on its stream listener. This will happen even if there are network errors that prevent Necko from actually performing the requests. Such errors will be reported in the channel's status and in the <code>status</code> argument to <code>onStopRequest</code>.<br />
<br />
If the channel ends up being able to provide data, it will make one or more <code>onDataAvailable</code> on its listener after calling <code>onStartRequest</code> and before calling <code>onStopRequest</code>. For each call, the listener is responsible for either returning an error or reading the entire data stream passed in to the call.<br />
<br />
If an error is returned from either <code>onStartRequest</code> or <code>onDataAvailable</code>, the channel must act as if it has been canceled with the corresponding error code.<br />
<br />
A channel has two URI objects associated with it. The <code>originalURI</code> of the channel is the URI that was originally passed to <code>newChannel</code> to create the channel that then had <code>asyncOpen</code> called on it. The <code>URI</code> is the URI from which the channel is reading data. These can be different in various cases involving protocol handlers that forward network access to other protocol handlers, as well as in situations in which a redirect occurs (e.g. following an HTTP 3xx response). In redirect situations, a new channel object will be created, but the originalURI will be propagated from the old channel to the new channel.<br />
<br />
Note that the <code>nsIRequest</code> that's passed to onStartRequest must match the one passed to onDataAvailable and onStopRequest, but need not be the original channel that asyncOpen was called on. In particular, when an HTTP redirect happens the request argument to the callbacks will be the post-redirect channel.<br />
<br />
TODO: crypto?<br />
<br />
== Document rendering pipeline ==<br />
<br />
Some of the major components of Gecko can be described as steps on the<br />
path from an HTML document coming in from the network to the graphics<br />
commands needed to render that document. An HTML document is a<br />
serialization of a tree structure. (FIXME: add diagram) The HTML<br />
parser and content sink create an in-memory representation of this tree,<br />
which we call the '''DOM tree''' or '''content tree'''.<br />
Many JavaScript APIs operate on the content tree. Then, in<br />
layout, we create a second tree, the '''frame tree''' (or<br />
'''rendering tree''') that is a similar shape to the content tree,<br />
but where each node in the tree represents a rectangle (except in SVG<br />
where they represent other shapes). We then compute the positions of<br />
the nodes in the frame tree (called '''frames''') and paint them<br />
using our cross-platform graphics APIs (which, underneath, map to<br />
platform-specific graphics APIs).<br />
<br />
See [http://dbaron.org/talks/ David Baron's "Fast CSS: How Browsers Lay Out Web Pages" talk] for an overview of the pipeline in a presentation format.<br />
<br />
=== Parser ===<br />
<br />
The parser's job is to transform a character stream into a tree<br />
structure, with the help of the content sink classes.<br />
<br />
HTML is parsed using a parser implementing the parsing algorithm in the<br />
HTML specification (starting with HTML5). Much of this parser is<br />
translated from Java, and changes are made to the Java version. This<br />
parser in parser/html/. The parser is driven by the output of the networking layer (see nsHtml5StreamParser::OnDataAvailable). The HTML5 parser is capable of parsing off the main thread which is the normal case. It also parses on the main thread to be able to synchronously handle things such as innerHTML modifications.<br />
<br />
The codebase still has the previous generation HTML parser, which is<br />
still used for a small number of things, though we hope to be able to<br />
remove it entirely soon. This parser is in parser/htmlparser/.<br />
<br />
XML is parsed using the expat library (parser/expat/) and code that<br />
wraps it (parser/xml/). This is a non-validating parser; however, it<br />
loads certain DTDs to support XUL localization.<br />
<br />
=== DOM / Content ===<br />
<br />
The content tree or DOM tree is the central data structure for Web<br />
pages. It is a tree structure, initially created from the tree<br />
structure expressed in the HTML or XML markup. The nodes in the tree<br />
implement major parts of the DOM (Document Object Model) specifications.<br />
The nodes themselves are part of a class hierarchy rooted at<br />
<code>nsINode</code>; different derived classes are used for things such<br />
as text nodes, the document itself, HTML elements, SVG elements, etc.,<br />
with further subclasses of many of these types (e.g., for specific HTML<br />
elements). Many of the APIs available to script running in Web pages<br />
are associated with these nodes. The tree structure persists while the<br />
Web pages is displayed, since it stores much of state associated with<br />
the Web page. The code for these nodes lives in the content/ directory.<br />
<br />
The DOM APIs are not threadsafe. DOM nodes can be accessed only from<br />
the main thread (also known as the UI thread (user interface thread)) of<br />
the application.<br />
<br />
There are also many other APIs available to Web pages that are not APIs<br />
on the nodes in the DOM tree. Many of these other APIs also live in the<br />
same directories, though some live in content/ and some in dom/. These<br />
include APIs such as the DOM event model.<br />
<br />
The dom/ directory also includes some of the code needed to expose Web<br />
APIs to JavaScript (in other words, the glue code between JavaScript and<br />
these APIs). For an overview, see [https://ask.mozilla.org/question/390/how-is-the-web-exposed-dom-implemented/ DOM API Implementation]. See [[#Scripting|Scripting]] below for details of the JS engine.<br />
<br />
TODO: Internal APIs vs. DOM APIs.<br />
<br />
TODO: Mutation observers / document observers.<br />
<br />
TODO: Reference counting and cycle collection.<br />
<br />
TODO: specification links<br />
<br />
=== Style System ===<br />
<br />
==== Quantum CSS (Stylo) ====<br />
<br />
Starting with Firefox 57 and later, Gecko makes use of the parallel style system written in Rust that comes from Servo. There's an [https://hacks.mozilla.org/2017/08/inside-a-super-fast-css-engine-quantum-css-aka-stylo/ overview] of this with graphics to help explain what's going on. The [https://github.com/servo/servo/wiki/Layout-Overview Servo wiki] has some more details.<br />
<br />
==== Gecko ====<br />
<br />
The rest of the style section section describes the Gecko style system used in Firefox 56 and earlier. Some bits may still apply, but it likely needs revising.<br />
<br />
In order to display the content, Gecko needs to compute the styles<br />
relevant to each DOM node. It does this based on the model described in<br />
the CSS specifications: this model applies to style specified in CSS<br />
(e.g. by a 'style' element, an 'xml-stylesheet' processing instruction<br />
or a 'style' attribute),<br />
style specified by presentation attributes, and the default style<br />
specified by our own user agent style sheets. There are two major<br />
sets of data structures within the style system:<br />
* first, data structures that represent sources of style data, such as CSS style sheets or data from stylistic HTML attributes<br />
* second, data structures that represent computed style for a given DOM node.<br />
These sets of data structures are mostly distinct (for example, they<br />
store values in different ways).<br />
<br />
The loading of CSS style sheets from the network is managed by the <br />
[https://dxr.mozilla.org/mozilla-central/source/layout/style/Loader.h CSS loader]; <br />
they are then tokenized by the <br />
[https://dxr.mozilla.org/mozilla-central/source/layout/style/nsCSSScanner.h CSS scanner] <br />
and parsed by the <br />
[https://dxr.mozilla.org/mozilla-central/source/layout/style/nsCSSParser.h CSS parser]. <br />
Those that are attached to the document also expose APIs to<br />
script that are known as the CSS Object Model, or CSSOM.<br />
<br />
The style sheets that apply to a document are managed by a class called<br />
the [https://dxr.mozilla.org/mozilla-central/source/layout/style/nsStyleSet.h style set].<br />
The style set interacts with the different types of<br />
style sheets (representing CSS style sheets, presentational<br />
attributes, and 'style' attributes) through two interfaces:<br />
[http://dxr.mozilla.org/mozilla-central/source/layout/style/nsIStyleSheet.h nsIStyleSheet] for basic management of style sheets and<br />
[http://dxr.mozilla.org/mozilla-central/source/layout/style/nsIStyleRuleProcessor.h nsIStyleRuleProcessor] for getting the style data out of them. Usually<br />
the same object implements both interfaces, except in the most important<br />
case, CSS style sheets, where there is a single rule processor for all<br />
of the CSS style sheets in each origin (user/UA/author) of the CSS cascade.<br />
<br />
The computed style data for an element/frame are exposed to the rest of<br />
Gecko through the class mozilla::ComputedStyle (previously called<br />
nsStyleContext). Rather than having a member variable for each<br />
CSS property, it breaks up the properties into groups of related<br />
properties called style structs. These style structs obey the rule that<br />
all of the properties in a single struct either inherit by default (what<br />
the CSS specifications call "Inherited: yes" in the definition of<br />
properties; we call these inherited structs) or all are not inherited by<br />
default (we call these reset structs). Separating the properties in<br />
this way improves the ability to share the structs between similar<br />
ComputedStyle objects and reduce the amount of memory needed to store<br />
the style data. The ComputedStyle API exposes a method for getting each<br />
struct, so you'll see code like<br />
<code>sc->GetStyleText()->mTextAlign</code> for getting the value of the<br />
text-align CSS property. (Frames (see the Layout section below) also<br />
have the same<br />
GetStyle* methods, which just forward the call to the frame's<br />
ComputedStyle.)<br />
<br />
The ComputedStyles form a tree structure, in a shape somewhat like the<br />
content tree (except that we coalesce identical sibling ComputedStyles<br />
rather than keeping two of them around; if the parents have been<br />
coalesced then this can apply recursively and coalasce cousins, etc.;<br />
we do not coalesce parent/child ComputedStyles).<br />
The parent of a ComputedStyle has the style data that the ComputedStyle<br />
inherits from when CSS inheritance occurs. This means that the parent<br />
of the ComputedStyle for a DOM element is generally the ComputedStyle<br />
for that DOM element's parent, since that's how CSS says inheritance<br />
works.<br />
<br />
The process of turning the style sheets into computed style data goes<br />
through three main steps, the first two of which closely relate to the<br />
[http://dxr.mozilla.org/mozilla-central/source/layout/style/nsIStyleRule.h nsIStyleRule] interface, which represents an immutable source of style<br />
data, conceptually representing (and for CSS style rules, directly<br />
storing) a set of property:value pairs. (It is similar to the idea of a<br />
CSS style rule, except that it is immutable; this immutability allows<br />
for significant optimization. When a CSS style rule is changed through<br />
script, we create a new style rule.)<br />
<br />
The first step of going from style sheets to computed style data is<br />
finding the ordered sequence of style rules that apply to an element.<br />
The order represents which rules override which other rules: if two<br />
rules have a value for the same property, the higher ranking one wins.<br />
(Note that there's another difference from CSS style rules: declarations<br />
with !important are represented using a separate style rule.) This is<br />
done by calling one of the nsIStyleRuleProcessor::RulesMatching methods.<br />
The ordered sequence is stored in a<br />
[http://en.wikipedia.org/wiki/Trie trie] called the rule tree: the path<br />
from the root of the rule tree to any (leaf or non-leaf) node in the<br />
rule tree represents a sequence of rules, with the highest ranking<br />
farthest from the root. Each rule node (except for the root) has a<br />
pointer to a rule, but since a rule may appear in many sequences, there<br />
are sometimes many rule nodes pointing to the same rule. Once we have<br />
this list we create a ComputedStyle (or find an appropriate existing<br />
sibling) with the correct parent pointer (for inheritance) and rule node<br />
pointer (for the list of rules), and a few other pieces of information<br />
(like the pseudo-element).<br />
<br />
The second step of going from style sheets to computed style data is<br />
getting the winning property:value pairs from the rules. (This only<br />
provides property:value pairs for some of the properties; the remaining<br />
properties will fall back to inheritance or to their initial values<br />
depending on whether the property is inherited by default.) We do this<br />
step (and the third) for each style struct, the first time it is needed.<br />
This is done in nsRuleNode::WalkRuleTree, where we ask each style rule<br />
to fill in its property:value pairs by calling its MapRuleInfoInto<br />
function. When called, the rule fills in only those pairs that haven't<br />
been filled in already, since we're calling from the highest priority<br />
rule to the lowest (since in many cases this allows us to stop before<br />
going through the whole list, or to do partial computation that just<br />
adds to data cached higher in the rule tree).<br />
<br />
The third step of going from style sheets to computed style data (which<br />
various caching optimizations allow us to skip in many cases) is<br />
actually doing the computation; this generally means we transform the<br />
style data into the data type described in the "Computed Value" line in<br />
the property's definition in the CSS specifications. This<br />
transformation happens in functions called nsRuleNode::Compute*Data,<br />
where the * in the middle represents the name of the style struct. This<br />
is where the transformation from the style sheet value storage format to<br />
the computed value storage format happens.<br />
<br />
Once we have the computed style data, we then store it: if a style struct<br />
in the computed style data doesn't<br />
depend on inherited values or on data from other style structs, then we<br />
can cache it in the rule tree (and then reuse it, without recomputing<br />
it, for any ComputedStyles pointing to that rule node). Otherwise, we<br />
store it on the ComputedStyle (in which case it may be shared<br />
with the ComputedStyle's descendant ComputedStyles).<br />
This is where keeping inherited and<br />
non-inherited properties separate is useful: in the common case of<br />
relatively few properties being specified, we can generally cache the<br />
non-inherited structs in the rule tree, and we can generally share the<br />
inherited structs up and down the ComputedStyle tree.<br />
<br />
The ownership models in style sheet structures are a mix of reference<br />
counted structures (for things accessible from script) and directly<br />
owned structures. ComputedStyles are reference counted, and own their<br />
parents (from which they inherit), and rule nodes are garbage collected<br />
with a simple mark and sweep collector (which often never needs to run).<br />
<br />
* code: [http://dxr.mozilla.org/mozilla-central/source/layout/style/ layout/style/], where most files have useful one line descriptions at the top that show up in DXR<br />
* Bugzilla: Style System (CSS)<br />
* specifications<br />
** [http://www.w3.org/TR/CSS21/ CSS 2.1]<br />
** [http://www.w3.org/TR/css-2010/ CSS 2010, listing stable css3 modules]<br />
** [http://dev.w3.org/csswg/ CSS WG editors drafts] (often more current, but sometimes more unstable than the drafts on the technical reports page)<br />
** [http://dbaron.org/mozilla/visited-privacy Preventing attacks on a user's history through CSS :visited selectors]<br />
* documentation<br />
** [http://www-archive.mozilla.org/newlayout/doc/style-system.html style system documentation] (somewhat out of date)<br />
<br />
=== Layout ===<br />
<br />
Much of the layout code deals with operations on the frame tree (or<br />
rendering tree). In the frame tree, each node represents a rectangle<br />
(or, for SVG, other shapes). The frame tree has a shape similar to the<br />
content tree, since many content nodes have one corresponding frame,<br />
though it differs in a few ways, since some content nodes have more than<br />
one frame or don't have any frames at all. When elements are<br />
display:none in CSS or undisplayed for certain other reasons, they won't<br />
have any frames. When elements are broken across lines or pages, they<br />
have multiple frames; elements may also have multiple frames when<br />
multiple frames nested inside each other are needed to display a single<br />
element (for example, a table, a table cell, or many types of form<br />
controls).<br />
<br />
Each node in the frame tree is an instance of a class derived from<br />
<code>nsIFrame</code>. As with the content tree, there is a substantial<br />
type hierarchy, but the type hierarchy is very different: it includes<br />
types like text frames, blocks and inlines, the various parts of tables,<br />
and the various types of HTML form controls.<br />
<br />
Frames are allocated within an arena owned by the pres shell. Each<br />
frame is owned by its parent; frames are not reference counted, and code<br />
must not hold on to pointers to frames. To mitigate potential security<br />
bugs when pointers to destroyed frames, we use<br />
[http://robert.ocallahan.org/2010/10/mitigating-dangling-pointer-bugs-using_15.html frame poisoning], which takes two parts. When a frame is destroyed<br />
other than at the end of life of the presentation, we fill its memory<br />
with a pattern consisting of a repeated pointer to inaccessible memory,<br />
and then put the memory on a per-frame-class freelist. This means that<br />
if code accesses the memory through a dangling pointer, it will either<br />
crash quickly by dereferencing the poison pattern or it will find a<br />
valid frame.<br />
<br />
Like the content tree, frames must be accessed only from the UI thread.<br />
<br />
The frame tree should not store any important data. While it does<br />
usually persist while a page is being displayed, frames are often<br />
destroyed and recreated in response to certain style changes, and in the<br />
future we may do the same to reduce memory use for pages that are<br />
currently inactive. There were a number of cases where this rule was<br />
violated in the past and we stored important data in the frame tree;<br />
however, most (though not quite all) such cases are now fixed.<br />
<br />
The rectangle represented by the frame is what CSS calls the element's<br />
border box. This is the outside edge of the border (or the inside edge<br />
of the margin). The margin lives outside the border; and the padding<br />
lives inside the border. In addition to nsIFrame::GetRect, we also have<br />
the APIs nsIFrame::GetPaddingRect to get the padding box (the outside<br />
edge of the padding, or inside edge of the border) and<br />
nsIFrame::GetContentRect to get the content box (the outside edge of the<br />
content, or inside edge of the padding). These APIs may produce out of<br />
date results when reflow is needed (or has not yet occurred).<br />
<br />
In addition to tracking a rectangle, frames also track two overflow<br />
areas: visual overflow and scrollable overflow. These overflow areas<br />
represent the union of the area needed by the frame and by all its<br />
descendants. The visual overflow is used for painting-related<br />
optimizations: it is a rectangle covering all of the area that might be<br />
painted when the frame and all of its descendants paint. The scrollable<br />
overflow represents the area that the user should be able to scroll to<br />
to see the frame and all of its descendants. In some cases differences<br />
between the frame's rect and its overflow happen because of descendants<br />
that stick out of the frame; in other cases they occur because of some<br />
characteristic of the frame itself. The two overflow areas are<br />
similar, but there are differences: for example, margins are part of<br />
scrollable overflow but not visual overflow, whereas text-shadows are<br />
part of visual overflow but not scrollable overflow.<br />
<br />
When frames are broken across lines, columns, or pages, we create<br />
multiple frames representing the multiple rectangles of the element.<br />
The first one is the primary frame, and the rest are its continuations<br />
(which are more likely to be destroyed and recreated during reflow).<br />
These frames are linked together as continuations: they have a<br />
doubly-linked list that can be used to traverse the continuations using<br />
nsIFrame::GetPrevContinuation and nsIFrame::GetNextContinuation.<br />
(Currently continuations always have the same style data, though we may<br />
at some point want to break that invariant.)<br />
<br />
Continuations are sometimes siblings of each other, and sometimes not.<br />
For example, if a paragraph contains a span which contains a link, and<br />
the link is split across lines, then the continuations of the span are<br />
siblings (since they are both children of the paragraph), but the<br />
continuations of the link are not siblings (since each continuation of<br />
the link is descended from a different continuation of the span).<br />
Traversing the entire frame tree does '''not''' require considering<br />
continuations, since all of the continuations are descendants of the<br />
element containing the break.<br />
<br />
We also use continuations for cases (most importantly, bidi reordering,<br />
where left-to-right text and right-to-left text need to be separated<br />
into different continuations since they may not form a contiguous<br />
rectangle) where the continuations should not be rewrapped during<br />
reflow: we call these continuations fixed rather than fluid.<br />
nsIFrame::GetNextInFlow and nsIFrame::GetPrevInFlow traverse only the<br />
fluid continuations and do not cross fixed continuation boundaries.<br />
<br />
If an inline frame has non-inline children, then we split the original <br />
inline frame into parts. The original inline's children are <br />
distributed into these parts like so- The children of the original <br />
inline are grouped into runs of inline and non-inline and runs of <br />
inline get an inline parent while runs of non-inline get an anonymous <br />
block parent. This is 'ib-splitting' or block-inside-inline-splitting. <br />
This splitting proceeds recursively up the frame tree until all <br />
non-inlines inside inlines are ancestors of a block frame with anonymous <br />
block wrappers in between. This splitting maintains the relative order<br />
between these child frames and the relationship between the parts of a <br />
split inline is maintained using an ib-sibling chain. It is important <br />
to note that any wrappers created during frame construction (such as <br />
for tables) may not be included in the ib-sibling chain depending on <br />
when this wrapper creation takes place. <br />
<br />
TODO: nsBox craziness from https://bugzilla.mozilla.org/show_bug.cgi?id=524925#c64<br />
<br />
TODO: link to documentation of block and inline layout<br />
<br />
TODO: link to documentation of scrollframes<br />
<br />
TODO: link to documentation of XUL frame classes<br />
<br />
Code (note that most files in base and generic have useful one line descriptions at the top that show up in DXR):<br />
* [http://dxr.mozilla.org/mozilla-central/source/layout/base/ layout/base/] contains objects that coordinate everything and a bunch of other miscellaneous things<br />
* [http://dxr.mozilla.org/mozilla-central/source/layout/generic/ layout/generic/] contains the basic frame classes as well as support code for their reflow methods (ReflowInput, ReflowOutput)<br />
* [http://dxr.mozilla.org/mozilla-central/source/layout/forms/ layout/forms/] contains frame classes for HTML form controls<br />
* [http://dxr.mozilla.org/mozilla-central/source/layout/tables/ layout/tables/] contains frame classes for CSS/HTML tables<br />
* [http://dxr.mozilla.org/mozilla-central/source/layout/mathml/ layout/mathml/] contains frame classes for MathML<br />
* [http://dxr.mozilla.org/mozilla-central/source/layout/svg/ layout/svg/] contains frame classes for SVG<br />
* [http://dxr.mozilla.org/mozilla-central/source/layout/xul/ layout/xul/] contains frame classes for the XUL box model and for various XUL widgets<br />
<br />
Bugzilla:<br />
* All of the components whose names begin with "Layout" in the "Core" product<br />
<br />
Further documentation:<br />
* Talk: [https://air.mozilla.org/introduction-to-graphics-layout-architecture/ Introduction to graphics/layout architecture] (Robert O'Callahan, 2014-04-18)<br />
* Talk: [https://air.mozilla.org/bz-layout-and-styles/ Layout and Styles) (Boris Zbarsky, 2014-10-14<br />
<br />
<br />
==== Frame Construction ====<br />
<br />
Frame construction is the process of creating frames. This is done when styles change in ways that require frames to be created or recreated or when nodes are inserted into the document. The content tree and the frame tree don't have quite the same shape, and the frame construction process does some of the work of creating the right shape for the frame tree. It handles the aspects of creating the right shape that don't depend on layout information. So for example, frame construction handles the work needed to implement [http://www.w3.org/TR/CSS21/tables.html#anonymous-boxes table anonymous objects] but does not handle frames that need to be created when an element is broken across lines or pages.<br />
<br />
The basic unit of frame construction is a run of contiguous children of a single parent element. When asked to construct frames for such a run of children, the frame constructor first determines, based on the siblings and parent of the nodes involved, where in the frame tree the new frames should be inserted. Then the frame constructor walks through the list of content nodes involved and for each one creates a temporary data structure called a '''frame construction item'''. The frame construction item encapsulates various information needed to create the frames for the content node: its style data, some metadata about how one would create a frame for this node based on its namespace, tag name, and styles, and some data about what sort of frame will be created. This list of frame construction items is then analyzed to see whether constructing frames based on it and inserting them at the chosen insertion point will produce a valid frame tree. If it will not, the frame constructor either fixes up the list of frame construction items so that the resulting frame tree would be valid or throws away the list of frame construction items and requests the destruction and re-creation of the frame for the parent element so that it has a chance to create a list of frame construction items that it <em>can</em> fix up.<br />
<br />
Once the frame constructor has a list of frame construction items and an insertion point that would lead to a valid frame tree, it goes ahead and creates frames based on those items. Creation of a non-leaf frame recursively attempts to create frames for the children of that frame's element, so in effect frames are created in a depth-first traversal of the content tree.<br />
<br />
The vast majority of the code in the frame constructor, therefore, falls into one of these categories:<br />
* Code to determine the correct insertion point in the frame tree for new frames.<br />
* Code to create, for a given content node, frame construction items. This involves some searches through static data tables for metadata about the frame to be created.<br />
* Code to analyze the list of frame construction items.<br />
* Code to fix up the list of frame construction items.<br />
* Code to create frames from frame construction items.<br />
<br />
Code: [http://dxr.mozilla.org/mozilla-central/source/layout/base/nsCSSFrameConstructor.h layout/base/nsCSSFrameConstructor.h] and [http://dxr.mozilla.org/mozilla-central/source/layout/base/nsCSSFrameConstructor.cpp layout/base/nsCSSFrameConstructor.cpp]<br />
<br />
==== Reflow ====<br />
<br />
Reflow is the process of computing the positions and sizes of frames. (After all,<br />
frames represent rectangles, and at some point we need to figure out<br />
exactly *what* rectangle.) Reflow is done recursively, with each<br />
frame's Reflow method calling the Reflow methods on that frame's<br />
descendants.<br />
<br />
In many cases, the correct results are defined by CSS specifications<br />
(particularly [http://www.w3.org/TR/CSS21/visudet.html CSS 2.1]). In some cases, the details are not defined by<br />
CSS, though in some (but not all) of those cases we are constrained by<br />
Web compatibility. When the details are defined by CSS, however, the<br />
code to compute the layout is generally structured somewhat differently<br />
from the way it is described in the CSS specifications, since the CSS<br />
specifications are generally written in terms of constraints, whereas<br />
our layout code consists of algorithms optimized for incremental<br />
recomputation.<br />
<br />
The reflow generally starts from the root of the frame tree, though some other<br />
types of frame can act as reflow roots and start a reflow from them.<br />
Reflow roots must obey the invariant that a change inside one of their<br />
descendants never changes their rect or overflow areas (though currently<br />
scrollbars are reflow roots but don't quite obey this invariant).<br />
<br />
In many cases, we want to reflow a part of the frame tree, and we want<br />
this reflow to be efficient. For example, when content is added or<br />
removed from the document tree or when styles change, we want the amount<br />
of work we need to redo to be proportional to the amount of content. We<br />
also want to efficiently handle a series of changes to the same content.<br />
<br />
To do this, we maintain two bits on frames:<br />
[http://dxr.mozilla.org/mozilla-central/search?q=var%3ANS_FRAME_IS_DIRTY&case=true&redirect=true NS_FRAME_IS_DIRTY]<br />
indicates that a frame and all of its descendants require reflow.<br />
[http://dxr.mozilla.org/mozilla-central/search?q=var%3ANS_FRAME_HAS_DIRTY_CHILDREN&case=true&redirect=true NS_FRAME_HAS_DIRTY_CHILDREN]<br />
indicates that a frame has a descendant that<br />
is dirty or has had a descendant removed (i.e., that it has a child that<br />
has NS_FRAME_IS_DIRTY or NS_FRAME_HAS_DIRTY_CHILDREN or it had a child<br />
removed). These bits allow coalescing of multiple updates; this<br />
coalescing is done in nsPresShell, which tracks the set of reflow roots<br />
that require reflow. The bits are set during calls to<br />
nsPresShell::FrameNeedsReflow and are cleared during reflow.<br />
<br />
The layout algorithms used by many of the frame classes are those<br />
specified in CSS, which are based on the traditional document formatting<br />
model, where widths are input and heights are output.<br />
<br />
In some cases, however, widths need to be determined based on the<br />
content. This depends on two ''intrinsic widths'': the minimum<br />
intrinsic width (see [http://dxr.mozilla.org/search?q=type%3AnsIFrame%20function%3AGetMinWidth&tree=mozilla-central nsIFrame::GetMinWidth]) and the preferred intrinsic<br />
width (see [http://dxr.mozilla.org/search?q=type%3AnsIFrame%20function%3AGetPrefWidth&tree=mozilla-central nsIFrame::GetPrefWidth]). The concept of what these widths<br />
represent is best explained by describing what they are on a paragraph<br />
containing only text: in such a paragraph the minimum intrinsic width<br />
is the width of the longest word, and the preferred intrinsic width is<br />
the width of the entire paragraph laid out on one line.<br />
<br />
Intrinsic widths are invalidated separately from the dirty bits<br />
described above. When a caller informs the pres shell that a frame<br />
needs reflow (nsIPresShell::FrameNeedsReflow), it passes one of three<br />
options:<br />
* eResize indicates that no intrinsic widths are dirty<br />
* eTreeChange indicates that intrinsic widths on it and its ancestors are dirty (which happens, for example, if new children are added to it)<br />
* eStyleChange indicates that intrinsic widths on it, its ancestors, and its descendants are dirty (for example, if the font-size changes)<br />
<br />
Reflow is the area where the XUL frame classes (those that inherit from<br />
nsBoxFrame or nsLeafBoxFrame) are most different from the rest. Instead<br />
of using nsIFrame::Reflow, they do their layout computations using<br />
intrinsic size methods called GetMinSize, GetPrefSize, and GetMaxSize<br />
(which report intrinsic sizes in two dimensions) and a final layout<br />
method called Layout. In many cases these methods defer some of the<br />
computation to a separate object called a layout manager.<br />
<br />
When an individual frame's Reflow method is called, most of the input is<br />
provided on an object called ReflowInput and the output is filled<br />
in to an object called ReflowOutput. After reflow, the caller<br />
(usually the parent) is responsible for setting the frame's size based<br />
on the metrics reported. (This can make some computations during reflow<br />
difficult, since the new size is found in either the reflow state or the<br />
metrics, but the frame's size is still the old size. However, it's<br />
useful for invalidating the correct areas that need to be repainted.)<br />
<br />
One major difference worth noting is that in XUL layout, the size of the<br />
child is set prior to its parent calling its Layout method. (Once<br />
invalidation uses display lists and is no longer tangled up in Reflow,<br />
it may be worth switching non-XUL layout to work this way as well.)<br />
<br />
==== Painting ====<br />
<br />
TODO: display lists (and event handling)<br />
<br />
TODO: layers<br />
<br />
==== Pagination ====<br />
<br />
The concepts behind pagination (also known as fragmentation) are a bit complicated, so for now we've split them off into a separate document: [[Gecko:Continuation_Model]]. This code is used for printing, print-preview, and multicolumn frames.<br />
<br />
=== Dynamic change handling along the rendering pipeline ===<br />
<br />
The ability to make changes to the DOM from script is a major feature of the Web platform. Web authors rely on the concept (though there are a few exceptions, such as animations) that changing the DOM from script leads to the same rendering that would have resulted from starting from that DOM tree. They also rely on the performance characteristics of these changes: small changes to the DOM that have small effects should have proportionally small processing time. This means that Gecko needs to efficiently propagate changes from the content tree to style, the frame tree, the geometry of the frame tree, and the screen.<br />
<br />
For many types of changes, however, there is substantial overhead to processing a change, no matter how small. For example, reflow must propagate from the top of the frame tree down to the frames that are dirty, no matter how small the change. One very common way around this is to batch up changes. We batch up changes in lots of ways, for example:<br />
* The content sink adds multiple nodes to the DOM tree before notifying listeners that they've been added. This allows notifying once about an ancestor rather than for each of its descendants, or notifying about a group of descendants all at once, which speeds up the processing of those notifications.<br />
* We batch up nodes that require style reresolution (recomputation of selector matching and processing the resulting style changes). This batching is tree based, so it not only merges multiple notifications on the same element, but also merges a notification on an ancestor with a notification on its descendant (since ''some'' of these notifications imply that style reresolution is required on all descendants).<br />
* We wait to reconstruct frames that require reconstruction (after destroying frames eagerly). This, like the tree-based style reresolution batching, avoids duplication both for same-element notifications and ancestor-descendant notifications, even though it doesn't actually do any tree-based caching.<br />
* We postpone doing reflows until needed. As for style reresolution, this maintains tree-based dirty bits (see the description of NS_FRAME_IS_DIRTY and NS_FRAME_HAS_DIRTY_CHILDREN under Reflow).<br />
* We allow the OS to queue up multiple invalidates before repainting (though we will likely switch to controlling that ourselves). This leads to a single repaint of some set of pixels where there might otherwise have been multiple (though it may also lead to more pixels being repainted if multiple rectangles are merged to a single one).<br />
<br />
Having changes buffered up means, however, that various pieces of information (layout, style, etc.) may not be up-to-date. Some things require up-to-date information: for example, we don't want to expose the details of our buffering to Web page script since the programming model of Web page script assumes that DOM changes take effect "immediately", i.e., that the script shouldn't be able to detect any buffering. Many Web pages depend on this.<br />
<br />
We therefore have ways to flush these different sorts of buffers. There are methods called FlushPendingNotifications on nsIDocument and nsIPresShell, that take an argument of what things to flush:<br />
* Flush_Content: create all the content nodes from data buffered in the parser<br />
* Flush_ContentAndNotify: the above, plus notify document observers about the creation of all nodes created so far<br />
* Flush_Style: the above, plus make sure style data are up-to-date<br />
* Flush_Frames: the above, plus make sure all frame construction has happened (currently the same as Flush_Style)<br />
* Flush_InterruptibleLayout: the above, plus perform layout (Reflow), but allow interrupting layout if it takes too long<br />
* Flush_Layout: the above, plus ensure layout (Reflow) runs to completion<br />
* Flush_Display (should never be used): the above, plus ensure repainting happens<br />
<br />
The major way that notifications of changes propagate from the content code to layout and other areas of code is through the nsIDocumentObserver and nsIMutationObserver interfaces. Classes can implement this interface to listen to notifications of changes for an entire document or for a subtree of the content tree.<br />
<br />
WRITE ME: ... layout document observer implementations<br />
<br />
TODO: how style system optimizes away rerunning selector matching<br />
<br />
TODO: style changes and nsChangeHint<br />
<br />
=== Refresh driver ===<br />
<br />
== Graphics ==<br />
[https://wiki.mozilla.org/Platform/GFX Wiki page] | [https://wiki.mozilla.org/index.php?title=Platform/GFX/Contribute contribute]<br />
<br />
==== Painting/Rasterizing ====<br />
<br />
Painting/rendering/rasterizing is the step where graphical primitives (such as a command to fill an [https://developer.mozilla.org/en-US/docs/Web/SVG SVG] circle, or a [https://developer.mozilla.org/en-US/docs/Web/Guide/Graphics/Drawing_graphics_with_canvas canvas] command to stroke a path between x, y, z, or the internally produced command to draw the edge of an HTML div's border) are used to color in the pixels of a surface so that the surface "displays" those rasterized primitives.<br />
<br />
The platform independent library that gecko uses to render is [http://dxr.mozilla.org/mozilla-central/source/gfx/2d/2D.h Moz2D]. Gecko code paints into Moz2D DrawTarget objects (the DrawTarget baseclass having multiple platform dependent subclasses). (At least this is where gecko is going - for now there is still significant amounts of code that uses [http://dxr.mozilla.org/mozilla-central/source/gfx/thebes/gfxContext.h Thebes gfxContext] objects or the even older nsRenderingContext objects. Objects of these types now always wrap a DrawTarget so all painting does now go through Moz2D, but conversion to use the wrapped DrawTargets directly is taking time since consumer code can sometimes need to be radically rewritten to fit the Moz2D API and immediate mode paradigm.)<br />
<br />
==== Compositing ====<br />
<br />
The compositing stage of the rendering pipeline is operated by the [http://dxr.mozilla.org/mozilla-central/source/gfx/layers/ gfx/layers] module.<br />
<br />
Different parts of a web page can sometimes be painted into intermediate surfaces retained by layers. It can be convenient to think of layers as the layers in image manipulation programs like The Gimp or Photoshop. Layers are organized as a tree. Layers are primarily used to minimize invalidating and repainting when elements are being animated independently of one another in a way that can be optimized using layers (e.g. opacity or transform animations), and to enable some effects (such as transparency and 3D transforms).<br />
<br />
Compositing is the action of flattening the layers into the final image that is shown on the screen.<br />
<br />
On some platform, compositing happens on the Content thread. However, on other platforms we composite on a separate thread (Off-main-thread compositing, or OMTC). OMTC is at the moment the default behavior on mobile platforms, but the goal is to do it on all platforms in the long run.<br />
<br />
The Layers architecture is built on the following notions:<br />
* Compositor: an object that can draw quads on the screen (or on an off-screen render target).<br />
* Texture: an object that contains image data.<br />
* Compositable: an object that can manipulate one or several textures, and knows how to present them to the compositor<br />
* Layer: an element of the layer tree. A layer usually doesn't know much about compositing: it uses a compositable to do the work. Layers are mostly nodes of the layer tree.<br />
<br />
[[File:LayersRefactoring.png|thumb|650px|New layers architecture, with OGL backend]]<br />
<br />
The above abstractions are sufficient to perform compositing on the main thread, but on the OMTC case, we need a mechanism to synchronize a client layer tree that is constructed on the content thread, and a host layer tree that is used for compositing on the compositor thread.<br />
This synchronization process must ensure that the host layer tree reflects the state of the current layer tree while remaining in a consistent state, and must transfer texture data from a thread to the other. Moreover, on some platforms the content and compositor threads may live in separate processes.<br />
<br />
To perform this synchronization, we use the IPDL IPC framework. IPDL lets us describe communications protocols and actors in a domain specific language. for more information about IPDL, read https://wiki.mozilla.org/IPDL<br />
<br />
When the client layer tree is modified, we record modifications into messages that are sent together to the host side within a transaction. A transaction is basically a list of modifications to the layer tree that have to be applied all at once to preserve consistency in the state of the host layer tree.<br />
<br />
Texture transfer is done by synchronizing texture objects across processes/threads using a couple TextureClient/TextureHost that wrap shared data and provide access to it on both sides. TextureHosts provide access to one or several TextureSource, which has the necessary API to actually composite the texture (TextureClient/Host being more about IPC synchronization than actual compositing.<br />
The logic behind texture transfer (as in single/double/triple buffering, texture tiling, etc) is operated by the CompositableClient and CompositableHost.<br />
<br />
It is important to understand the separation between layers and compositables. Compositables handle all the logic around texture transfer, while layers define the shape of the layer tree. a Compositable is created independently from a layer and attached to it on both sides. While layers transactions can only originate from the content thread, this separation makes it possible for us to have separate compositable transactions between any thread and the compositor thread. We use the ImageBridge IPDL protocol to that end. The Idea of ImageBridge is to create a Compositable that is manipulated on the ImageBridgeThread, and that can transfer/synchronize textures without using the content thread at all. This is very useful for smooth Video compositing: video frames are decoded and passed into the ImageBridge without ever touching the content thread, which could be busy processing reflows or heavy javascript workloads.<br />
<br />
It is worth reading the inline code documentation in the following files:<br />
* [http://dxr.mozilla.org/mozilla-central/source/gfx/layers/Compositor.h gfx/layers/Compositor.h]<br />
* [http://dxr.mozilla.org/mozilla-central/source/gfx/layers/ShadowLayers.h gfx/layers/ShadowLayers.h]<br />
* [http://dxr.mozilla.org/mozilla-central/source/gfx/layers/Layers.h gfx/layers/Layers.h]<br />
* [http://dxr.mozilla.org/mozilla-central/source/gfx/layers/host/TextureHost.h gfx/layers/host/TextureHost.h]<br />
* [http://dxr.mozilla.org/mozilla-central/source/gfx/layers/client/CompositableClient.h gfx/layers/client/CompositableClient.h]<br />
<br />
To visualize how a web page is layered, turn on the pref "layers.draw-borders" in about:config. When this pref is on, the borders of layers and tiles are displayed on top of the content. This only works when using the new Compositor API, that is when off-main-thread compositing is activated. OMTC is activated by default on all mobile platforms, and will progressively get activated on desktop platforms (not yet, though). On platforms where OMTC is not used, this pref has no effect. <br />
<br />
Blog posts with information on Layers that should be integrated here:<br />
<br />
* [http://www.basschouten.com/blog1.php/layers-cross-platform-acceleration Layers: Cross-Platform Acceleration]<br />
* [http://robert.ocallahan.org/2010/04/layers_01.html Layers]<br />
* [http://robert.ocallahan.org/2010/07/retained-layers_16.html Retained Layers]<br />
* [http://chrislord.net/index.php/2011/07/25/shadow-layers-and-learning-by-failing/ Shadow Layers, and learning by failing]<br />
* [http://chrislord.net/index.php/2011/08/16/accelerated-layer-rendering-and-learning-by-some-success/ Accelerated layer-rendering, and learning by (some) success]<br />
* [http://featherweightmusings.blogspot.co.uk/2012/05/mask-layers_26.html Mask Layers]<br />
* [http://featherweightmusings.blogspot.co.uk/2012/05/building-mask-layer.html Building a mask layer]<br />
* [http://featherweightmusings.blogspot.co.uk/2012/06/mask-layers-on-direct3d-backends.html Mask Layers on the Direct3D backends]<br />
* [http://robert.ocallahan.org/2011/09/graphics-api-design.html Graphics API Design]<br />
<br />
==== Async Panning and Zooming ====<br />
<br />
On some of our mobile platforms we have some code that allows the user to do asynchronous (i.e. off-main-thread) panning and zooming of content. This code is the Async Pan/Zoom module (APZ) code and is further documented at [[Platform/GFX/APZ]].<br />
<br />
== Scripting ==<br />
<br />
=== JavaScript Engine ===<br />
<br />
Gecko embeds the SpiderMonkey JavaScript engine (located in js/src). The JS engine includes a number of Just-In-Time compilers (or JITs). SpiderMonkey provides a powerful and extensive embedding API (called the JSAPI). Because of its complexity, using the JSAPI directly is frowned upon, and a number of abstractions have been built in Gecko to allow interacting with the JS engine without using JSAPI directly. Some JSAPI concepts are important for Gecko developers to understand, and they are listed below:<br />
<br />
* Global object: The '''global object''' is the object on which all global variables/properties/methods live. In a web page this is the 'window' object. In other things such as XPCOM components or sandboxes XPConnect creates a global object with a small number of builtin APIs.<br />
* Compartments: A '''compartment''' is a subdivision of the JS heap. The mapping from global objects to compartments is one-to-one; that is, every global object has a compartment associated with it, and no compartment is associated with more than one global object. (NB: There are compartments associated with no global object, but they aren't very interesting). When JS code is running SpiderMonkey has a concept of a "current" compartment. New objects that are created will be created in the "current" compartment and associated with the global object of that compartment.<br />
* When objects in one compartment can see objects in another compartment (via e.g. iframe.contentWindow.foo) '''cross-compartment wrappers''' or '''CCWs''' mediate the interaction between the two compartments. By default CCWs ensure that the current compartment is kept up-to-date when execution crosses a compartment boundary. SpiderMonkey also allows embeddings to extend wrappers with custom behavior to implement security policies, which Gecko uses extensively (see the Security section for more information).<br />
<br />
=== XPConnect ===<br />
<br />
'''XPConnect''' is a bridge between C++ and JS used by XPCOM components exposed to or implemented in JavaScript. XPConnect allows two XPCOM components to talk to each other without knowing or caring which language they are implemented in. XPConnect allows JS code to call XPCOM components by exposing XPCOM interfaces as JS objects, and mapping function calls and attributes from JS into virtual method calls on the underlying C++ object. It also allows JS code to implement an XPCOM component that can be called from C++ by faking the vtable of an interface and translating calls on the interface into JS calls. XPConnect accomplishes this using the vtable data stored in XPCOM TypeLibs (or XPT files) by the XPIDL compiler and a small layer of platform specific code called [https://developer.mozilla.org/en-US/docs/xptcall_FAQ xptcall] that knows how to interact with and impersonate vtables of XPCOM interfaces.<br />
<br />
XPConnect is also used for a small (and decreasing) number of legacy DOM objects. At one time all of the DOM used XPConnect to talk to JS, but we have been replacing XPConnect with the WebIDL bindings (see the next section for more information). Arbitrary XPCOM components are not exposed to web content. XPCOM components that want to be accessible to web content must provide class info (that is, they must QI to nsIClassInfo) and must be marked with the nsIClassInfo::DOM_OBJECT flag. Most of these objects also are listed in dom/base/nsDOMClassInfo.cpp, where the interfaces that should be visible to the web are enumerated. This file also houses some "scriptable helpers" (classes ending in "SH" and implementing nsIXPCScriptable), which are a set of optional hooks that can be used by XPConnect objects to implement more exotic behaviors (such as indexed getters or setters, lazily resolved properties, etc). This is all legacy code, and any new DOM code should use the WebIDL bindings.<br />
<br />
=== WebIDL Bindings ===<br />
<br />
The '''WebIDL bindings''' are a separate bridge between C++ and JS that is specifically designed for use by DOM code. We intend to replace all uses of XPConnect to interface with content JavaScript with the WebIDL bindings. [https://developer.mozilla.org/en-US/docs/Mozilla/WebIDL_bindings Extensive documentation] on the WebIDL bindings is available, but the basic idea is that a binding generator takes WebIDL files from web standards and some configuration data provided by us and generates at build time C++ glue code that sits between the JS engine and the DOM object. This setup allows us to produce faster, more specialized code for better performance at the cost of increased codesize.<br />
<br />
The WebIDL bindings also implement all of the behavior specified in WebIDL, making it possible for new additions to the DOM to behave correctly "out of the box". The binding layer also provides C++ abstractions for types that would otherwise require direct JSAPI calls to handle, such as typed arrays. <br />
<br />
=== Security ===<br />
<br />
Gecko's JS security model is based on the concept of compartments. Every compartment has a '''principal''' associated with it that contains security information such as the '''origin''' of the compartment, whether or not it has system privileges, etc. For the following discussion, '''wrappee''' refers to the underlying object being wrapped, '''scope''' refers to the compartment the object is being wrapped for use in, and '''wrapper''' refers to the object created in '''scope''' that allows it to interact with '''wrappee'''. "Chrome" refers to JS that is built in to the browser or part of an extension, which runs with full privileges, and is contrasted with "content", which is web provided script that is subject to security restrictions and the same origin policy.<br />
<br />
* Xray wrappers: Xray wrappers are used when the scope has chrome privileges and the wrappee is the JS reflection of an underlying DOM object. Beyond the usual CCW duties of making sure that content code does not run with chrome privileges, Xray wrappers also ensure that calling methods or accessing attributes on the wrappee has the "expected" effect. For example, a web page could replace the <code>close</code> method on its window with a JS function that does something completely different. (e.g. <code>window.close = function() { alert("This isn't what you wanted!") };</code>). Overwriting methods in this way (or creating entirely new ones) is referred to as '''expando''' properties. Xrays see through expando properties, invoking the original method/getter/setter if the expando overwrites a builtin or seeing undefined in the expando creates a new property. This allows chrome code to call methods on content DOM objects without worrying about how the page has changed the object.<br />
* Waived xray wrappers: The xray behavior is not always desirable. It is possible for chrome to "waive" the xray behavior and see the actual JS object. The wrapper still guarantees that code runs with the correct privileges, but methods/getters/setters may not behave as expected. This is equivalent to the behavior chrome sees when it looks at non-DOM content JS objects.<br />
* For more information, see the [https://developer.mozilla.org/en-US/docs/Mozilla/Gecko/Script_security MDN page]<br />
* bholley's [https://air.mozilla.org/enter-the-compartment/ Enter the Compartment] talk also provides an overview of our compartment architecture.<br />
<br />
== Images ==<br />
<br />
== Plugins ==<br />
<br />
== Platform-specific layers ==<br />
<br />
* widget<br />
* native theme<br />
* files, networking, other low-level things<br />
* Accessibility APIs<br />
* Input. Touch-input stuff is somewhat described at [[Platform/Input/Touch]].<br />
<br />
== Editor ==<br />
<br />
== Base layers ==<br />
<br />
=== NSPR ===<br />
<br />
NSPR is a library for providing cross-platform APIs for various<br />
platform-specific functions. We tend to be trying to use it as little<br />
as possible, although there are a number of areas (particularly some<br />
network-related APIs and threading/locking primitives) where we use it<br />
quite a bit.<br />
<br />
=== XPCOM ===<br />
<br />
XPCOM is a cross-platform modularity library, modeled on Microsoft COM. It<br />
is an object system in which all objects inherit from the <code>nsISupports</code> interface.<br />
<br />
components and services, contract IDs and CIDs<br />
<br />
prior overuse of XPCOM; littering with XPCOM does not produce modularity<br />
<br />
Base headers (part of xpcom/base/) and data structures. See also mfbt.<br />
<br />
Threading<br />
<br />
xptcall, proxies<br />
<br />
reference counting, cycle collection<br />
<br />
Further documentation:<br />
* XPCOM and Internal Strings in Gecko (talk by David Baron, 2014-03-20): [https://air.mozilla.org/xpcom-and-internal-strings-in-gecko/ video], [https://dbaron.org/talks/2014-03-20-xpcom-string-taipei/speaking-notes speaking notes]<br />
<br />
=== String ===<br />
<br />
XPCOM has string classes for representing sequences of characters. Typical C++ string classes have the goals of encapsulating the memory management of buffers and the issues needed to avoid buffer overruns common in traditional C string handling. Mozilla's string classes have these goals, and also the goal of reducing copying of strings.<br />
<br />
(There is a second set of string classes in xpcom/glue for callers outside of libxul; these classes are partially source-compatible but have different (worse) performance characteristics. This discussion does not cover those classes.)<br />
<br />
We have two parallel sets of classes, one for strings with 1-byte units (<code>char</code>, which may be signed or unsigned), and one for strings with 2-byte units (<code>char16_t</code>, always unsigned). The classes are named such that the class for 2-byte characters ends with <code>String</code> and the corresponding class for 1-byte characters ends with <code>CString</code>. 2-byte strings are almost always used to encode [http://en.wikipedia.org/wiki/UTF-16 UTF-16]. 1-byte strings are usually used to encode either [http://en.wikipedia.org/wiki/ASCII ASCII] or [http://en.wikipedia.org/wiki/UTF-8 UTF-8], but are sometimes also used to hold data in some other encoding or just byte sequences.<br />
<br />
The string classes distinguish, as part of the type hierarchy, between strings that must have a null-terminator at the end of their buffer (<code>ns[C]String</code>) and strings that are not required to have a null-terminator (<code>ns[C]Substring</code>). <code>ns[C]Substring</code> is the base of the string classes (since it imposes fewer requirements) and <code>ns[C]String</code> is a class derived from it. Functions taking strings as parameters should generally take one of these four types.<br />
<br />
In order to avoid unnecessary copying of string data (which can have significant performance cost), the string classes support different ownership models. All string classes support the following three ownership models dynamically:<br />
* reference counted, copy-on-write, buffers (the default)<br />
* adopted buffers (a buffer that the string class owns, but is not reference counted, because it came from somewhere else)<br />
* dependent buffers, that is, an underlying buffer that the string class does not own, but that the caller that constructed the string guarantees will outlive the string instance<br />
In addition, there is a special string class, <code>nsAuto[C]String</code>, that ''additionally'' contains an internal 64-unit buffer (intended primarily for use on the stack), leading to a fourth ownership model:<br />
* storage within an auto string's stack buffer<br />
Auto strings will prefer reference counting an existing reference-counted buffer over their stack buffer, but will otherwise use their stack buffer for anything that will fit in it.<br />
<br />
There are a number of additional string classes, particularly <code>nsDependent[C]String</code>, <code>nsDependent[C]Substring</code>, and the <code>NS_LITERAL_[C]STRING</code> macros which construct an <code>nsLiteral[C]String</code> which exist primarily as constructors for the other types. These types are really just convenient notation for constructing an <code>ns[C]S[ubs]tring</code> with a non-default ownership mode; they should not be thought of as different types. (The <code>Substring</code>, <code>StringHead</code>, and <code>StringTail</code> functions are also constructors for dependent [sub]strings.) Non-default ownership modes can also be set up using the <code>Rebind</code> and <code>Adopt</code> methods, although the <code>Rebind</code> methods actually live on the derived types, which is probably a mistake (although moving them up would require some care to avoid making an API that easily allows assigning a non-null-terminated buffer to a string whose static type indicates that it is null-terminated).<br />
<br />
Note that the presence of all of these classes imposes some awkwardness in terms of distinctions being available as both static type distinctions and dynamic type distinctions. In general, the only distinctions that should be made statically are 1-byte vs. 2-byte sequences (<code>CString</code> vs <code>String</code>) and whether the buffer is null-terminated or not (<code>Substring</code> vs <code>String</code>). (Does the code actually do a good job of dynamically enforcing the <code>Substring</code> vs. <code>String</code> restriction?)<br />
<br />
TODO: buffer growth, concatenation optimizations<br />
<br />
TODO: encoding conversion, what's validated and what isn't<br />
<br />
TODO: "string API", nsAString (historical)<br />
<br />
* Code: xpcom/string/<br />
* Bugzilla: Core::String<br />
<br />
Further documentation:<br />
* XPCOM and Internal Strings in Gecko (talk by David Baron, 2014-03-20): [https://air.mozilla.org/xpcom-and-internal-strings-in-gecko/ video], [https://dbaron.org/talks/2014-03-20-xpcom-string-taipei/speaking-notes speaking notes]</div>Dbaronhttps://wiki.mozilla.org/index.php?title=Gecko:Overview&diff=1193184Gecko:Overview2018-05-02T20:24:14Z<p>Dbaron: /* String */ link to video</p>
<hr />
<div>This document attempts to give an overview of the different parts of<br />
Gecko, what they do, and why they do it, say where the code for them is<br />
within the repository, and link to more specific documentation (when<br />
available) covering the details of that code. '''It is not yet complete.''' Maintainers of these<br />
areas of code should correct errors, add information, and add links to<br />
more detailed documentation (since this document is intended to remain<br />
an overview, not complete documentation).<br />
<br />
__TOC__<br />
<br />
== Browsers, Frames, and Document Navigation ==<br />
<br />
=== Docshell ===<br />
<br />
The user of a Web browser can change the page shown in that browser in<br />
many ways: by clicking a link, loading a new URL, using the forward and<br />
back buttons, or other ways. This can happen inside a space we'll call<br />
a '''browsing context'''; this space can be a browser window, a tab, or a frame<br />
or iframe within a document. The toplevel data structures within Gecko<br />
represent this browsing context; they contain other data structures<br />
representing the individual pages displayed inside of it (most<br />
importantly, the current one). In terms of implementation, these two<br />
types of navigation, the top level of a browser and the frames within<br />
it, largely use the same data structures.<br />
<br />
In Gecko, the '''docshell''' is the toplevel object responsible for<br />
managing a single browsing context. It, and the associated '''session history''' code, <br />
manage the navigation between pages inside of a<br />
docshell. (Note the difference between session history, which is a<br />
sequence of pages in a single browser session, used for recording information<br />
for back and forward navigation, and global history, which is the<br />
history of pages visited and associated times, regardless of browser<br />
session, used for things like link coloring and address autocompletion.)<br />
<br />
There are relatively few objects in Gecko that are associated with a<br />
docshell rather than being associated with a particular one of the pages<br />
inside of it. Most such objects are attached to the docshell. An important object associated with the docshell is the nsGlobalWindowOuter which is what the HTML5 spec refers to as a WindowProxy (into which Window objects, as implemented by nsGlobalWindowInner, are loaded). See the DOM section below for more information on<br />
this.<br />
<br />
The most toplevel object for managing the contents of a particular page<br />
being displayed within a docshell is a document viewer (see layout).<br />
Other important objects associated with this presentation are the<br />
document (see DOM) and the pres(entation) shell and pres(entation)<br />
context (see layout).<br />
<br />
[[File:WebNavigation.png|thumb|400px|<xul:browser>, frameloader and docshell in single process configuration]]<br />
<br />
Docshells are organized into a tree. If a docshell has a non-null parent, then it corresponds to a subframe in whatever page is currently loaded in the parent docshell, and the corresponding subframe element (for example, an iframe) is called a '''browsing context container'''. In Gecko, a browsing context container would implement <code>[https://dxr.mozilla.org/mozilla-central/rev/f9a5e9ed62103c84e4cde915f4d08f1ce71be83e/dom/base/nsIFrameLoader.idl#271 nsIFrameLoaderOwner]</code> to hold a '''frameloader''', which holds and manages the docshell. <br />
<br />
One of the most interfaces docshell implemented is <code>[https://dxr.mozilla.org/mozilla-central/source/docshell/base/nsIWebNavigation.idl nsIWebNavigation]</code>. It defines major functions of a browsing context, such as <code>loadURI</code> / <code>goBack</code> / <code>goForward</code> and <code>reload</code>. In single process configuration of desktop Firefox, <code><xul:browser></code> (which represents a tab) operates on docshell through <code>nsIWebNavigation</code>, as shown in the right figure.<br />
<br />
* code: mozilla/docshell/<br />
* bugzilla: Core::Document Navigation<br />
* documentation: [[DocShell:Home Page]]<br />
<br />
=== Session History ===<br />
<br />
In order to keep the session history of subframes after the root document is unloaded and docshells of subframes are destroyed, only the root docshell of a docshell tree manages the session history (this does not match the conceptual model in the HTML5 spec and may be subject to change).<br />
<br />
As an example to explain the structure of session history implementation in Gecko, consider there's a tab A, which loads document 1; in document 1, there are iframe B & C, which loads document 2 & 3, respectively. Later, an user navigates iframe B to document 4. The following figures show the conceptual model of the example, and the corresponding session history structure.<br />
<br />
{| <br />
| [[File:BrowsingContextExample1.png|thumb|190px|Conceptual model representation; color denotes current visible active documents]]<br />
| [[File:SHistoryExample1.png|thumb|180px|Session history structure; color denotes current transaction / entries]]<br />
|}<br />
<br />
In Gecko, a [https://dxr.mozilla.org/mozilla-central/source/docshell/shistory/nsSHistory.h session history] object holds a list of [https://dxr.mozilla.org/mozilla-central/source/docshell/shistory/nsSHTransaction.h transactions] (denoted as T1 & T2 in the figure); each transaction points to a tree of [https://dxr.mozilla.org/mozilla-central/source/docshell/shistory/nsSHEntry.h entries]; each entry records the docshell it associated to, and a URL. Now that if we navigate the tab to a different root document 5, which includes an iframe D with document 6, then it becomes:<br />
<br />
{| <br />
| [[File:BrowsingContextExample2.png|thumb|275px|Conceptual model representation]]<br />
| [[File:SHistoryExample2.png|thumb|250px|Session history structure]]<br />
|}<br />
<br />
=== Embedding ===<br />
<br />
To be written (and maybe rewritten if we get an IPC embedding API).<br />
<br />
[[File:WebNavigationE10S.png|thumb|500px|<xul:remote-browser>, frameloader and docshell in multiprocess configuration. The horizontal dash-lines represent inter-process communication]]<br />
<br />
=== Multi-process and IPC ===<br />
<br />
In a multi-process desktop Firefox, a tab is managed by <code>[https://dxr.mozilla.org/mozilla-central/source/toolkit/content/widgets/remote-browser.xml <xul:remote-browser>]</code>. It still operates on nsIWebNavigation, but in this case the docshell is in a remote process and can not be accessed directly. The encapsulation of remote nsIWebNavigation is done by the javascript-implemented <code>[https://dxr.mozilla.org/mozilla-central/source/toolkit/components/remotebrowserutils/RemoteWebNavigation.js RemoteWebNavigation]</code>.<br />
<br />
In this configuration, the frameloader of a root docshell lives in parent process, so it can not access docshell directly either. Instead, it holds a <code>[https://dxr.mozilla.org/mozilla-central/source/dom/ipc/TabParent.h TabParent]</code> instance to interact with <code>[https://dxr.mozilla.org/mozilla-central/source/dom/ipc/TabChild.h TabChild]</code> in child-process. At C/C++ level, the communication across processes for a single tab is through the '''PBrowser''' IPC protocol implemented by TabParent and TabChild, while at the javascript level it's done by '''message manager''' (which is ontop of PBrowser). RemoteWebNavigation, for example, sends messages to <code>[https://dxr.mozilla.org/mozilla-central/source/toolkit/content/browser-child.js browser-child.js]</code> in content process through message manager.<br />
<br />
== Networking ==<br />
<br />
The network library Gecko uses is called Necko. Necko APIs are largely organized around three concepts: '''URI objects''', '''protocol handlers''', and '''channels'''.<br />
<br />
=== Protocol handlers ===<br />
A '''protocol handler''' is an XPCOM service associated with a particular URI scheme or network protocol. Necko includes protocol handlers for HTTP, FTP, the data: URI scheme, and various others. Extensions can implement protocol handlers of their own.<br />
<br />
A protocol handler implements the <code>[https://dxr.mozilla.org/mozilla-central/source/netwerk/base/nsIProtocolHandler.idl nsIProtocolHandler]</code> API, which serves three primary purposes:<br />
# Providing metadata about the protocol (its security characteristics, whether it requires actual network access, what the corresponding URI scheme is, what TCP port the protocol uses by default).<br />
# Creating URI objects for the protocol's scheme.<br />
# Creating channel objects for the protocol's URI objects<br />
<br />
Typically, the built-in I/O service (<code>[https://dxr.mozilla.org/mozilla-central/source/netwerk/base/nsIIOService2.idl nsIIOService]</code>) is responsible for finding the right protocol handler for URI object creation and channel creation, while a variety of consumers queries protocol metadata. Querying protocol metadata is the recommended way to handle any sort of code that needs to have different behavior for different URI schemes. In particular, unlike whitelists or blacklists, it correctly handles the addition of new protocols.<br />
<br />
A service can register itself as a protocol handler by registering for the contract ID <code>"@mozilla.org/network/protocol;1?name=SSSSS"</code> where <code>SSSS</code> is the URI scheme for the protocol (e.g. "http", "ftp", and so forth).<br />
<br />
=== URI objects ===<br />
URI objects, which implement the <code>[https://dxr.mozilla.org/mozilla-central/source/netwerk/base/nsIURI.idl nsIURI]</code> API, are a way of representing URIs and IRIs. Their main advantage over strings is that they do basic syntax checking and canonicalization on the URI string that they're provided with. They also provide various accessors to extract particular parts of the URI and provide URI equality comparisons. URIs that correspond to hierarchical schemes implement the additional <code>[https://dxr.mozilla.org/mozilla-central/source/netwerk/base/nsIURL.idl nsIURL]</code> interface, which exposes even more accessors for breaking out parts of the URI.<br />
<br />
URI objects are typically created by calling the <code>newURI</code> method on the I/O service, or in C++ by calling the <code>NS_NewURI</code> utility function. This makes sure to create the URI object using the right protocol handler, which ensures that the right kind of object is created. Direct creation of URIs via <code>createInstance</code> is reserved for protocol handler implementations.<br />
<br />
=== Channels ===<br />
[https://dxr.mozilla.org/mozilla-central/source/netwerk/base/nsIChannel.idl Channels] are the Necko representation of a single request/response interaction with a server. A channel is created by calling the <code>newChannel</code> method on the [https://dxr.mozilla.org/mozilla-central/source/netwerk/base/nsIIOService.idl I/O service], or in C++ by calling the <code>[https://dxr.mozilla.org/mozilla-central/search?q=function%3ANS_NewChannel&case=true NS_NewChannel]</code> utility function. The channel can then be configured as needed, and finally its <code>asyncOpen</code> method can be called. This method takes an <code>[https://dxr.mozilla.org/mozilla-central/source/netwerk/base/nsIStreamListener.idl nsIStreamListener]</code> as an argument.<br />
<br />
If <code>asyncOpen</code> has returned successfully, the channel guarantees that it will asynchronously call the <code>onStartRequest</code> and <code>onStopRequest</code> methods on its stream listener. This will happen even if there are network errors that prevent Necko from actually performing the requests. Such errors will be reported in the channel's status and in the <code>status</code> argument to <code>onStopRequest</code>.<br />
<br />
If the channel ends up being able to provide data, it will make one or more <code>onDataAvailable</code> on its listener after calling <code>onStartRequest</code> and before calling <code>onStopRequest</code>. For each call, the listener is responsible for either returning an error or reading the entire data stream passed in to the call.<br />
<br />
If an error is returned from either <code>onStartRequest</code> or <code>onDataAvailable</code>, the channel must act as if it has been canceled with the corresponding error code.<br />
<br />
A channel has two URI objects associated with it. The <code>originalURI</code> of the channel is the URI that was originally passed to <code>newChannel</code> to create the channel that then had <code>asyncOpen</code> called on it. The <code>URI</code> is the URI from which the channel is reading data. These can be different in various cases involving protocol handlers that forward network access to other protocol handlers, as well as in situations in which a redirect occurs (e.g. following an HTTP 3xx response). In redirect situations, a new channel object will be created, but the originalURI will be propagated from the old channel to the new channel.<br />
<br />
Note that the <code>nsIRequest</code> that's passed to onStartRequest must match the one passed to onDataAvailable and onStopRequest, but need not be the original channel that asyncOpen was called on. In particular, when an HTTP redirect happens the request argument to the callbacks will be the post-redirect channel.<br />
<br />
TODO: crypto?<br />
<br />
== Document rendering pipeline ==<br />
<br />
Some of the major components of Gecko can be described as steps on the<br />
path from an HTML document coming in from the network to the graphics<br />
commands needed to render that document. An HTML document is a<br />
serialization of a tree structure. (FIXME: add diagram) The HTML<br />
parser and content sink create an in-memory representation of this tree,<br />
which we call the '''DOM tree''' or '''content tree'''.<br />
Many JavaScript APIs operate on the content tree. Then, in<br />
layout, we create a second tree, the '''frame tree''' (or<br />
'''rendering tree''') that is a similar shape to the content tree,<br />
but where each node in the tree represents a rectangle (except in SVG<br />
where they represent other shapes). We then compute the positions of<br />
the nodes in the frame tree (called '''frames''') and paint them<br />
using our cross-platform graphics APIs (which, underneath, map to<br />
platform-specific graphics APIs).<br />
<br />
See [http://dbaron.org/talks/ David Baron's "Fast CSS: How Browsers Lay Out Web Pages" talk] for an overview of the pipeline in a presentation format.<br />
<br />
=== Parser ===<br />
<br />
The parser's job is to transform a character stream into a tree<br />
structure, with the help of the content sink classes.<br />
<br />
HTML is parsed using a parser implementing the parsing algorithm in the<br />
HTML specification (starting with HTML5). Much of this parser is<br />
translated from Java, and changes are made to the Java version. This<br />
parser in parser/html/. The parser is driven by the output of the networking layer (see nsHtml5StreamParser::OnDataAvailable). The HTML5 parser is capable of parsing off the main thread which is the normal case. It also parses on the main thread to be able to synchronously handle things such as innerHTML modifications.<br />
<br />
The codebase still has the previous generation HTML parser, which is<br />
still used for a small number of things, though we hope to be able to<br />
remove it entirely soon. This parser is in parser/htmlparser/.<br />
<br />
XML is parsed using the expat library (parser/expat/) and code that<br />
wraps it (parser/xml/). This is a non-validating parser; however, it<br />
loads certain DTDs to support XUL localization.<br />
<br />
=== DOM / Content ===<br />
<br />
The content tree or DOM tree is the central data structure for Web<br />
pages. It is a tree structure, initially created from the tree<br />
structure expressed in the HTML or XML markup. The nodes in the tree<br />
implement major parts of the DOM (Document Object Model) specifications.<br />
The nodes themselves are part of a class hierarchy rooted at<br />
<code>nsINode</code>; different derived classes are used for things such<br />
as text nodes, the document itself, HTML elements, SVG elements, etc.,<br />
with further subclasses of many of these types (e.g., for specific HTML<br />
elements). Many of the APIs available to script running in Web pages<br />
are associated with these nodes. The tree structure persists while the<br />
Web pages is displayed, since it stores much of state associated with<br />
the Web page. The code for these nodes lives in the content/ directory.<br />
<br />
The DOM APIs are not threadsafe. DOM nodes can be accessed only from<br />
the main thread (also known as the UI thread (user interface thread)) of<br />
the application.<br />
<br />
There are also many other APIs available to Web pages that are not APIs<br />
on the nodes in the DOM tree. Many of these other APIs also live in the<br />
same directories, though some live in content/ and some in dom/. These<br />
include APIs such as the DOM event model.<br />
<br />
The dom/ directory also includes some of the code needed to expose Web<br />
APIs to JavaScript (in other words, the glue code between JavaScript and<br />
these APIs). For an overview, see [https://ask.mozilla.org/question/390/how-is-the-web-exposed-dom-implemented/ DOM API Implementation]. See [[#Scripting|Scripting]] below for details of the JS engine.<br />
<br />
TODO: Internal APIs vs. DOM APIs.<br />
<br />
TODO: Mutation observers / document observers.<br />
<br />
TODO: Reference counting and cycle collection.<br />
<br />
TODO: specification links<br />
<br />
=== Style System ===<br />
<br />
==== Quantum CSS (Stylo) ====<br />
<br />
Starting with Firefox 57 and later, Gecko makes use of the parallel style system written in Rust that comes from Servo. There's an [https://hacks.mozilla.org/2017/08/inside-a-super-fast-css-engine-quantum-css-aka-stylo/ overview] of this with graphics to help explain what's going on. The [https://github.com/servo/servo/wiki/Layout-Overview Servo wiki] has some more details.<br />
<br />
==== Gecko ====<br />
<br />
The rest of the style section section describes the Gecko style system used in Firefox 56 and earlier. Some bits may still apply, but it likely needs revising.<br />
<br />
In order to display the content, Gecko needs to compute the styles<br />
relevant to each DOM node. It does this based on the model described in<br />
the CSS specifications: this model applies to style specified in CSS<br />
(e.g. by a 'style' element, an 'xml-stylesheet' processing instruction<br />
or a 'style' attribute),<br />
style specified by presentation attributes, and the default style<br />
specified by our own user agent style sheets. There are two major<br />
sets of data structures within the style system:<br />
* first, data structures that represent sources of style data, such as CSS style sheets or data from stylistic HTML attributes<br />
* second, data structures that represent computed style for a given DOM node.<br />
These sets of data structures are mostly distinct (for example, they<br />
store values in different ways).<br />
<br />
The loading of CSS style sheets from the network is managed by the <br />
[https://dxr.mozilla.org/mozilla-central/source/layout/style/Loader.h CSS loader]; <br />
they are then tokenized by the <br />
[https://dxr.mozilla.org/mozilla-central/source/layout/style/nsCSSScanner.h CSS scanner] <br />
and parsed by the <br />
[https://dxr.mozilla.org/mozilla-central/source/layout/style/nsCSSParser.h CSS parser]. <br />
Those that are attached to the document also expose APIs to<br />
script that are known as the CSS Object Model, or CSSOM.<br />
<br />
The style sheets that apply to a document are managed by a class called<br />
the [https://dxr.mozilla.org/mozilla-central/source/layout/style/nsStyleSet.h style set].<br />
The style set interacts with the different types of<br />
style sheets (representing CSS style sheets, presentational<br />
attributes, and 'style' attributes) through two interfaces:<br />
[http://dxr.mozilla.org/mozilla-central/source/layout/style/nsIStyleSheet.h nsIStyleSheet] for basic management of style sheets and<br />
[http://dxr.mozilla.org/mozilla-central/source/layout/style/nsIStyleRuleProcessor.h nsIStyleRuleProcessor] for getting the style data out of them. Usually<br />
the same object implements both interfaces, except in the most important<br />
case, CSS style sheets, where there is a single rule processor for all<br />
of the CSS style sheets in each origin (user/UA/author) of the CSS cascade.<br />
<br />
The computed style data for an element/frame are exposed to the rest of<br />
Gecko through the class mozilla::ComputedStyle (previously called<br />
nsStyleContext). Rather than having a member variable for each<br />
CSS property, it breaks up the properties into groups of related<br />
properties called style structs. These style structs obey the rule that<br />
all of the properties in a single struct either inherit by default (what<br />
the CSS specifications call "Inherited: yes" in the definition of<br />
properties; we call these inherited structs) or all are not inherited by<br />
default (we call these reset structs). Separating the properties in<br />
this way improves the ability to share the structs between similar<br />
ComputedStyle objects and reduce the amount of memory needed to store<br />
the style data. The ComputedStyle API exposes a method for getting each<br />
struct, so you'll see code like<br />
<code>sc->GetStyleText()->mTextAlign</code> for getting the value of the<br />
text-align CSS property. (Frames (see the Layout section below) also<br />
have the same<br />
GetStyle* methods, which just forward the call to the frame's<br />
ComputedStyle.)<br />
<br />
The ComputedStyles form a tree structure, in a shape somewhat like the<br />
content tree (except that we coalesce identical sibling ComputedStyles<br />
rather than keeping two of them around; if the parents have been<br />
coalesced then this can apply recursively and coalasce cousins, etc.;<br />
we do not coalesce parent/child ComputedStyles).<br />
The parent of a ComputedStyle has the style data that the ComputedStyle<br />
inherits from when CSS inheritance occurs. This means that the parent<br />
of the ComputedStyle for a DOM element is generally the ComputedStyle<br />
for that DOM element's parent, since that's how CSS says inheritance<br />
works.<br />
<br />
The process of turning the style sheets into computed style data goes<br />
through three main steps, the first two of which closely relate to the<br />
[http://dxr.mozilla.org/mozilla-central/source/layout/style/nsIStyleRule.h nsIStyleRule] interface, which represents an immutable source of style<br />
data, conceptually representing (and for CSS style rules, directly<br />
storing) a set of property:value pairs. (It is similar to the idea of a<br />
CSS style rule, except that it is immutable; this immutability allows<br />
for significant optimization. When a CSS style rule is changed through<br />
script, we create a new style rule.)<br />
<br />
The first step of going from style sheets to computed style data is<br />
finding the ordered sequence of style rules that apply to an element.<br />
The order represents which rules override which other rules: if two<br />
rules have a value for the same property, the higher ranking one wins.<br />
(Note that there's another difference from CSS style rules: declarations<br />
with !important are represented using a separate style rule.) This is<br />
done by calling one of the nsIStyleRuleProcessor::RulesMatching methods.<br />
The ordered sequence is stored in a<br />
[http://en.wikipedia.org/wiki/Trie trie] called the rule tree: the path<br />
from the root of the rule tree to any (leaf or non-leaf) node in the<br />
rule tree represents a sequence of rules, with the highest ranking<br />
farthest from the root. Each rule node (except for the root) has a<br />
pointer to a rule, but since a rule may appear in many sequences, there<br />
are sometimes many rule nodes pointing to the same rule. Once we have<br />
this list we create a ComputedStyle (or find an appropriate existing<br />
sibling) with the correct parent pointer (for inheritance) and rule node<br />
pointer (for the list of rules), and a few other pieces of information<br />
(like the pseudo-element).<br />
<br />
The second step of going from style sheets to computed style data is<br />
getting the winning property:value pairs from the rules. (This only<br />
provides property:value pairs for some of the properties; the remaining<br />
properties will fall back to inheritance or to their initial values<br />
depending on whether the property is inherited by default.) We do this<br />
step (and the third) for each style struct, the first time it is needed.<br />
This is done in nsRuleNode::WalkRuleTree, where we ask each style rule<br />
to fill in its property:value pairs by calling its MapRuleInfoInto<br />
function. When called, the rule fills in only those pairs that haven't<br />
been filled in already, since we're calling from the highest priority<br />
rule to the lowest (since in many cases this allows us to stop before<br />
going through the whole list, or to do partial computation that just<br />
adds to data cached higher in the rule tree).<br />
<br />
The third step of going from style sheets to computed style data (which<br />
various caching optimizations allow us to skip in many cases) is<br />
actually doing the computation; this generally means we transform the<br />
style data into the data type described in the "Computed Value" line in<br />
the property's definition in the CSS specifications. This<br />
transformation happens in functions called nsRuleNode::Compute*Data,<br />
where the * in the middle represents the name of the style struct. This<br />
is where the transformation from the style sheet value storage format to<br />
the computed value storage format happens.<br />
<br />
Once we have the computed style data, we then store it: if a style struct<br />
in the computed style data doesn't<br />
depend on inherited values or on data from other style structs, then we<br />
can cache it in the rule tree (and then reuse it, without recomputing<br />
it, for any ComputedStyles pointing to that rule node). Otherwise, we<br />
store it on the ComputedStyle (in which case it may be shared<br />
with the ComputedStyle's descendant ComputedStyles).<br />
This is where keeping inherited and<br />
non-inherited properties separate is useful: in the common case of<br />
relatively few properties being specified, we can generally cache the<br />
non-inherited structs in the rule tree, and we can generally share the<br />
inherited structs up and down the ComputedStyle tree.<br />
<br />
The ownership models in style sheet structures are a mix of reference<br />
counted structures (for things accessible from script) and directly<br />
owned structures. ComputedStyles are reference counted, and own their<br />
parents (from which they inherit), and rule nodes are garbage collected<br />
with a simple mark and sweep collector (which often never needs to run).<br />
<br />
* code: [http://dxr.mozilla.org/mozilla-central/source/layout/style/ layout/style/], where most files have useful one line descriptions at the top that show up in DXR<br />
* Bugzilla: Style System (CSS)<br />
* specifications<br />
** [http://www.w3.org/TR/CSS21/ CSS 2.1]<br />
** [http://www.w3.org/TR/css-2010/ CSS 2010, listing stable css3 modules]<br />
** [http://dev.w3.org/csswg/ CSS WG editors drafts] (often more current, but sometimes more unstable than the drafts on the technical reports page)<br />
** [http://dbaron.org/mozilla/visited-privacy Preventing attacks on a user's history through CSS :visited selectors]<br />
* documentation<br />
** [http://www-archive.mozilla.org/newlayout/doc/style-system.html style system documentation] (somewhat out of date)<br />
<br />
=== Layout ===<br />
<br />
Much of the layout code deals with operations on the frame tree (or<br />
rendering tree). In the frame tree, each node represents a rectangle<br />
(or, for SVG, other shapes). The frame tree has a shape similar to the<br />
content tree, since many content nodes have one corresponding frame,<br />
though it differs in a few ways, since some content nodes have more than<br />
one frame or don't have any frames at all. When elements are<br />
display:none in CSS or undisplayed for certain other reasons, they won't<br />
have any frames. When elements are broken across lines or pages, they<br />
have multiple frames; elements may also have multiple frames when<br />
multiple frames nested inside each other are needed to display a single<br />
element (for example, a table, a table cell, or many types of form<br />
controls).<br />
<br />
Each node in the frame tree is an instance of a class derived from<br />
<code>nsIFrame</code>. As with the content tree, there is a substantial<br />
type hierarchy, but the type hierarchy is very different: it includes<br />
types like text frames, blocks and inlines, the various parts of tables,<br />
and the various types of HTML form controls.<br />
<br />
Frames are allocated within an arena owned by the pres shell. Each<br />
frame is owned by its parent; frames are not reference counted, and code<br />
must not hold on to pointers to frames. To mitigate potential security<br />
bugs when pointers to destroyed frames, we use<br />
[http://robert.ocallahan.org/2010/10/mitigating-dangling-pointer-bugs-using_15.html frame poisoning], which takes two parts. When a frame is destroyed<br />
other than at the end of life of the presentation, we fill its memory<br />
with a pattern consisting of a repeated pointer to inaccessible memory,<br />
and then put the memory on a per-frame-class freelist. This means that<br />
if code accesses the memory through a dangling pointer, it will either<br />
crash quickly by dereferencing the poison pattern or it will find a<br />
valid frame.<br />
<br />
Like the content tree, frames must be accessed only from the UI thread.<br />
<br />
The frame tree should not store any important data. While it does<br />
usually persist while a page is being displayed, frames are often<br />
destroyed and recreated in response to certain style changes, and in the<br />
future we may do the same to reduce memory use for pages that are<br />
currently inactive. There were a number of cases where this rule was<br />
violated in the past and we stored important data in the frame tree;<br />
however, most (though not quite all) such cases are now fixed.<br />
<br />
The rectangle represented by the frame is what CSS calls the element's<br />
border box. This is the outside edge of the border (or the inside edge<br />
of the margin). The margin lives outside the border; and the padding<br />
lives inside the border. In addition to nsIFrame::GetRect, we also have<br />
the APIs nsIFrame::GetPaddingRect to get the padding box (the outside<br />
edge of the padding, or inside edge of the border) and<br />
nsIFrame::GetContentRect to get the content box (the outside edge of the<br />
content, or inside edge of the padding). These APIs may produce out of<br />
date results when reflow is needed (or has not yet occurred).<br />
<br />
In addition to tracking a rectangle, frames also track two overflow<br />
areas: visual overflow and scrollable overflow. These overflow areas<br />
represent the union of the area needed by the frame and by all its<br />
descendants. The visual overflow is used for painting-related<br />
optimizations: it is a rectangle covering all of the area that might be<br />
painted when the frame and all of its descendants paint. The scrollable<br />
overflow represents the area that the user should be able to scroll to<br />
to see the frame and all of its descendants. In some cases differences<br />
between the frame's rect and its overflow happen because of descendants<br />
that stick out of the frame; in other cases they occur because of some<br />
characteristic of the frame itself. The two overflow areas are<br />
similar, but there are differences: for example, margins are part of<br />
scrollable overflow but not visual overflow, whereas text-shadows are<br />
part of visual overflow but not scrollable overflow.<br />
<br />
When frames are broken across lines, columns, or pages, we create<br />
multiple frames representing the multiple rectangles of the element.<br />
The first one is the primary frame, and the rest are its continuations<br />
(which are more likely to be destroyed and recreated during reflow).<br />
These frames are linked together as continuations: they have a<br />
doubly-linked list that can be used to traverse the continuations using<br />
nsIFrame::GetPrevContinuation and nsIFrame::GetNextContinuation.<br />
(Currently continuations always have the same style data, though we may<br />
at some point want to break that invariant.)<br />
<br />
Continuations are sometimes siblings of each other, and sometimes not.<br />
For example, if a paragraph contains a span which contains a link, and<br />
the link is split across lines, then the continuations of the span are<br />
siblings (since they are both children of the paragraph), but the<br />
continuations of the link are not siblings (since each continuation of<br />
the link is descended from a different continuation of the span).<br />
Traversing the entire frame tree does '''not''' require considering<br />
continuations, since all of the continuations are descendants of the<br />
element containing the break.<br />
<br />
We also use continuations for cases (most importantly, bidi reordering,<br />
where left-to-right text and right-to-left text need to be separated<br />
into different continuations since they may not form a contiguous<br />
rectangle) where the continuations should not be rewrapped during<br />
reflow: we call these continuations fixed rather than fluid.<br />
nsIFrame::GetNextInFlow and nsIFrame::GetPrevInFlow traverse only the<br />
fluid continuations and do not cross fixed continuation boundaries.<br />
<br />
If an inline frame has non-inline children, then we split the original <br />
inline frame into parts. The original inline's children are <br />
distributed into these parts like so- The children of the original <br />
inline are grouped into runs of inline and non-inline and runs of <br />
inline get an inline parent while runs of non-inline get an anonymous <br />
block parent. This is 'ib-splitting' or block-inside-inline-splitting. <br />
This splitting proceeds recursively up the frame tree until all <br />
non-inlines inside inlines are ancestors of a block frame with anonymous <br />
block wrappers in between. This splitting maintains the relative order<br />
between these child frames and the relationship between the parts of a <br />
split inline is maintained using an ib-sibling chain. It is important <br />
to note that any wrappers created during frame construction (such as <br />
for tables) may not be included in the ib-sibling chain depending on <br />
when this wrapper creation takes place. <br />
<br />
TODO: nsBox craziness from https://bugzilla.mozilla.org/show_bug.cgi?id=524925#c64<br />
<br />
TODO: link to documentation of block and inline layout<br />
<br />
TODO: link to documentation of scrollframes<br />
<br />
TODO: link to documentation of XUL frame classes<br />
<br />
Code (note that most files in base and generic have useful one line descriptions at the top that show up in DXR):<br />
* [http://dxr.mozilla.org/mozilla-central/source/layout/base/ layout/base/] contains objects that coordinate everything and a bunch of other miscellaneous things<br />
* [http://dxr.mozilla.org/mozilla-central/source/layout/generic/ layout/generic/] contains the basic frame classes as well as support code for their reflow methods (ReflowInput, ReflowOutput)<br />
* [http://dxr.mozilla.org/mozilla-central/source/layout/forms/ layout/forms/] contains frame classes for HTML form controls<br />
* [http://dxr.mozilla.org/mozilla-central/source/layout/tables/ layout/tables/] contains frame classes for CSS/HTML tables<br />
* [http://dxr.mozilla.org/mozilla-central/source/layout/mathml/ layout/mathml/] contains frame classes for MathML<br />
* [http://dxr.mozilla.org/mozilla-central/source/layout/svg/ layout/svg/] contains frame classes for SVG<br />
* [http://dxr.mozilla.org/mozilla-central/source/layout/xul/ layout/xul/] contains frame classes for the XUL box model and for various XUL widgets<br />
<br />
Bugzilla:<br />
* All of the components whose names begin with "Layout" in the "Core" product<br />
<br />
==== Frame Construction ====<br />
<br />
Frame construction is the process of creating frames. This is done when styles change in ways that require frames to be created or recreated or when nodes are inserted into the document. The content tree and the frame tree don't have quite the same shape, and the frame construction process does some of the work of creating the right shape for the frame tree. It handles the aspects of creating the right shape that don't depend on layout information. So for example, frame construction handles the work needed to implement [http://www.w3.org/TR/CSS21/tables.html#anonymous-boxes table anonymous objects] but does not handle frames that need to be created when an element is broken across lines or pages.<br />
<br />
The basic unit of frame construction is a run of contiguous children of a single parent element. When asked to construct frames for such a run of children, the frame constructor first determines, based on the siblings and parent of the nodes involved, where in the frame tree the new frames should be inserted. Then the frame constructor walks through the list of content nodes involved and for each one creates a temporary data structure called a '''frame construction item'''. The frame construction item encapsulates various information needed to create the frames for the content node: its style data, some metadata about how one would create a frame for this node based on its namespace, tag name, and styles, and some data about what sort of frame will be created. This list of frame construction items is then analyzed to see whether constructing frames based on it and inserting them at the chosen insertion point will produce a valid frame tree. If it will not, the frame constructor either fixes up the list of frame construction items so that the resulting frame tree would be valid or throws away the list of frame construction items and requests the destruction and re-creation of the frame for the parent element so that it has a chance to create a list of frame construction items that it <em>can</em> fix up.<br />
<br />
Once the frame constructor has a list of frame construction items and an insertion point that would lead to a valid frame tree, it goes ahead and creates frames based on those items. Creation of a non-leaf frame recursively attempts to create frames for the children of that frame's element, so in effect frames are created in a depth-first traversal of the content tree.<br />
<br />
The vast majority of the code in the frame constructor, therefore, falls into one of these categories:<br />
* Code to determine the correct insertion point in the frame tree for new frames.<br />
* Code to create, for a given content node, frame construction items. This involves some searches through static data tables for metadata about the frame to be created.<br />
* Code to analyze the list of frame construction items.<br />
* Code to fix up the list of frame construction items.<br />
* Code to create frames from frame construction items.<br />
<br />
Code: [http://dxr.mozilla.org/mozilla-central/source/layout/base/nsCSSFrameConstructor.h layout/base/nsCSSFrameConstructor.h] and [http://dxr.mozilla.org/mozilla-central/source/layout/base/nsCSSFrameConstructor.cpp layout/base/nsCSSFrameConstructor.cpp]<br />
<br />
==== Reflow ====<br />
<br />
Reflow is the process of computing the positions and sizes of frames. (After all,<br />
frames represent rectangles, and at some point we need to figure out<br />
exactly *what* rectangle.) Reflow is done recursively, with each<br />
frame's Reflow method calling the Reflow methods on that frame's<br />
descendants.<br />
<br />
In many cases, the correct results are defined by CSS specifications<br />
(particularly [http://www.w3.org/TR/CSS21/visudet.html CSS 2.1]). In some cases, the details are not defined by<br />
CSS, though in some (but not all) of those cases we are constrained by<br />
Web compatibility. When the details are defined by CSS, however, the<br />
code to compute the layout is generally structured somewhat differently<br />
from the way it is described in the CSS specifications, since the CSS<br />
specifications are generally written in terms of constraints, whereas<br />
our layout code consists of algorithms optimized for incremental<br />
recomputation.<br />
<br />
The reflow generally starts from the root of the frame tree, though some other<br />
types of frame can act as reflow roots and start a reflow from them.<br />
Reflow roots must obey the invariant that a change inside one of their<br />
descendants never changes their rect or overflow areas (though currently<br />
scrollbars are reflow roots but don't quite obey this invariant).<br />
<br />
In many cases, we want to reflow a part of the frame tree, and we want<br />
this reflow to be efficient. For example, when content is added or<br />
removed from the document tree or when styles change, we want the amount<br />
of work we need to redo to be proportional to the amount of content. We<br />
also want to efficiently handle a series of changes to the same content.<br />
<br />
To do this, we maintain two bits on frames:<br />
[http://dxr.mozilla.org/mozilla-central/search?q=var%3ANS_FRAME_IS_DIRTY&case=true&redirect=true NS_FRAME_IS_DIRTY]<br />
indicates that a frame and all of its descendants require reflow.<br />
[http://dxr.mozilla.org/mozilla-central/search?q=var%3ANS_FRAME_HAS_DIRTY_CHILDREN&case=true&redirect=true NS_FRAME_HAS_DIRTY_CHILDREN]<br />
indicates that a frame has a descendant that<br />
is dirty or has had a descendant removed (i.e., that it has a child that<br />
has NS_FRAME_IS_DIRTY or NS_FRAME_HAS_DIRTY_CHILDREN or it had a child<br />
removed). These bits allow coalescing of multiple updates; this<br />
coalescing is done in nsPresShell, which tracks the set of reflow roots<br />
that require reflow. The bits are set during calls to<br />
nsPresShell::FrameNeedsReflow and are cleared during reflow.<br />
<br />
The layout algorithms used by many of the frame classes are those<br />
specified in CSS, which are based on the traditional document formatting<br />
model, where widths are input and heights are output.<br />
<br />
In some cases, however, widths need to be determined based on the<br />
content. This depends on two ''intrinsic widths'': the minimum<br />
intrinsic width (see [http://dxr.mozilla.org/search?q=type%3AnsIFrame%20function%3AGetMinWidth&tree=mozilla-central nsIFrame::GetMinWidth]) and the preferred intrinsic<br />
width (see [http://dxr.mozilla.org/search?q=type%3AnsIFrame%20function%3AGetPrefWidth&tree=mozilla-central nsIFrame::GetPrefWidth]). The concept of what these widths<br />
represent is best explained by describing what they are on a paragraph<br />
containing only text: in such a paragraph the minimum intrinsic width<br />
is the width of the longest word, and the preferred intrinsic width is<br />
the width of the entire paragraph laid out on one line.<br />
<br />
Intrinsic widths are invalidated separately from the dirty bits<br />
described above. When a caller informs the pres shell that a frame<br />
needs reflow (nsIPresShell::FrameNeedsReflow), it passes one of three<br />
options:<br />
* eResize indicates that no intrinsic widths are dirty<br />
* eTreeChange indicates that intrinsic widths on it and its ancestors are dirty (which happens, for example, if new children are added to it)<br />
* eStyleChange indicates that intrinsic widths on it, its ancestors, and its descendants are dirty (for example, if the font-size changes)<br />
<br />
Reflow is the area where the XUL frame classes (those that inherit from<br />
nsBoxFrame or nsLeafBoxFrame) are most different from the rest. Instead<br />
of using nsIFrame::Reflow, they do their layout computations using<br />
intrinsic size methods called GetMinSize, GetPrefSize, and GetMaxSize<br />
(which report intrinsic sizes in two dimensions) and a final layout<br />
method called Layout. In many cases these methods defer some of the<br />
computation to a separate object called a layout manager.<br />
<br />
When an individual frame's Reflow method is called, most of the input is<br />
provided on an object called ReflowInput and the output is filled<br />
in to an object called ReflowOutput. After reflow, the caller<br />
(usually the parent) is responsible for setting the frame's size based<br />
on the metrics reported. (This can make some computations during reflow<br />
difficult, since the new size is found in either the reflow state or the<br />
metrics, but the frame's size is still the old size. However, it's<br />
useful for invalidating the correct areas that need to be repainted.)<br />
<br />
One major difference worth noting is that in XUL layout, the size of the<br />
child is set prior to its parent calling its Layout method. (Once<br />
invalidation uses display lists and is no longer tangled up in Reflow,<br />
it may be worth switching non-XUL layout to work this way as well.)<br />
<br />
==== Painting ====<br />
<br />
TODO: display lists (and event handling)<br />
<br />
TODO: layers<br />
<br />
==== Pagination ====<br />
<br />
The concepts behind pagination (also known as fragmentation) are a bit complicated, so for now we've split them off into a separate document: [[Gecko:Continuation_Model]]. This code is used for printing, print-preview, and multicolumn frames.<br />
<br />
=== Dynamic change handling along the rendering pipeline ===<br />
<br />
The ability to make changes to the DOM from script is a major feature of the Web platform. Web authors rely on the concept (though there are a few exceptions, such as animations) that changing the DOM from script leads to the same rendering that would have resulted from starting from that DOM tree. They also rely on the performance characteristics of these changes: small changes to the DOM that have small effects should have proportionally small processing time. This means that Gecko needs to efficiently propagate changes from the content tree to style, the frame tree, the geometry of the frame tree, and the screen.<br />
<br />
For many types of changes, however, there is substantial overhead to processing a change, no matter how small. For example, reflow must propagate from the top of the frame tree down to the frames that are dirty, no matter how small the change. One very common way around this is to batch up changes. We batch up changes in lots of ways, for example:<br />
* The content sink adds multiple nodes to the DOM tree before notifying listeners that they've been added. This allows notifying once about an ancestor rather than for each of its descendants, or notifying about a group of descendants all at once, which speeds up the processing of those notifications.<br />
* We batch up nodes that require style reresolution (recomputation of selector matching and processing the resulting style changes). This batching is tree based, so it not only merges multiple notifications on the same element, but also merges a notification on an ancestor with a notification on its descendant (since ''some'' of these notifications imply that style reresolution is required on all descendants).<br />
* We wait to reconstruct frames that require reconstruction (after destroying frames eagerly). This, like the tree-based style reresolution batching, avoids duplication both for same-element notifications and ancestor-descendant notifications, even though it doesn't actually do any tree-based caching.<br />
* We postpone doing reflows until needed. As for style reresolution, this maintains tree-based dirty bits (see the description of NS_FRAME_IS_DIRTY and NS_FRAME_HAS_DIRTY_CHILDREN under Reflow).<br />
* We allow the OS to queue up multiple invalidates before repainting (though we will likely switch to controlling that ourselves). This leads to a single repaint of some set of pixels where there might otherwise have been multiple (though it may also lead to more pixels being repainted if multiple rectangles are merged to a single one).<br />
<br />
Having changes buffered up means, however, that various pieces of information (layout, style, etc.) may not be up-to-date. Some things require up-to-date information: for example, we don't want to expose the details of our buffering to Web page script since the programming model of Web page script assumes that DOM changes take effect "immediately", i.e., that the script shouldn't be able to detect any buffering. Many Web pages depend on this.<br />
<br />
We therefore have ways to flush these different sorts of buffers. There are methods called FlushPendingNotifications on nsIDocument and nsIPresShell, that take an argument of what things to flush:<br />
* Flush_Content: create all the content nodes from data buffered in the parser<br />
* Flush_ContentAndNotify: the above, plus notify document observers about the creation of all nodes created so far<br />
* Flush_Style: the above, plus make sure style data are up-to-date<br />
* Flush_Frames: the above, plus make sure all frame construction has happened (currently the same as Flush_Style)<br />
* Flush_InterruptibleLayout: the above, plus perform layout (Reflow), but allow interrupting layout if it takes too long<br />
* Flush_Layout: the above, plus ensure layout (Reflow) runs to completion<br />
* Flush_Display (should never be used): the above, plus ensure repainting happens<br />
<br />
The major way that notifications of changes propagate from the content code to layout and other areas of code is through the nsIDocumentObserver and nsIMutationObserver interfaces. Classes can implement this interface to listen to notifications of changes for an entire document or for a subtree of the content tree.<br />
<br />
WRITE ME: ... layout document observer implementations<br />
<br />
TODO: how style system optimizes away rerunning selector matching<br />
<br />
TODO: style changes and nsChangeHint<br />
<br />
=== Refresh driver ===<br />
<br />
== Graphics ==<br />
[https://wiki.mozilla.org/Platform/GFX Wiki page] | [https://wiki.mozilla.org/index.php?title=Platform/GFX/Contribute contribute]<br />
<br />
==== Painting/Rasterizing ====<br />
<br />
Painting/rendering/rasterizing is the step where graphical primitives (such as a command to fill an [https://developer.mozilla.org/en-US/docs/Web/SVG SVG] circle, or a [https://developer.mozilla.org/en-US/docs/Web/Guide/Graphics/Drawing_graphics_with_canvas canvas] command to stroke a path between x, y, z, or the internally produced command to draw the edge of an HTML div's border) are used to color in the pixels of a surface so that the surface "displays" those rasterized primitives.<br />
<br />
The platform independent library that gecko uses to render is [http://dxr.mozilla.org/mozilla-central/source/gfx/2d/2D.h Moz2D]. Gecko code paints into Moz2D DrawTarget objects (the DrawTarget baseclass having multiple platform dependent subclasses). (At least this is where gecko is going - for now there is still significant amounts of code that uses [http://dxr.mozilla.org/mozilla-central/source/gfx/thebes/gfxContext.h Thebes gfxContext] objects or the even older nsRenderingContext objects. Objects of these types now always wrap a DrawTarget so all painting does now go through Moz2D, but conversion to use the wrapped DrawTargets directly is taking time since consumer code can sometimes need to be radically rewritten to fit the Moz2D API and immediate mode paradigm.)<br />
<br />
==== Compositing ====<br />
<br />
The compositing stage of the rendering pipeline is operated by the [http://dxr.mozilla.org/mozilla-central/source/gfx/layers/ gfx/layers] module.<br />
<br />
Different parts of a web page can sometimes be painted into intermediate surfaces retained by layers. It can be convenient to think of layers as the layers in image manipulation programs like The Gimp or Photoshop. Layers are organized as a tree. Layers are primarily used to minimize invalidating and repainting when elements are being animated independently of one another in a way that can be optimized using layers (e.g. opacity or transform animations), and to enable some effects (such as transparency and 3D transforms).<br />
<br />
Compositing is the action of flattening the layers into the final image that is shown on the screen.<br />
<br />
On some platform, compositing happens on the Content thread. However, on other platforms we composite on a separate thread (Off-main-thread compositing, or OMTC). OMTC is at the moment the default behavior on mobile platforms, but the goal is to do it on all platforms in the long run.<br />
<br />
The Layers architecture is built on the following notions:<br />
* Compositor: an object that can draw quads on the screen (or on an off-screen render target).<br />
* Texture: an object that contains image data.<br />
* Compositable: an object that can manipulate one or several textures, and knows how to present them to the compositor<br />
* Layer: an element of the layer tree. A layer usually doesn't know much about compositing: it uses a compositable to do the work. Layers are mostly nodes of the layer tree.<br />
<br />
[[File:LayersRefactoring.png|thumb|650px|New layers architecture, with OGL backend]]<br />
<br />
The above abstractions are sufficient to perform compositing on the main thread, but on the OMTC case, we need a mechanism to synchronize a client layer tree that is constructed on the content thread, and a host layer tree that is used for compositing on the compositor thread.<br />
This synchronization process must ensure that the host layer tree reflects the state of the current layer tree while remaining in a consistent state, and must transfer texture data from a thread to the other. Moreover, on some platforms the content and compositor threads may live in separate processes.<br />
<br />
To perform this synchronization, we use the IPDL IPC framework. IPDL lets us describe communications protocols and actors in a domain specific language. for more information about IPDL, read https://wiki.mozilla.org/IPDL<br />
<br />
When the client layer tree is modified, we record modifications into messages that are sent together to the host side within a transaction. A transaction is basically a list of modifications to the layer tree that have to be applied all at once to preserve consistency in the state of the host layer tree.<br />
<br />
Texture transfer is done by synchronizing texture objects across processes/threads using a couple TextureClient/TextureHost that wrap shared data and provide access to it on both sides. TextureHosts provide access to one or several TextureSource, which has the necessary API to actually composite the texture (TextureClient/Host being more about IPC synchronization than actual compositing.<br />
The logic behind texture transfer (as in single/double/triple buffering, texture tiling, etc) is operated by the CompositableClient and CompositableHost.<br />
<br />
It is important to understand the separation between layers and compositables. Compositables handle all the logic around texture transfer, while layers define the shape of the layer tree. a Compositable is created independently from a layer and attached to it on both sides. While layers transactions can only originate from the content thread, this separation makes it possible for us to have separate compositable transactions between any thread and the compositor thread. We use the ImageBridge IPDL protocol to that end. The Idea of ImageBridge is to create a Compositable that is manipulated on the ImageBridgeThread, and that can transfer/synchronize textures without using the content thread at all. This is very useful for smooth Video compositing: video frames are decoded and passed into the ImageBridge without ever touching the content thread, which could be busy processing reflows or heavy javascript workloads.<br />
<br />
It is worth reading the inline code documentation in the following files:<br />
* [http://dxr.mozilla.org/mozilla-central/source/gfx/layers/Compositor.h gfx/layers/Compositor.h]<br />
* [http://dxr.mozilla.org/mozilla-central/source/gfx/layers/ShadowLayers.h gfx/layers/ShadowLayers.h]<br />
* [http://dxr.mozilla.org/mozilla-central/source/gfx/layers/Layers.h gfx/layers/Layers.h]<br />
* [http://dxr.mozilla.org/mozilla-central/source/gfx/layers/host/TextureHost.h gfx/layers/host/TextureHost.h]<br />
* [http://dxr.mozilla.org/mozilla-central/source/gfx/layers/client/CompositableClient.h gfx/layers/client/CompositableClient.h]<br />
<br />
To visualize how a web page is layered, turn on the pref "layers.draw-borders" in about:config. When this pref is on, the borders of layers and tiles are displayed on top of the content. This only works when using the new Compositor API, that is when off-main-thread compositing is activated. OMTC is activated by default on all mobile platforms, and will progressively get activated on desktop platforms (not yet, though). On platforms where OMTC is not used, this pref has no effect. <br />
<br />
Blog posts with information on Layers that should be integrated here:<br />
<br />
* [http://www.basschouten.com/blog1.php/layers-cross-platform-acceleration Layers: Cross-Platform Acceleration]<br />
* [http://robert.ocallahan.org/2010/04/layers_01.html Layers]<br />
* [http://robert.ocallahan.org/2010/07/retained-layers_16.html Retained Layers]<br />
* [http://chrislord.net/index.php/2011/07/25/shadow-layers-and-learning-by-failing/ Shadow Layers, and learning by failing]<br />
* [http://chrislord.net/index.php/2011/08/16/accelerated-layer-rendering-and-learning-by-some-success/ Accelerated layer-rendering, and learning by (some) success]<br />
* [http://featherweightmusings.blogspot.co.uk/2012/05/mask-layers_26.html Mask Layers]<br />
* [http://featherweightmusings.blogspot.co.uk/2012/05/building-mask-layer.html Building a mask layer]<br />
* [http://featherweightmusings.blogspot.co.uk/2012/06/mask-layers-on-direct3d-backends.html Mask Layers on the Direct3D backends]<br />
* [http://robert.ocallahan.org/2011/09/graphics-api-design.html Graphics API Design]<br />
<br />
==== Async Panning and Zooming ====<br />
<br />
On some of our mobile platforms we have some code that allows the user to do asynchronous (i.e. off-main-thread) panning and zooming of content. This code is the Async Pan/Zoom module (APZ) code and is further documented at [[Platform/GFX/APZ]].<br />
<br />
== Scripting ==<br />
<br />
=== JavaScript Engine ===<br />
<br />
Gecko embeds the SpiderMonkey JavaScript engine (located in js/src). The JS engine includes a number of Just-In-Time compilers (or JITs). SpiderMonkey provides a powerful and extensive embedding API (called the JSAPI). Because of its complexity, using the JSAPI directly is frowned upon, and a number of abstractions have been built in Gecko to allow interacting with the JS engine without using JSAPI directly. Some JSAPI concepts are important for Gecko developers to understand, and they are listed below:<br />
<br />
* Global object: The '''global object''' is the object on which all global variables/properties/methods live. In a web page this is the 'window' object. In other things such as XPCOM components or sandboxes XPConnect creates a global object with a small number of builtin APIs.<br />
* Compartments: A '''compartment''' is a subdivision of the JS heap. The mapping from global objects to compartments is one-to-one; that is, every global object has a compartment associated with it, and no compartment is associated with more than one global object. (NB: There are compartments associated with no global object, but they aren't very interesting). When JS code is running SpiderMonkey has a concept of a "current" compartment. New objects that are created will be created in the "current" compartment and associated with the global object of that compartment.<br />
* When objects in one compartment can see objects in another compartment (via e.g. iframe.contentWindow.foo) '''cross-compartment wrappers''' or '''CCWs''' mediate the interaction between the two compartments. By default CCWs ensure that the current compartment is kept up-to-date when execution crosses a compartment boundary. SpiderMonkey also allows embeddings to extend wrappers with custom behavior to implement security policies, which Gecko uses extensively (see the Security section for more information).<br />
<br />
=== XPConnect ===<br />
<br />
'''XPConnect''' is a bridge between C++ and JS used by XPCOM components exposed to or implemented in JavaScript. XPConnect allows two XPCOM components to talk to each other without knowing or caring which language they are implemented in. XPConnect allows JS code to call XPCOM components by exposing XPCOM interfaces as JS objects, and mapping function calls and attributes from JS into virtual method calls on the underlying C++ object. It also allows JS code to implement an XPCOM component that can be called from C++ by faking the vtable of an interface and translating calls on the interface into JS calls. XPConnect accomplishes this using the vtable data stored in XPCOM TypeLibs (or XPT files) by the XPIDL compiler and a small layer of platform specific code called [https://developer.mozilla.org/en-US/docs/xptcall_FAQ xptcall] that knows how to interact with and impersonate vtables of XPCOM interfaces.<br />
<br />
XPConnect is also used for a small (and decreasing) number of legacy DOM objects. At one time all of the DOM used XPConnect to talk to JS, but we have been replacing XPConnect with the WebIDL bindings (see the next section for more information). Arbitrary XPCOM components are not exposed to web content. XPCOM components that want to be accessible to web content must provide class info (that is, they must QI to nsIClassInfo) and must be marked with the nsIClassInfo::DOM_OBJECT flag. Most of these objects also are listed in dom/base/nsDOMClassInfo.cpp, where the interfaces that should be visible to the web are enumerated. This file also houses some "scriptable helpers" (classes ending in "SH" and implementing nsIXPCScriptable), which are a set of optional hooks that can be used by XPConnect objects to implement more exotic behaviors (such as indexed getters or setters, lazily resolved properties, etc). This is all legacy code, and any new DOM code should use the WebIDL bindings.<br />
<br />
=== WebIDL Bindings ===<br />
<br />
The '''WebIDL bindings''' are a separate bridge between C++ and JS that is specifically designed for use by DOM code. We intend to replace all uses of XPConnect to interface with content JavaScript with the WebIDL bindings. [https://developer.mozilla.org/en-US/docs/Mozilla/WebIDL_bindings Extensive documentation] on the WebIDL bindings is available, but the basic idea is that a binding generator takes WebIDL files from web standards and some configuration data provided by us and generates at build time C++ glue code that sits between the JS engine and the DOM object. This setup allows us to produce faster, more specialized code for better performance at the cost of increased codesize.<br />
<br />
The WebIDL bindings also implement all of the behavior specified in WebIDL, making it possible for new additions to the DOM to behave correctly "out of the box". The binding layer also provides C++ abstractions for types that would otherwise require direct JSAPI calls to handle, such as typed arrays. <br />
<br />
=== Security ===<br />
<br />
Gecko's JS security model is based on the concept of compartments. Every compartment has a '''principal''' associated with it that contains security information such as the '''origin''' of the compartment, whether or not it has system privileges, etc. For the following discussion, '''wrappee''' refers to the underlying object being wrapped, '''scope''' refers to the compartment the object is being wrapped for use in, and '''wrapper''' refers to the object created in '''scope''' that allows it to interact with '''wrappee'''. "Chrome" refers to JS that is built in to the browser or part of an extension, which runs with full privileges, and is contrasted with "content", which is web provided script that is subject to security restrictions and the same origin policy.<br />
<br />
* Xray wrappers: Xray wrappers are used when the scope has chrome privileges and the wrappee is the JS reflection of an underlying DOM object. Beyond the usual CCW duties of making sure that content code does not run with chrome privileges, Xray wrappers also ensure that calling methods or accessing attributes on the wrappee has the "expected" effect. For example, a web page could replace the <code>close</code> method on its window with a JS function that does something completely different. (e.g. <code>window.close = function() { alert("This isn't what you wanted!") };</code>). Overwriting methods in this way (or creating entirely new ones) is referred to as '''expando''' properties. Xrays see through expando properties, invoking the original method/getter/setter if the expando overwrites a builtin or seeing undefined in the expando creates a new property. This allows chrome code to call methods on content DOM objects without worrying about how the page has changed the object.<br />
* Waived xray wrappers: The xray behavior is not always desirable. It is possible for chrome to "waive" the xray behavior and see the actual JS object. The wrapper still guarantees that code runs with the correct privileges, but methods/getters/setters may not behave as expected. This is equivalent to the behavior chrome sees when it looks at non-DOM content JS objects.<br />
* For more information, see the [https://developer.mozilla.org/en-US/docs/Mozilla/Gecko/Script_security MDN page]<br />
* bholley's [https://air.mozilla.org/enter-the-compartment/ Enter the Compartment] talk also provides an overview of our compartment architecture.<br />
<br />
== Images ==<br />
<br />
== Plugins ==<br />
<br />
== Platform-specific layers ==<br />
<br />
* widget<br />
* native theme<br />
* files, networking, other low-level things<br />
* Accessibility APIs<br />
* Input. Touch-input stuff is somewhat described at [[Platform/Input/Touch]].<br />
<br />
== Editor ==<br />
<br />
== Base layers ==<br />
<br />
=== NSPR ===<br />
<br />
NSPR is a library for providing cross-platform APIs for various<br />
platform-specific functions. We tend to be trying to use it as little<br />
as possible, although there are a number of areas (particularly some<br />
network-related APIs and threading/locking primitives) where we use it<br />
quite a bit.<br />
<br />
=== XPCOM ===<br />
<br />
XPCOM is a cross-platform modularity library, modeled on Microsoft COM. It<br />
is an object system in which all objects inherit from the <code>nsISupports</code> interface.<br />
<br />
components and services, contract IDs and CIDs<br />
<br />
prior overuse of XPCOM; littering with XPCOM does not produce modularity<br />
<br />
Base headers (part of xpcom/base/) and data structures. See also mfbt.<br />
<br />
Threading<br />
<br />
xptcall, proxies<br />
<br />
reference counting, cycle collection<br />
<br />
Further documentation:<br />
* XPCOM and Internal Strings in Gecko (talk by David Baron, 2014-03-20): [https://air.mozilla.org/xpcom-and-internal-strings-in-gecko/ video], [https://dbaron.org/talks/2014-03-20-xpcom-string-taipei/speaking-notes speaking notes]<br />
<br />
=== String ===<br />
<br />
XPCOM has string classes for representing sequences of characters. Typical C++ string classes have the goals of encapsulating the memory management of buffers and the issues needed to avoid buffer overruns common in traditional C string handling. Mozilla's string classes have these goals, and also the goal of reducing copying of strings.<br />
<br />
(There is a second set of string classes in xpcom/glue for callers outside of libxul; these classes are partially source-compatible but have different (worse) performance characteristics. This discussion does not cover those classes.)<br />
<br />
We have two parallel sets of classes, one for strings with 1-byte units (<code>char</code>, which may be signed or unsigned), and one for strings with 2-byte units (<code>char16_t</code>, always unsigned). The classes are named such that the class for 2-byte characters ends with <code>String</code> and the corresponding class for 1-byte characters ends with <code>CString</code>. 2-byte strings are almost always used to encode [http://en.wikipedia.org/wiki/UTF-16 UTF-16]. 1-byte strings are usually used to encode either [http://en.wikipedia.org/wiki/ASCII ASCII] or [http://en.wikipedia.org/wiki/UTF-8 UTF-8], but are sometimes also used to hold data in some other encoding or just byte sequences.<br />
<br />
The string classes distinguish, as part of the type hierarchy, between strings that must have a null-terminator at the end of their buffer (<code>ns[C]String</code>) and strings that are not required to have a null-terminator (<code>ns[C]Substring</code>). <code>ns[C]Substring</code> is the base of the string classes (since it imposes fewer requirements) and <code>ns[C]String</code> is a class derived from it. Functions taking strings as parameters should generally take one of these four types.<br />
<br />
In order to avoid unnecessary copying of string data (which can have significant performance cost), the string classes support different ownership models. All string classes support the following three ownership models dynamically:<br />
* reference counted, copy-on-write, buffers (the default)<br />
* adopted buffers (a buffer that the string class owns, but is not reference counted, because it came from somewhere else)<br />
* dependent buffers, that is, an underlying buffer that the string class does not own, but that the caller that constructed the string guarantees will outlive the string instance<br />
In addition, there is a special string class, <code>nsAuto[C]String</code>, that ''additionally'' contains an internal 64-unit buffer (intended primarily for use on the stack), leading to a fourth ownership model:<br />
* storage within an auto string's stack buffer<br />
Auto strings will prefer reference counting an existing reference-counted buffer over their stack buffer, but will otherwise use their stack buffer for anything that will fit in it.<br />
<br />
There are a number of additional string classes, particularly <code>nsDependent[C]String</code>, <code>nsDependent[C]Substring</code>, and the <code>NS_LITERAL_[C]STRING</code> macros which construct an <code>nsLiteral[C]String</code> which exist primarily as constructors for the other types. These types are really just convenient notation for constructing an <code>ns[C]S[ubs]tring</code> with a non-default ownership mode; they should not be thought of as different types. (The <code>Substring</code>, <code>StringHead</code>, and <code>StringTail</code> functions are also constructors for dependent [sub]strings.) Non-default ownership modes can also be set up using the <code>Rebind</code> and <code>Adopt</code> methods, although the <code>Rebind</code> methods actually live on the derived types, which is probably a mistake (although moving them up would require some care to avoid making an API that easily allows assigning a non-null-terminated buffer to a string whose static type indicates that it is null-terminated).<br />
<br />
Note that the presence of all of these classes imposes some awkwardness in terms of distinctions being available as both static type distinctions and dynamic type distinctions. In general, the only distinctions that should be made statically are 1-byte vs. 2-byte sequences (<code>CString</code> vs <code>String</code>) and whether the buffer is null-terminated or not (<code>Substring</code> vs <code>String</code>). (Does the code actually do a good job of dynamically enforcing the <code>Substring</code> vs. <code>String</code> restriction?)<br />
<br />
TODO: buffer growth, concatenation optimizations<br />
<br />
TODO: encoding conversion, what's validated and what isn't<br />
<br />
TODO: "string API", nsAString (historical)<br />
<br />
* Code: xpcom/string/<br />
* Bugzilla: Core::String<br />
<br />
Further documentation:<br />
* XPCOM and Internal Strings in Gecko (talk by David Baron, 2014-03-20): [https://air.mozilla.org/xpcom-and-internal-strings-in-gecko/ video], [https://dbaron.org/talks/2014-03-20-xpcom-string-taipei/speaking-notes speaking notes]</div>Dbaronhttps://wiki.mozilla.org/index.php?title=Gecko:Overview&diff=1193183Gecko:Overview2018-05-02T20:23:52Z<p>Dbaron: /* XPCOM */ add date</p>
<hr />
<div>This document attempts to give an overview of the different parts of<br />
Gecko, what they do, and why they do it, say where the code for them is<br />
within the repository, and link to more specific documentation (when<br />
available) covering the details of that code. '''It is not yet complete.''' Maintainers of these<br />
areas of code should correct errors, add information, and add links to<br />
more detailed documentation (since this document is intended to remain<br />
an overview, not complete documentation).<br />
<br />
__TOC__<br />
<br />
== Browsers, Frames, and Document Navigation ==<br />
<br />
=== Docshell ===<br />
<br />
The user of a Web browser can change the page shown in that browser in<br />
many ways: by clicking a link, loading a new URL, using the forward and<br />
back buttons, or other ways. This can happen inside a space we'll call<br />
a '''browsing context'''; this space can be a browser window, a tab, or a frame<br />
or iframe within a document. The toplevel data structures within Gecko<br />
represent this browsing context; they contain other data structures<br />
representing the individual pages displayed inside of it (most<br />
importantly, the current one). In terms of implementation, these two<br />
types of navigation, the top level of a browser and the frames within<br />
it, largely use the same data structures.<br />
<br />
In Gecko, the '''docshell''' is the toplevel object responsible for<br />
managing a single browsing context. It, and the associated '''session history''' code, <br />
manage the navigation between pages inside of a<br />
docshell. (Note the difference between session history, which is a<br />
sequence of pages in a single browser session, used for recording information<br />
for back and forward navigation, and global history, which is the<br />
history of pages visited and associated times, regardless of browser<br />
session, used for things like link coloring and address autocompletion.)<br />
<br />
There are relatively few objects in Gecko that are associated with a<br />
docshell rather than being associated with a particular one of the pages<br />
inside of it. Most such objects are attached to the docshell. An important object associated with the docshell is the nsGlobalWindowOuter which is what the HTML5 spec refers to as a WindowProxy (into which Window objects, as implemented by nsGlobalWindowInner, are loaded). See the DOM section below for more information on<br />
this.<br />
<br />
The most toplevel object for managing the contents of a particular page<br />
being displayed within a docshell is a document viewer (see layout).<br />
Other important objects associated with this presentation are the<br />
document (see DOM) and the pres(entation) shell and pres(entation)<br />
context (see layout).<br />
<br />
[[File:WebNavigation.png|thumb|400px|<xul:browser>, frameloader and docshell in single process configuration]]<br />
<br />
Docshells are organized into a tree. If a docshell has a non-null parent, then it corresponds to a subframe in whatever page is currently loaded in the parent docshell, and the corresponding subframe element (for example, an iframe) is called a '''browsing context container'''. In Gecko, a browsing context container would implement <code>[https://dxr.mozilla.org/mozilla-central/rev/f9a5e9ed62103c84e4cde915f4d08f1ce71be83e/dom/base/nsIFrameLoader.idl#271 nsIFrameLoaderOwner]</code> to hold a '''frameloader''', which holds and manages the docshell. <br />
<br />
One of the most interfaces docshell implemented is <code>[https://dxr.mozilla.org/mozilla-central/source/docshell/base/nsIWebNavigation.idl nsIWebNavigation]</code>. It defines major functions of a browsing context, such as <code>loadURI</code> / <code>goBack</code> / <code>goForward</code> and <code>reload</code>. In single process configuration of desktop Firefox, <code><xul:browser></code> (which represents a tab) operates on docshell through <code>nsIWebNavigation</code>, as shown in the right figure.<br />
<br />
* code: mozilla/docshell/<br />
* bugzilla: Core::Document Navigation<br />
* documentation: [[DocShell:Home Page]]<br />
<br />
=== Session History ===<br />
<br />
In order to keep the session history of subframes after the root document is unloaded and docshells of subframes are destroyed, only the root docshell of a docshell tree manages the session history (this does not match the conceptual model in the HTML5 spec and may be subject to change).<br />
<br />
As an example to explain the structure of session history implementation in Gecko, consider there's a tab A, which loads document 1; in document 1, there are iframe B & C, which loads document 2 & 3, respectively. Later, an user navigates iframe B to document 4. The following figures show the conceptual model of the example, and the corresponding session history structure.<br />
<br />
{| <br />
| [[File:BrowsingContextExample1.png|thumb|190px|Conceptual model representation; color denotes current visible active documents]]<br />
| [[File:SHistoryExample1.png|thumb|180px|Session history structure; color denotes current transaction / entries]]<br />
|}<br />
<br />
In Gecko, a [https://dxr.mozilla.org/mozilla-central/source/docshell/shistory/nsSHistory.h session history] object holds a list of [https://dxr.mozilla.org/mozilla-central/source/docshell/shistory/nsSHTransaction.h transactions] (denoted as T1 & T2 in the figure); each transaction points to a tree of [https://dxr.mozilla.org/mozilla-central/source/docshell/shistory/nsSHEntry.h entries]; each entry records the docshell it associated to, and a URL. Now that if we navigate the tab to a different root document 5, which includes an iframe D with document 6, then it becomes:<br />
<br />
{| <br />
| [[File:BrowsingContextExample2.png|thumb|275px|Conceptual model representation]]<br />
| [[File:SHistoryExample2.png|thumb|250px|Session history structure]]<br />
|}<br />
<br />
=== Embedding ===<br />
<br />
To be written (and maybe rewritten if we get an IPC embedding API).<br />
<br />
[[File:WebNavigationE10S.png|thumb|500px|<xul:remote-browser>, frameloader and docshell in multiprocess configuration. The horizontal dash-lines represent inter-process communication]]<br />
<br />
=== Multi-process and IPC ===<br />
<br />
In a multi-process desktop Firefox, a tab is managed by <code>[https://dxr.mozilla.org/mozilla-central/source/toolkit/content/widgets/remote-browser.xml <xul:remote-browser>]</code>. It still operates on nsIWebNavigation, but in this case the docshell is in a remote process and can not be accessed directly. The encapsulation of remote nsIWebNavigation is done by the javascript-implemented <code>[https://dxr.mozilla.org/mozilla-central/source/toolkit/components/remotebrowserutils/RemoteWebNavigation.js RemoteWebNavigation]</code>.<br />
<br />
In this configuration, the frameloader of a root docshell lives in parent process, so it can not access docshell directly either. Instead, it holds a <code>[https://dxr.mozilla.org/mozilla-central/source/dom/ipc/TabParent.h TabParent]</code> instance to interact with <code>[https://dxr.mozilla.org/mozilla-central/source/dom/ipc/TabChild.h TabChild]</code> in child-process. At C/C++ level, the communication across processes for a single tab is through the '''PBrowser''' IPC protocol implemented by TabParent and TabChild, while at the javascript level it's done by '''message manager''' (which is ontop of PBrowser). RemoteWebNavigation, for example, sends messages to <code>[https://dxr.mozilla.org/mozilla-central/source/toolkit/content/browser-child.js browser-child.js]</code> in content process through message manager.<br />
<br />
== Networking ==<br />
<br />
The network library Gecko uses is called Necko. Necko APIs are largely organized around three concepts: '''URI objects''', '''protocol handlers''', and '''channels'''.<br />
<br />
=== Protocol handlers ===<br />
A '''protocol handler''' is an XPCOM service associated with a particular URI scheme or network protocol. Necko includes protocol handlers for HTTP, FTP, the data: URI scheme, and various others. Extensions can implement protocol handlers of their own.<br />
<br />
A protocol handler implements the <code>[https://dxr.mozilla.org/mozilla-central/source/netwerk/base/nsIProtocolHandler.idl nsIProtocolHandler]</code> API, which serves three primary purposes:<br />
# Providing metadata about the protocol (its security characteristics, whether it requires actual network access, what the corresponding URI scheme is, what TCP port the protocol uses by default).<br />
# Creating URI objects for the protocol's scheme.<br />
# Creating channel objects for the protocol's URI objects<br />
<br />
Typically, the built-in I/O service (<code>[https://dxr.mozilla.org/mozilla-central/source/netwerk/base/nsIIOService2.idl nsIIOService]</code>) is responsible for finding the right protocol handler for URI object creation and channel creation, while a variety of consumers queries protocol metadata. Querying protocol metadata is the recommended way to handle any sort of code that needs to have different behavior for different URI schemes. In particular, unlike whitelists or blacklists, it correctly handles the addition of new protocols.<br />
<br />
A service can register itself as a protocol handler by registering for the contract ID <code>"@mozilla.org/network/protocol;1?name=SSSSS"</code> where <code>SSSS</code> is the URI scheme for the protocol (e.g. "http", "ftp", and so forth).<br />
<br />
=== URI objects ===<br />
URI objects, which implement the <code>[https://dxr.mozilla.org/mozilla-central/source/netwerk/base/nsIURI.idl nsIURI]</code> API, are a way of representing URIs and IRIs. Their main advantage over strings is that they do basic syntax checking and canonicalization on the URI string that they're provided with. They also provide various accessors to extract particular parts of the URI and provide URI equality comparisons. URIs that correspond to hierarchical schemes implement the additional <code>[https://dxr.mozilla.org/mozilla-central/source/netwerk/base/nsIURL.idl nsIURL]</code> interface, which exposes even more accessors for breaking out parts of the URI.<br />
<br />
URI objects are typically created by calling the <code>newURI</code> method on the I/O service, or in C++ by calling the <code>NS_NewURI</code> utility function. This makes sure to create the URI object using the right protocol handler, which ensures that the right kind of object is created. Direct creation of URIs via <code>createInstance</code> is reserved for protocol handler implementations.<br />
<br />
=== Channels ===<br />
[https://dxr.mozilla.org/mozilla-central/source/netwerk/base/nsIChannel.idl Channels] are the Necko representation of a single request/response interaction with a server. A channel is created by calling the <code>newChannel</code> method on the [https://dxr.mozilla.org/mozilla-central/source/netwerk/base/nsIIOService.idl I/O service], or in C++ by calling the <code>[https://dxr.mozilla.org/mozilla-central/search?q=function%3ANS_NewChannel&case=true NS_NewChannel]</code> utility function. The channel can then be configured as needed, and finally its <code>asyncOpen</code> method can be called. This method takes an <code>[https://dxr.mozilla.org/mozilla-central/source/netwerk/base/nsIStreamListener.idl nsIStreamListener]</code> as an argument.<br />
<br />
If <code>asyncOpen</code> has returned successfully, the channel guarantees that it will asynchronously call the <code>onStartRequest</code> and <code>onStopRequest</code> methods on its stream listener. This will happen even if there are network errors that prevent Necko from actually performing the requests. Such errors will be reported in the channel's status and in the <code>status</code> argument to <code>onStopRequest</code>.<br />
<br />
If the channel ends up being able to provide data, it will make one or more <code>onDataAvailable</code> on its listener after calling <code>onStartRequest</code> and before calling <code>onStopRequest</code>. For each call, the listener is responsible for either returning an error or reading the entire data stream passed in to the call.<br />
<br />
If an error is returned from either <code>onStartRequest</code> or <code>onDataAvailable</code>, the channel must act as if it has been canceled with the corresponding error code.<br />
<br />
A channel has two URI objects associated with it. The <code>originalURI</code> of the channel is the URI that was originally passed to <code>newChannel</code> to create the channel that then had <code>asyncOpen</code> called on it. The <code>URI</code> is the URI from which the channel is reading data. These can be different in various cases involving protocol handlers that forward network access to other protocol handlers, as well as in situations in which a redirect occurs (e.g. following an HTTP 3xx response). In redirect situations, a new channel object will be created, but the originalURI will be propagated from the old channel to the new channel.<br />
<br />
Note that the <code>nsIRequest</code> that's passed to onStartRequest must match the one passed to onDataAvailable and onStopRequest, but need not be the original channel that asyncOpen was called on. In particular, when an HTTP redirect happens the request argument to the callbacks will be the post-redirect channel.<br />
<br />
TODO: crypto?<br />
<br />
== Document rendering pipeline ==<br />
<br />
Some of the major components of Gecko can be described as steps on the<br />
path from an HTML document coming in from the network to the graphics<br />
commands needed to render that document. An HTML document is a<br />
serialization of a tree structure. (FIXME: add diagram) The HTML<br />
parser and content sink create an in-memory representation of this tree,<br />
which we call the '''DOM tree''' or '''content tree'''.<br />
Many JavaScript APIs operate on the content tree. Then, in<br />
layout, we create a second tree, the '''frame tree''' (or<br />
'''rendering tree''') that is a similar shape to the content tree,<br />
but where each node in the tree represents a rectangle (except in SVG<br />
where they represent other shapes). We then compute the positions of<br />
the nodes in the frame tree (called '''frames''') and paint them<br />
using our cross-platform graphics APIs (which, underneath, map to<br />
platform-specific graphics APIs).<br />
<br />
See [http://dbaron.org/talks/ David Baron's "Fast CSS: How Browsers Lay Out Web Pages" talk] for an overview of the pipeline in a presentation format.<br />
<br />
=== Parser ===<br />
<br />
The parser's job is to transform a character stream into a tree<br />
structure, with the help of the content sink classes.<br />
<br />
HTML is parsed using a parser implementing the parsing algorithm in the<br />
HTML specification (starting with HTML5). Much of this parser is<br />
translated from Java, and changes are made to the Java version. This<br />
parser in parser/html/. The parser is driven by the output of the networking layer (see nsHtml5StreamParser::OnDataAvailable). The HTML5 parser is capable of parsing off the main thread which is the normal case. It also parses on the main thread to be able to synchronously handle things such as innerHTML modifications.<br />
<br />
The codebase still has the previous generation HTML parser, which is<br />
still used for a small number of things, though we hope to be able to<br />
remove it entirely soon. This parser is in parser/htmlparser/.<br />
<br />
XML is parsed using the expat library (parser/expat/) and code that<br />
wraps it (parser/xml/). This is a non-validating parser; however, it<br />
loads certain DTDs to support XUL localization.<br />
<br />
=== DOM / Content ===<br />
<br />
The content tree or DOM tree is the central data structure for Web<br />
pages. It is a tree structure, initially created from the tree<br />
structure expressed in the HTML or XML markup. The nodes in the tree<br />
implement major parts of the DOM (Document Object Model) specifications.<br />
The nodes themselves are part of a class hierarchy rooted at<br />
<code>nsINode</code>; different derived classes are used for things such<br />
as text nodes, the document itself, HTML elements, SVG elements, etc.,<br />
with further subclasses of many of these types (e.g., for specific HTML<br />
elements). Many of the APIs available to script running in Web pages<br />
are associated with these nodes. The tree structure persists while the<br />
Web pages is displayed, since it stores much of state associated with<br />
the Web page. The code for these nodes lives in the content/ directory.<br />
<br />
The DOM APIs are not threadsafe. DOM nodes can be accessed only from<br />
the main thread (also known as the UI thread (user interface thread)) of<br />
the application.<br />
<br />
There are also many other APIs available to Web pages that are not APIs<br />
on the nodes in the DOM tree. Many of these other APIs also live in the<br />
same directories, though some live in content/ and some in dom/. These<br />
include APIs such as the DOM event model.<br />
<br />
The dom/ directory also includes some of the code needed to expose Web<br />
APIs to JavaScript (in other words, the glue code between JavaScript and<br />
these APIs). For an overview, see [https://ask.mozilla.org/question/390/how-is-the-web-exposed-dom-implemented/ DOM API Implementation]. See [[#Scripting|Scripting]] below for details of the JS engine.<br />
<br />
TODO: Internal APIs vs. DOM APIs.<br />
<br />
TODO: Mutation observers / document observers.<br />
<br />
TODO: Reference counting and cycle collection.<br />
<br />
TODO: specification links<br />
<br />
=== Style System ===<br />
<br />
==== Quantum CSS (Stylo) ====<br />
<br />
Starting with Firefox 57 and later, Gecko makes use of the parallel style system written in Rust that comes from Servo. There's an [https://hacks.mozilla.org/2017/08/inside-a-super-fast-css-engine-quantum-css-aka-stylo/ overview] of this with graphics to help explain what's going on. The [https://github.com/servo/servo/wiki/Layout-Overview Servo wiki] has some more details.<br />
<br />
==== Gecko ====<br />
<br />
The rest of the style section section describes the Gecko style system used in Firefox 56 and earlier. Some bits may still apply, but it likely needs revising.<br />
<br />
In order to display the content, Gecko needs to compute the styles<br />
relevant to each DOM node. It does this based on the model described in<br />
the CSS specifications: this model applies to style specified in CSS<br />
(e.g. by a 'style' element, an 'xml-stylesheet' processing instruction<br />
or a 'style' attribute),<br />
style specified by presentation attributes, and the default style<br />
specified by our own user agent style sheets. There are two major<br />
sets of data structures within the style system:<br />
* first, data structures that represent sources of style data, such as CSS style sheets or data from stylistic HTML attributes<br />
* second, data structures that represent computed style for a given DOM node.<br />
These sets of data structures are mostly distinct (for example, they<br />
store values in different ways).<br />
<br />
The loading of CSS style sheets from the network is managed by the <br />
[https://dxr.mozilla.org/mozilla-central/source/layout/style/Loader.h CSS loader]; <br />
they are then tokenized by the <br />
[https://dxr.mozilla.org/mozilla-central/source/layout/style/nsCSSScanner.h CSS scanner] <br />
and parsed by the <br />
[https://dxr.mozilla.org/mozilla-central/source/layout/style/nsCSSParser.h CSS parser]. <br />
Those that are attached to the document also expose APIs to<br />
script that are known as the CSS Object Model, or CSSOM.<br />
<br />
The style sheets that apply to a document are managed by a class called<br />
the [https://dxr.mozilla.org/mozilla-central/source/layout/style/nsStyleSet.h style set].<br />
The style set interacts with the different types of<br />
style sheets (representing CSS style sheets, presentational<br />
attributes, and 'style' attributes) through two interfaces:<br />
[http://dxr.mozilla.org/mozilla-central/source/layout/style/nsIStyleSheet.h nsIStyleSheet] for basic management of style sheets and<br />
[http://dxr.mozilla.org/mozilla-central/source/layout/style/nsIStyleRuleProcessor.h nsIStyleRuleProcessor] for getting the style data out of them. Usually<br />
the same object implements both interfaces, except in the most important<br />
case, CSS style sheets, where there is a single rule processor for all<br />
of the CSS style sheets in each origin (user/UA/author) of the CSS cascade.<br />
<br />
The computed style data for an element/frame are exposed to the rest of<br />
Gecko through the class mozilla::ComputedStyle (previously called<br />
nsStyleContext). Rather than having a member variable for each<br />
CSS property, it breaks up the properties into groups of related<br />
properties called style structs. These style structs obey the rule that<br />
all of the properties in a single struct either inherit by default (what<br />
the CSS specifications call "Inherited: yes" in the definition of<br />
properties; we call these inherited structs) or all are not inherited by<br />
default (we call these reset structs). Separating the properties in<br />
this way improves the ability to share the structs between similar<br />
ComputedStyle objects and reduce the amount of memory needed to store<br />
the style data. The ComputedStyle API exposes a method for getting each<br />
struct, so you'll see code like<br />
<code>sc->GetStyleText()->mTextAlign</code> for getting the value of the<br />
text-align CSS property. (Frames (see the Layout section below) also<br />
have the same<br />
GetStyle* methods, which just forward the call to the frame's<br />
ComputedStyle.)<br />
<br />
The ComputedStyles form a tree structure, in a shape somewhat like the<br />
content tree (except that we coalesce identical sibling ComputedStyles<br />
rather than keeping two of them around; if the parents have been<br />
coalesced then this can apply recursively and coalasce cousins, etc.;<br />
we do not coalesce parent/child ComputedStyles).<br />
The parent of a ComputedStyle has the style data that the ComputedStyle<br />
inherits from when CSS inheritance occurs. This means that the parent<br />
of the ComputedStyle for a DOM element is generally the ComputedStyle<br />
for that DOM element's parent, since that's how CSS says inheritance<br />
works.<br />
<br />
The process of turning the style sheets into computed style data goes<br />
through three main steps, the first two of which closely relate to the<br />
[http://dxr.mozilla.org/mozilla-central/source/layout/style/nsIStyleRule.h nsIStyleRule] interface, which represents an immutable source of style<br />
data, conceptually representing (and for CSS style rules, directly<br />
storing) a set of property:value pairs. (It is similar to the idea of a<br />
CSS style rule, except that it is immutable; this immutability allows<br />
for significant optimization. When a CSS style rule is changed through<br />
script, we create a new style rule.)<br />
<br />
The first step of going from style sheets to computed style data is<br />
finding the ordered sequence of style rules that apply to an element.<br />
The order represents which rules override which other rules: if two<br />
rules have a value for the same property, the higher ranking one wins.<br />
(Note that there's another difference from CSS style rules: declarations<br />
with !important are represented using a separate style rule.) This is<br />
done by calling one of the nsIStyleRuleProcessor::RulesMatching methods.<br />
The ordered sequence is stored in a<br />
[http://en.wikipedia.org/wiki/Trie trie] called the rule tree: the path<br />
from the root of the rule tree to any (leaf or non-leaf) node in the<br />
rule tree represents a sequence of rules, with the highest ranking<br />
farthest from the root. Each rule node (except for the root) has a<br />
pointer to a rule, but since a rule may appear in many sequences, there<br />
are sometimes many rule nodes pointing to the same rule. Once we have<br />
this list we create a ComputedStyle (or find an appropriate existing<br />
sibling) with the correct parent pointer (for inheritance) and rule node<br />
pointer (for the list of rules), and a few other pieces of information<br />
(like the pseudo-element).<br />
<br />
The second step of going from style sheets to computed style data is<br />
getting the winning property:value pairs from the rules. (This only<br />
provides property:value pairs for some of the properties; the remaining<br />
properties will fall back to inheritance or to their initial values<br />
depending on whether the property is inherited by default.) We do this<br />
step (and the third) for each style struct, the first time it is needed.<br />
This is done in nsRuleNode::WalkRuleTree, where we ask each style rule<br />
to fill in its property:value pairs by calling its MapRuleInfoInto<br />
function. When called, the rule fills in only those pairs that haven't<br />
been filled in already, since we're calling from the highest priority<br />
rule to the lowest (since in many cases this allows us to stop before<br />
going through the whole list, or to do partial computation that just<br />
adds to data cached higher in the rule tree).<br />
<br />
The third step of going from style sheets to computed style data (which<br />
various caching optimizations allow us to skip in many cases) is<br />
actually doing the computation; this generally means we transform the<br />
style data into the data type described in the "Computed Value" line in<br />
the property's definition in the CSS specifications. This<br />
transformation happens in functions called nsRuleNode::Compute*Data,<br />
where the * in the middle represents the name of the style struct. This<br />
is where the transformation from the style sheet value storage format to<br />
the computed value storage format happens.<br />
<br />
Once we have the computed style data, we then store it: if a style struct<br />
in the computed style data doesn't<br />
depend on inherited values or on data from other style structs, then we<br />
can cache it in the rule tree (and then reuse it, without recomputing<br />
it, for any ComputedStyles pointing to that rule node). Otherwise, we<br />
store it on the ComputedStyle (in which case it may be shared<br />
with the ComputedStyle's descendant ComputedStyles).<br />
This is where keeping inherited and<br />
non-inherited properties separate is useful: in the common case of<br />
relatively few properties being specified, we can generally cache the<br />
non-inherited structs in the rule tree, and we can generally share the<br />
inherited structs up and down the ComputedStyle tree.<br />
<br />
The ownership models in style sheet structures are a mix of reference<br />
counted structures (for things accessible from script) and directly<br />
owned structures. ComputedStyles are reference counted, and own their<br />
parents (from which they inherit), and rule nodes are garbage collected<br />
with a simple mark and sweep collector (which often never needs to run).<br />
<br />
* code: [http://dxr.mozilla.org/mozilla-central/source/layout/style/ layout/style/], where most files have useful one line descriptions at the top that show up in DXR<br />
* Bugzilla: Style System (CSS)<br />
* specifications<br />
** [http://www.w3.org/TR/CSS21/ CSS 2.1]<br />
** [http://www.w3.org/TR/css-2010/ CSS 2010, listing stable css3 modules]<br />
** [http://dev.w3.org/csswg/ CSS WG editors drafts] (often more current, but sometimes more unstable than the drafts on the technical reports page)<br />
** [http://dbaron.org/mozilla/visited-privacy Preventing attacks on a user's history through CSS :visited selectors]<br />
* documentation<br />
** [http://www-archive.mozilla.org/newlayout/doc/style-system.html style system documentation] (somewhat out of date)<br />
<br />
=== Layout ===<br />
<br />
Much of the layout code deals with operations on the frame tree (or<br />
rendering tree). In the frame tree, each node represents a rectangle<br />
(or, for SVG, other shapes). The frame tree has a shape similar to the<br />
content tree, since many content nodes have one corresponding frame,<br />
though it differs in a few ways, since some content nodes have more than<br />
one frame or don't have any frames at all. When elements are<br />
display:none in CSS or undisplayed for certain other reasons, they won't<br />
have any frames. When elements are broken across lines or pages, they<br />
have multiple frames; elements may also have multiple frames when<br />
multiple frames nested inside each other are needed to display a single<br />
element (for example, a table, a table cell, or many types of form<br />
controls).<br />
<br />
Each node in the frame tree is an instance of a class derived from<br />
<code>nsIFrame</code>. As with the content tree, there is a substantial<br />
type hierarchy, but the type hierarchy is very different: it includes<br />
types like text frames, blocks and inlines, the various parts of tables,<br />
and the various types of HTML form controls.<br />
<br />
Frames are allocated within an arena owned by the pres shell. Each<br />
frame is owned by its parent; frames are not reference counted, and code<br />
must not hold on to pointers to frames. To mitigate potential security<br />
bugs when pointers to destroyed frames, we use<br />
[http://robert.ocallahan.org/2010/10/mitigating-dangling-pointer-bugs-using_15.html frame poisoning], which takes two parts. When a frame is destroyed<br />
other than at the end of life of the presentation, we fill its memory<br />
with a pattern consisting of a repeated pointer to inaccessible memory,<br />
and then put the memory on a per-frame-class freelist. This means that<br />
if code accesses the memory through a dangling pointer, it will either<br />
crash quickly by dereferencing the poison pattern or it will find a<br />
valid frame.<br />
<br />
Like the content tree, frames must be accessed only from the UI thread.<br />
<br />
The frame tree should not store any important data. While it does<br />
usually persist while a page is being displayed, frames are often<br />
destroyed and recreated in response to certain style changes, and in the<br />
future we may do the same to reduce memory use for pages that are<br />
currently inactive. There were a number of cases where this rule was<br />
violated in the past and we stored important data in the frame tree;<br />
however, most (though not quite all) such cases are now fixed.<br />
<br />
The rectangle represented by the frame is what CSS calls the element's<br />
border box. This is the outside edge of the border (or the inside edge<br />
of the margin). The margin lives outside the border; and the padding<br />
lives inside the border. In addition to nsIFrame::GetRect, we also have<br />
the APIs nsIFrame::GetPaddingRect to get the padding box (the outside<br />
edge of the padding, or inside edge of the border) and<br />
nsIFrame::GetContentRect to get the content box (the outside edge of the<br />
content, or inside edge of the padding). These APIs may produce out of<br />
date results when reflow is needed (or has not yet occurred).<br />
<br />
In addition to tracking a rectangle, frames also track two overflow<br />
areas: visual overflow and scrollable overflow. These overflow areas<br />
represent the union of the area needed by the frame and by all its<br />
descendants. The visual overflow is used for painting-related<br />
optimizations: it is a rectangle covering all of the area that might be<br />
painted when the frame and all of its descendants paint. The scrollable<br />
overflow represents the area that the user should be able to scroll to<br />
to see the frame and all of its descendants. In some cases differences<br />
between the frame's rect and its overflow happen because of descendants<br />
that stick out of the frame; in other cases they occur because of some<br />
characteristic of the frame itself. The two overflow areas are<br />
similar, but there are differences: for example, margins are part of<br />
scrollable overflow but not visual overflow, whereas text-shadows are<br />
part of visual overflow but not scrollable overflow.<br />
<br />
When frames are broken across lines, columns, or pages, we create<br />
multiple frames representing the multiple rectangles of the element.<br />
The first one is the primary frame, and the rest are its continuations<br />
(which are more likely to be destroyed and recreated during reflow).<br />
These frames are linked together as continuations: they have a<br />
doubly-linked list that can be used to traverse the continuations using<br />
nsIFrame::GetPrevContinuation and nsIFrame::GetNextContinuation.<br />
(Currently continuations always have the same style data, though we may<br />
at some point want to break that invariant.)<br />
<br />
Continuations are sometimes siblings of each other, and sometimes not.<br />
For example, if a paragraph contains a span which contains a link, and<br />
the link is split across lines, then the continuations of the span are<br />
siblings (since they are both children of the paragraph), but the<br />
continuations of the link are not siblings (since each continuation of<br />
the link is descended from a different continuation of the span).<br />
Traversing the entire frame tree does '''not''' require considering<br />
continuations, since all of the continuations are descendants of the<br />
element containing the break.<br />
<br />
We also use continuations for cases (most importantly, bidi reordering,<br />
where left-to-right text and right-to-left text need to be separated<br />
into different continuations since they may not form a contiguous<br />
rectangle) where the continuations should not be rewrapped during<br />
reflow: we call these continuations fixed rather than fluid.<br />
nsIFrame::GetNextInFlow and nsIFrame::GetPrevInFlow traverse only the<br />
fluid continuations and do not cross fixed continuation boundaries.<br />
<br />
If an inline frame has non-inline children, then we split the original <br />
inline frame into parts. The original inline's children are <br />
distributed into these parts like so- The children of the original <br />
inline are grouped into runs of inline and non-inline and runs of <br />
inline get an inline parent while runs of non-inline get an anonymous <br />
block parent. This is 'ib-splitting' or block-inside-inline-splitting. <br />
This splitting proceeds recursively up the frame tree until all <br />
non-inlines inside inlines are ancestors of a block frame with anonymous <br />
block wrappers in between. This splitting maintains the relative order<br />
between these child frames and the relationship between the parts of a <br />
split inline is maintained using an ib-sibling chain. It is important <br />
to note that any wrappers created during frame construction (such as <br />
for tables) may not be included in the ib-sibling chain depending on <br />
when this wrapper creation takes place. <br />
<br />
TODO: nsBox craziness from https://bugzilla.mozilla.org/show_bug.cgi?id=524925#c64<br />
<br />
TODO: link to documentation of block and inline layout<br />
<br />
TODO: link to documentation of scrollframes<br />
<br />
TODO: link to documentation of XUL frame classes<br />
<br />
Code (note that most files in base and generic have useful one line descriptions at the top that show up in DXR):<br />
* [http://dxr.mozilla.org/mozilla-central/source/layout/base/ layout/base/] contains objects that coordinate everything and a bunch of other miscellaneous things<br />
* [http://dxr.mozilla.org/mozilla-central/source/layout/generic/ layout/generic/] contains the basic frame classes as well as support code for their reflow methods (ReflowInput, ReflowOutput)<br />
* [http://dxr.mozilla.org/mozilla-central/source/layout/forms/ layout/forms/] contains frame classes for HTML form controls<br />
* [http://dxr.mozilla.org/mozilla-central/source/layout/tables/ layout/tables/] contains frame classes for CSS/HTML tables<br />
* [http://dxr.mozilla.org/mozilla-central/source/layout/mathml/ layout/mathml/] contains frame classes for MathML<br />
* [http://dxr.mozilla.org/mozilla-central/source/layout/svg/ layout/svg/] contains frame classes for SVG<br />
* [http://dxr.mozilla.org/mozilla-central/source/layout/xul/ layout/xul/] contains frame classes for the XUL box model and for various XUL widgets<br />
<br />
Bugzilla:<br />
* All of the components whose names begin with "Layout" in the "Core" product<br />
<br />
==== Frame Construction ====<br />
<br />
Frame construction is the process of creating frames. This is done when styles change in ways that require frames to be created or recreated or when nodes are inserted into the document. The content tree and the frame tree don't have quite the same shape, and the frame construction process does some of the work of creating the right shape for the frame tree. It handles the aspects of creating the right shape that don't depend on layout information. So for example, frame construction handles the work needed to implement [http://www.w3.org/TR/CSS21/tables.html#anonymous-boxes table anonymous objects] but does not handle frames that need to be created when an element is broken across lines or pages.<br />
<br />
The basic unit of frame construction is a run of contiguous children of a single parent element. When asked to construct frames for such a run of children, the frame constructor first determines, based on the siblings and parent of the nodes involved, where in the frame tree the new frames should be inserted. Then the frame constructor walks through the list of content nodes involved and for each one creates a temporary data structure called a '''frame construction item'''. The frame construction item encapsulates various information needed to create the frames for the content node: its style data, some metadata about how one would create a frame for this node based on its namespace, tag name, and styles, and some data about what sort of frame will be created. This list of frame construction items is then analyzed to see whether constructing frames based on it and inserting them at the chosen insertion point will produce a valid frame tree. If it will not, the frame constructor either fixes up the list of frame construction items so that the resulting frame tree would be valid or throws away the list of frame construction items and requests the destruction and re-creation of the frame for the parent element so that it has a chance to create a list of frame construction items that it <em>can</em> fix up.<br />
<br />
Once the frame constructor has a list of frame construction items and an insertion point that would lead to a valid frame tree, it goes ahead and creates frames based on those items. Creation of a non-leaf frame recursively attempts to create frames for the children of that frame's element, so in effect frames are created in a depth-first traversal of the content tree.<br />
<br />
The vast majority of the code in the frame constructor, therefore, falls into one of these categories:<br />
* Code to determine the correct insertion point in the frame tree for new frames.<br />
* Code to create, for a given content node, frame construction items. This involves some searches through static data tables for metadata about the frame to be created.<br />
* Code to analyze the list of frame construction items.<br />
* Code to fix up the list of frame construction items.<br />
* Code to create frames from frame construction items.<br />
<br />
Code: [http://dxr.mozilla.org/mozilla-central/source/layout/base/nsCSSFrameConstructor.h layout/base/nsCSSFrameConstructor.h] and [http://dxr.mozilla.org/mozilla-central/source/layout/base/nsCSSFrameConstructor.cpp layout/base/nsCSSFrameConstructor.cpp]<br />
<br />
==== Reflow ====<br />
<br />
Reflow is the process of computing the positions and sizes of frames. (After all,<br />
frames represent rectangles, and at some point we need to figure out<br />
exactly *what* rectangle.) Reflow is done recursively, with each<br />
frame's Reflow method calling the Reflow methods on that frame's<br />
descendants.<br />
<br />
In many cases, the correct results are defined by CSS specifications<br />
(particularly [http://www.w3.org/TR/CSS21/visudet.html CSS 2.1]). In some cases, the details are not defined by<br />
CSS, though in some (but not all) of those cases we are constrained by<br />
Web compatibility. When the details are defined by CSS, however, the<br />
code to compute the layout is generally structured somewhat differently<br />
from the way it is described in the CSS specifications, since the CSS<br />
specifications are generally written in terms of constraints, whereas<br />
our layout code consists of algorithms optimized for incremental<br />
recomputation.<br />
<br />
The reflow generally starts from the root of the frame tree, though some other<br />
types of frame can act as reflow roots and start a reflow from them.<br />
Reflow roots must obey the invariant that a change inside one of their<br />
descendants never changes their rect or overflow areas (though currently<br />
scrollbars are reflow roots but don't quite obey this invariant).<br />
<br />
In many cases, we want to reflow a part of the frame tree, and we want<br />
this reflow to be efficient. For example, when content is added or<br />
removed from the document tree or when styles change, we want the amount<br />
of work we need to redo to be proportional to the amount of content. We<br />
also want to efficiently handle a series of changes to the same content.<br />
<br />
To do this, we maintain two bits on frames:<br />
[http://dxr.mozilla.org/mozilla-central/search?q=var%3ANS_FRAME_IS_DIRTY&case=true&redirect=true NS_FRAME_IS_DIRTY]<br />
indicates that a frame and all of its descendants require reflow.<br />
[http://dxr.mozilla.org/mozilla-central/search?q=var%3ANS_FRAME_HAS_DIRTY_CHILDREN&case=true&redirect=true NS_FRAME_HAS_DIRTY_CHILDREN]<br />
indicates that a frame has a descendant that<br />
is dirty or has had a descendant removed (i.e., that it has a child that<br />
has NS_FRAME_IS_DIRTY or NS_FRAME_HAS_DIRTY_CHILDREN or it had a child<br />
removed). These bits allow coalescing of multiple updates; this<br />
coalescing is done in nsPresShell, which tracks the set of reflow roots<br />
that require reflow. The bits are set during calls to<br />
nsPresShell::FrameNeedsReflow and are cleared during reflow.<br />
<br />
The layout algorithms used by many of the frame classes are those<br />
specified in CSS, which are based on the traditional document formatting<br />
model, where widths are input and heights are output.<br />
<br />
In some cases, however, widths need to be determined based on the<br />
content. This depends on two ''intrinsic widths'': the minimum<br />
intrinsic width (see [http://dxr.mozilla.org/search?q=type%3AnsIFrame%20function%3AGetMinWidth&tree=mozilla-central nsIFrame::GetMinWidth]) and the preferred intrinsic<br />
width (see [http://dxr.mozilla.org/search?q=type%3AnsIFrame%20function%3AGetPrefWidth&tree=mozilla-central nsIFrame::GetPrefWidth]). The concept of what these widths<br />
represent is best explained by describing what they are on a paragraph<br />
containing only text: in such a paragraph the minimum intrinsic width<br />
is the width of the longest word, and the preferred intrinsic width is<br />
the width of the entire paragraph laid out on one line.<br />
<br />
Intrinsic widths are invalidated separately from the dirty bits<br />
described above. When a caller informs the pres shell that a frame<br />
needs reflow (nsIPresShell::FrameNeedsReflow), it passes one of three<br />
options:<br />
* eResize indicates that no intrinsic widths are dirty<br />
* eTreeChange indicates that intrinsic widths on it and its ancestors are dirty (which happens, for example, if new children are added to it)<br />
* eStyleChange indicates that intrinsic widths on it, its ancestors, and its descendants are dirty (for example, if the font-size changes)<br />
<br />
Reflow is the area where the XUL frame classes (those that inherit from<br />
nsBoxFrame or nsLeafBoxFrame) are most different from the rest. Instead<br />
of using nsIFrame::Reflow, they do their layout computations using<br />
intrinsic size methods called GetMinSize, GetPrefSize, and GetMaxSize<br />
(which report intrinsic sizes in two dimensions) and a final layout<br />
method called Layout. In many cases these methods defer some of the<br />
computation to a separate object called a layout manager.<br />
<br />
When an individual frame's Reflow method is called, most of the input is<br />
provided on an object called ReflowInput and the output is filled<br />
in to an object called ReflowOutput. After reflow, the caller<br />
(usually the parent) is responsible for setting the frame's size based<br />
on the metrics reported. (This can make some computations during reflow<br />
difficult, since the new size is found in either the reflow state or the<br />
metrics, but the frame's size is still the old size. However, it's<br />
useful for invalidating the correct areas that need to be repainted.)<br />
<br />
One major difference worth noting is that in XUL layout, the size of the<br />
child is set prior to its parent calling its Layout method. (Once<br />
invalidation uses display lists and is no longer tangled up in Reflow,<br />
it may be worth switching non-XUL layout to work this way as well.)<br />
<br />
==== Painting ====<br />
<br />
TODO: display lists (and event handling)<br />
<br />
TODO: layers<br />
<br />
==== Pagination ====<br />
<br />
The concepts behind pagination (also known as fragmentation) are a bit complicated, so for now we've split them off into a separate document: [[Gecko:Continuation_Model]]. This code is used for printing, print-preview, and multicolumn frames.<br />
<br />
=== Dynamic change handling along the rendering pipeline ===<br />
<br />
The ability to make changes to the DOM from script is a major feature of the Web platform. Web authors rely on the concept (though there are a few exceptions, such as animations) that changing the DOM from script leads to the same rendering that would have resulted from starting from that DOM tree. They also rely on the performance characteristics of these changes: small changes to the DOM that have small effects should have proportionally small processing time. This means that Gecko needs to efficiently propagate changes from the content tree to style, the frame tree, the geometry of the frame tree, and the screen.<br />
<br />
For many types of changes, however, there is substantial overhead to processing a change, no matter how small. For example, reflow must propagate from the top of the frame tree down to the frames that are dirty, no matter how small the change. One very common way around this is to batch up changes. We batch up changes in lots of ways, for example:<br />
* The content sink adds multiple nodes to the DOM tree before notifying listeners that they've been added. This allows notifying once about an ancestor rather than for each of its descendants, or notifying about a group of descendants all at once, which speeds up the processing of those notifications.<br />
* We batch up nodes that require style reresolution (recomputation of selector matching and processing the resulting style changes). This batching is tree based, so it not only merges multiple notifications on the same element, but also merges a notification on an ancestor with a notification on its descendant (since ''some'' of these notifications imply that style reresolution is required on all descendants).<br />
* We wait to reconstruct frames that require reconstruction (after destroying frames eagerly). This, like the tree-based style reresolution batching, avoids duplication both for same-element notifications and ancestor-descendant notifications, even though it doesn't actually do any tree-based caching.<br />
* We postpone doing reflows until needed. As for style reresolution, this maintains tree-based dirty bits (see the description of NS_FRAME_IS_DIRTY and NS_FRAME_HAS_DIRTY_CHILDREN under Reflow).<br />
* We allow the OS to queue up multiple invalidates before repainting (though we will likely switch to controlling that ourselves). This leads to a single repaint of some set of pixels where there might otherwise have been multiple (though it may also lead to more pixels being repainted if multiple rectangles are merged to a single one).<br />
<br />
Having changes buffered up means, however, that various pieces of information (layout, style, etc.) may not be up-to-date. Some things require up-to-date information: for example, we don't want to expose the details of our buffering to Web page script since the programming model of Web page script assumes that DOM changes take effect "immediately", i.e., that the script shouldn't be able to detect any buffering. Many Web pages depend on this.<br />
<br />
We therefore have ways to flush these different sorts of buffers. There are methods called FlushPendingNotifications on nsIDocument and nsIPresShell, that take an argument of what things to flush:<br />
* Flush_Content: create all the content nodes from data buffered in the parser<br />
* Flush_ContentAndNotify: the above, plus notify document observers about the creation of all nodes created so far<br />
* Flush_Style: the above, plus make sure style data are up-to-date<br />
* Flush_Frames: the above, plus make sure all frame construction has happened (currently the same as Flush_Style)<br />
* Flush_InterruptibleLayout: the above, plus perform layout (Reflow), but allow interrupting layout if it takes too long<br />
* Flush_Layout: the above, plus ensure layout (Reflow) runs to completion<br />
* Flush_Display (should never be used): the above, plus ensure repainting happens<br />
<br />
The major way that notifications of changes propagate from the content code to layout and other areas of code is through the nsIDocumentObserver and nsIMutationObserver interfaces. Classes can implement this interface to listen to notifications of changes for an entire document or for a subtree of the content tree.<br />
<br />
WRITE ME: ... layout document observer implementations<br />
<br />
TODO: how style system optimizes away rerunning selector matching<br />
<br />
TODO: style changes and nsChangeHint<br />
<br />
=== Refresh driver ===<br />
<br />
== Graphics ==<br />
[https://wiki.mozilla.org/Platform/GFX Wiki page] | [https://wiki.mozilla.org/index.php?title=Platform/GFX/Contribute contribute]<br />
<br />
==== Painting/Rasterizing ====<br />
<br />
Painting/rendering/rasterizing is the step where graphical primitives (such as a command to fill an [https://developer.mozilla.org/en-US/docs/Web/SVG SVG] circle, or a [https://developer.mozilla.org/en-US/docs/Web/Guide/Graphics/Drawing_graphics_with_canvas canvas] command to stroke a path between x, y, z, or the internally produced command to draw the edge of an HTML div's border) are used to color in the pixels of a surface so that the surface "displays" those rasterized primitives.<br />
<br />
The platform independent library that gecko uses to render is [http://dxr.mozilla.org/mozilla-central/source/gfx/2d/2D.h Moz2D]. Gecko code paints into Moz2D DrawTarget objects (the DrawTarget baseclass having multiple platform dependent subclasses). (At least this is where gecko is going - for now there is still significant amounts of code that uses [http://dxr.mozilla.org/mozilla-central/source/gfx/thebes/gfxContext.h Thebes gfxContext] objects or the even older nsRenderingContext objects. Objects of these types now always wrap a DrawTarget so all painting does now go through Moz2D, but conversion to use the wrapped DrawTargets directly is taking time since consumer code can sometimes need to be radically rewritten to fit the Moz2D API and immediate mode paradigm.)<br />
<br />
==== Compositing ====<br />
<br />
The compositing stage of the rendering pipeline is operated by the [http://dxr.mozilla.org/mozilla-central/source/gfx/layers/ gfx/layers] module.<br />
<br />
Different parts of a web page can sometimes be painted into intermediate surfaces retained by layers. It can be convenient to think of layers as the layers in image manipulation programs like The Gimp or Photoshop. Layers are organized as a tree. Layers are primarily used to minimize invalidating and repainting when elements are being animated independently of one another in a way that can be optimized using layers (e.g. opacity or transform animations), and to enable some effects (such as transparency and 3D transforms).<br />
<br />
Compositing is the action of flattening the layers into the final image that is shown on the screen.<br />
<br />
On some platform, compositing happens on the Content thread. However, on other platforms we composite on a separate thread (Off-main-thread compositing, or OMTC). OMTC is at the moment the default behavior on mobile platforms, but the goal is to do it on all platforms in the long run.<br />
<br />
The Layers architecture is built on the following notions:<br />
* Compositor: an object that can draw quads on the screen (or on an off-screen render target).<br />
* Texture: an object that contains image data.<br />
* Compositable: an object that can manipulate one or several textures, and knows how to present them to the compositor<br />
* Layer: an element of the layer tree. A layer usually doesn't know much about compositing: it uses a compositable to do the work. Layers are mostly nodes of the layer tree.<br />
<br />
[[File:LayersRefactoring.png|thumb|650px|New layers architecture, with OGL backend]]<br />
<br />
The above abstractions are sufficient to perform compositing on the main thread, but on the OMTC case, we need a mechanism to synchronize a client layer tree that is constructed on the content thread, and a host layer tree that is used for compositing on the compositor thread.<br />
This synchronization process must ensure that the host layer tree reflects the state of the current layer tree while remaining in a consistent state, and must transfer texture data from a thread to the other. Moreover, on some platforms the content and compositor threads may live in separate processes.<br />
<br />
To perform this synchronization, we use the IPDL IPC framework. IPDL lets us describe communications protocols and actors in a domain specific language. for more information about IPDL, read https://wiki.mozilla.org/IPDL<br />
<br />
When the client layer tree is modified, we record modifications into messages that are sent together to the host side within a transaction. A transaction is basically a list of modifications to the layer tree that have to be applied all at once to preserve consistency in the state of the host layer tree.<br />
<br />
Texture transfer is done by synchronizing texture objects across processes/threads using a couple TextureClient/TextureHost that wrap shared data and provide access to it on both sides. TextureHosts provide access to one or several TextureSource, which has the necessary API to actually composite the texture (TextureClient/Host being more about IPC synchronization than actual compositing.<br />
The logic behind texture transfer (as in single/double/triple buffering, texture tiling, etc) is operated by the CompositableClient and CompositableHost.<br />
<br />
It is important to understand the separation between layers and compositables. Compositables handle all the logic around texture transfer, while layers define the shape of the layer tree. a Compositable is created independently from a layer and attached to it on both sides. While layers transactions can only originate from the content thread, this separation makes it possible for us to have separate compositable transactions between any thread and the compositor thread. We use the ImageBridge IPDL protocol to that end. The Idea of ImageBridge is to create a Compositable that is manipulated on the ImageBridgeThread, and that can transfer/synchronize textures without using the content thread at all. This is very useful for smooth Video compositing: video frames are decoded and passed into the ImageBridge without ever touching the content thread, which could be busy processing reflows or heavy javascript workloads.<br />
<br />
It is worth reading the inline code documentation in the following files:<br />
* [http://dxr.mozilla.org/mozilla-central/source/gfx/layers/Compositor.h gfx/layers/Compositor.h]<br />
* [http://dxr.mozilla.org/mozilla-central/source/gfx/layers/ShadowLayers.h gfx/layers/ShadowLayers.h]<br />
* [http://dxr.mozilla.org/mozilla-central/source/gfx/layers/Layers.h gfx/layers/Layers.h]<br />
* [http://dxr.mozilla.org/mozilla-central/source/gfx/layers/host/TextureHost.h gfx/layers/host/TextureHost.h]<br />
* [http://dxr.mozilla.org/mozilla-central/source/gfx/layers/client/CompositableClient.h gfx/layers/client/CompositableClient.h]<br />
<br />
To visualize how a web page is layered, turn on the pref "layers.draw-borders" in about:config. When this pref is on, the borders of layers and tiles are displayed on top of the content. This only works when using the new Compositor API, that is when off-main-thread compositing is activated. OMTC is activated by default on all mobile platforms, and will progressively get activated on desktop platforms (not yet, though). On platforms where OMTC is not used, this pref has no effect. <br />
<br />
Blog posts with information on Layers that should be integrated here:<br />
<br />
* [http://www.basschouten.com/blog1.php/layers-cross-platform-acceleration Layers: Cross-Platform Acceleration]<br />
* [http://robert.ocallahan.org/2010/04/layers_01.html Layers]<br />
* [http://robert.ocallahan.org/2010/07/retained-layers_16.html Retained Layers]<br />
* [http://chrislord.net/index.php/2011/07/25/shadow-layers-and-learning-by-failing/ Shadow Layers, and learning by failing]<br />
* [http://chrislord.net/index.php/2011/08/16/accelerated-layer-rendering-and-learning-by-some-success/ Accelerated layer-rendering, and learning by (some) success]<br />
* [http://featherweightmusings.blogspot.co.uk/2012/05/mask-layers_26.html Mask Layers]<br />
* [http://featherweightmusings.blogspot.co.uk/2012/05/building-mask-layer.html Building a mask layer]<br />
* [http://featherweightmusings.blogspot.co.uk/2012/06/mask-layers-on-direct3d-backends.html Mask Layers on the Direct3D backends]<br />
* [http://robert.ocallahan.org/2011/09/graphics-api-design.html Graphics API Design]<br />
<br />
==== Async Panning and Zooming ====<br />
<br />
On some of our mobile platforms we have some code that allows the user to do asynchronous (i.e. off-main-thread) panning and zooming of content. This code is the Async Pan/Zoom module (APZ) code and is further documented at [[Platform/GFX/APZ]].<br />
<br />
== Scripting ==<br />
<br />
=== JavaScript Engine ===<br />
<br />
Gecko embeds the SpiderMonkey JavaScript engine (located in js/src). The JS engine includes a number of Just-In-Time compilers (or JITs). SpiderMonkey provides a powerful and extensive embedding API (called the JSAPI). Because of its complexity, using the JSAPI directly is frowned upon, and a number of abstractions have been built in Gecko to allow interacting with the JS engine without using JSAPI directly. Some JSAPI concepts are important for Gecko developers to understand, and they are listed below:<br />
<br />
* Global object: The '''global object''' is the object on which all global variables/properties/methods live. In a web page this is the 'window' object. In other things such as XPCOM components or sandboxes XPConnect creates a global object with a small number of builtin APIs.<br />
* Compartments: A '''compartment''' is a subdivision of the JS heap. The mapping from global objects to compartments is one-to-one; that is, every global object has a compartment associated with it, and no compartment is associated with more than one global object. (NB: There are compartments associated with no global object, but they aren't very interesting). When JS code is running SpiderMonkey has a concept of a "current" compartment. New objects that are created will be created in the "current" compartment and associated with the global object of that compartment.<br />
* When objects in one compartment can see objects in another compartment (via e.g. iframe.contentWindow.foo) '''cross-compartment wrappers''' or '''CCWs''' mediate the interaction between the two compartments. By default CCWs ensure that the current compartment is kept up-to-date when execution crosses a compartment boundary. SpiderMonkey also allows embeddings to extend wrappers with custom behavior to implement security policies, which Gecko uses extensively (see the Security section for more information).<br />
<br />
=== XPConnect ===<br />
<br />
'''XPConnect''' is a bridge between C++ and JS used by XPCOM components exposed to or implemented in JavaScript. XPConnect allows two XPCOM components to talk to each other without knowing or caring which language they are implemented in. XPConnect allows JS code to call XPCOM components by exposing XPCOM interfaces as JS objects, and mapping function calls and attributes from JS into virtual method calls on the underlying C++ object. It also allows JS code to implement an XPCOM component that can be called from C++ by faking the vtable of an interface and translating calls on the interface into JS calls. XPConnect accomplishes this using the vtable data stored in XPCOM TypeLibs (or XPT files) by the XPIDL compiler and a small layer of platform specific code called [https://developer.mozilla.org/en-US/docs/xptcall_FAQ xptcall] that knows how to interact with and impersonate vtables of XPCOM interfaces.<br />
<br />
XPConnect is also used for a small (and decreasing) number of legacy DOM objects. At one time all of the DOM used XPConnect to talk to JS, but we have been replacing XPConnect with the WebIDL bindings (see the next section for more information). Arbitrary XPCOM components are not exposed to web content. XPCOM components that want to be accessible to web content must provide class info (that is, they must QI to nsIClassInfo) and must be marked with the nsIClassInfo::DOM_OBJECT flag. Most of these objects also are listed in dom/base/nsDOMClassInfo.cpp, where the interfaces that should be visible to the web are enumerated. This file also houses some "scriptable helpers" (classes ending in "SH" and implementing nsIXPCScriptable), which are a set of optional hooks that can be used by XPConnect objects to implement more exotic behaviors (such as indexed getters or setters, lazily resolved properties, etc). This is all legacy code, and any new DOM code should use the WebIDL bindings.<br />
<br />
=== WebIDL Bindings ===<br />
<br />
The '''WebIDL bindings''' are a separate bridge between C++ and JS that is specifically designed for use by DOM code. We intend to replace all uses of XPConnect to interface with content JavaScript with the WebIDL bindings. [https://developer.mozilla.org/en-US/docs/Mozilla/WebIDL_bindings Extensive documentation] on the WebIDL bindings is available, but the basic idea is that a binding generator takes WebIDL files from web standards and some configuration data provided by us and generates at build time C++ glue code that sits between the JS engine and the DOM object. This setup allows us to produce faster, more specialized code for better performance at the cost of increased codesize.<br />
<br />
The WebIDL bindings also implement all of the behavior specified in WebIDL, making it possible for new additions to the DOM to behave correctly "out of the box". The binding layer also provides C++ abstractions for types that would otherwise require direct JSAPI calls to handle, such as typed arrays. <br />
<br />
=== Security ===<br />
<br />
Gecko's JS security model is based on the concept of compartments. Every compartment has a '''principal''' associated with it that contains security information such as the '''origin''' of the compartment, whether or not it has system privileges, etc. For the following discussion, '''wrappee''' refers to the underlying object being wrapped, '''scope''' refers to the compartment the object is being wrapped for use in, and '''wrapper''' refers to the object created in '''scope''' that allows it to interact with '''wrappee'''. "Chrome" refers to JS that is built in to the browser or part of an extension, which runs with full privileges, and is contrasted with "content", which is web provided script that is subject to security restrictions and the same origin policy.<br />
<br />
* Xray wrappers: Xray wrappers are used when the scope has chrome privileges and the wrappee is the JS reflection of an underlying DOM object. Beyond the usual CCW duties of making sure that content code does not run with chrome privileges, Xray wrappers also ensure that calling methods or accessing attributes on the wrappee has the "expected" effect. For example, a web page could replace the <code>close</code> method on its window with a JS function that does something completely different. (e.g. <code>window.close = function() { alert("This isn't what you wanted!") };</code>). Overwriting methods in this way (or creating entirely new ones) is referred to as '''expando''' properties. Xrays see through expando properties, invoking the original method/getter/setter if the expando overwrites a builtin or seeing undefined in the expando creates a new property. This allows chrome code to call methods on content DOM objects without worrying about how the page has changed the object.<br />
* Waived xray wrappers: The xray behavior is not always desirable. It is possible for chrome to "waive" the xray behavior and see the actual JS object. The wrapper still guarantees that code runs with the correct privileges, but methods/getters/setters may not behave as expected. This is equivalent to the behavior chrome sees when it looks at non-DOM content JS objects.<br />
* For more information, see the [https://developer.mozilla.org/en-US/docs/Mozilla/Gecko/Script_security MDN page]<br />
* bholley's [https://air.mozilla.org/enter-the-compartment/ Enter the Compartment] talk also provides an overview of our compartment architecture.<br />
<br />
== Images ==<br />
<br />
== Plugins ==<br />
<br />
== Platform-specific layers ==<br />
<br />
* widget<br />
* native theme<br />
* files, networking, other low-level things<br />
* Accessibility APIs<br />
* Input. Touch-input stuff is somewhat described at [[Platform/Input/Touch]].<br />
<br />
== Editor ==<br />
<br />
== Base layers ==<br />
<br />
=== NSPR ===<br />
<br />
NSPR is a library for providing cross-platform APIs for various<br />
platform-specific functions. We tend to be trying to use it as little<br />
as possible, although there are a number of areas (particularly some<br />
network-related APIs and threading/locking primitives) where we use it<br />
quite a bit.<br />
<br />
=== XPCOM ===<br />
<br />
XPCOM is a cross-platform modularity library, modeled on Microsoft COM. It<br />
is an object system in which all objects inherit from the <code>nsISupports</code> interface.<br />
<br />
components and services, contract IDs and CIDs<br />
<br />
prior overuse of XPCOM; littering with XPCOM does not produce modularity<br />
<br />
Base headers (part of xpcom/base/) and data structures. See also mfbt.<br />
<br />
Threading<br />
<br />
xptcall, proxies<br />
<br />
reference counting, cycle collection<br />
<br />
Further documentation:<br />
* XPCOM and Internal Strings in Gecko (talk by David Baron, 2014-03-20): [https://air.mozilla.org/xpcom-and-internal-strings-in-gecko/ video], [https://dbaron.org/talks/2014-03-20-xpcom-string-taipei/speaking-notes speaking notes]<br />
<br />
=== String ===<br />
<br />
XPCOM has string classes for representing sequences of characters. Typical C++ string classes have the goals of encapsulating the memory management of buffers and the issues needed to avoid buffer overruns common in traditional C string handling. Mozilla's string classes have these goals, and also the goal of reducing copying of strings.<br />
<br />
(There is a second set of string classes in xpcom/glue for callers outside of libxul; these classes are partially source-compatible but have different (worse) performance characteristics. This discussion does not cover those classes.)<br />
<br />
We have two parallel sets of classes, one for strings with 1-byte units (<code>char</code>, which may be signed or unsigned), and one for strings with 2-byte units (<code>char16_t</code>, always unsigned). The classes are named such that the class for 2-byte characters ends with <code>String</code> and the corresponding class for 1-byte characters ends with <code>CString</code>. 2-byte strings are almost always used to encode [http://en.wikipedia.org/wiki/UTF-16 UTF-16]. 1-byte strings are usually used to encode either [http://en.wikipedia.org/wiki/ASCII ASCII] or [http://en.wikipedia.org/wiki/UTF-8 UTF-8], but are sometimes also used to hold data in some other encoding or just byte sequences.<br />
<br />
The string classes distinguish, as part of the type hierarchy, between strings that must have a null-terminator at the end of their buffer (<code>ns[C]String</code>) and strings that are not required to have a null-terminator (<code>ns[C]Substring</code>). <code>ns[C]Substring</code> is the base of the string classes (since it imposes fewer requirements) and <code>ns[C]String</code> is a class derived from it. Functions taking strings as parameters should generally take one of these four types.<br />
<br />
In order to avoid unnecessary copying of string data (which can have significant performance cost), the string classes support different ownership models. All string classes support the following three ownership models dynamically:<br />
* reference counted, copy-on-write, buffers (the default)<br />
* adopted buffers (a buffer that the string class owns, but is not reference counted, because it came from somewhere else)<br />
* dependent buffers, that is, an underlying buffer that the string class does not own, but that the caller that constructed the string guarantees will outlive the string instance<br />
In addition, there is a special string class, <code>nsAuto[C]String</code>, that ''additionally'' contains an internal 64-unit buffer (intended primarily for use on the stack), leading to a fourth ownership model:<br />
* storage within an auto string's stack buffer<br />
Auto strings will prefer reference counting an existing reference-counted buffer over their stack buffer, but will otherwise use their stack buffer for anything that will fit in it.<br />
<br />
There are a number of additional string classes, particularly <code>nsDependent[C]String</code>, <code>nsDependent[C]Substring</code>, and the <code>NS_LITERAL_[C]STRING</code> macros which construct an <code>nsLiteral[C]String</code> which exist primarily as constructors for the other types. These types are really just convenient notation for constructing an <code>ns[C]S[ubs]tring</code> with a non-default ownership mode; they should not be thought of as different types. (The <code>Substring</code>, <code>StringHead</code>, and <code>StringTail</code> functions are also constructors for dependent [sub]strings.) Non-default ownership modes can also be set up using the <code>Rebind</code> and <code>Adopt</code> methods, although the <code>Rebind</code> methods actually live on the derived types, which is probably a mistake (although moving them up would require some care to avoid making an API that easily allows assigning a non-null-terminated buffer to a string whose static type indicates that it is null-terminated).<br />
<br />
Note that the presence of all of these classes imposes some awkwardness in terms of distinctions being available as both static type distinctions and dynamic type distinctions. In general, the only distinctions that should be made statically are 1-byte vs. 2-byte sequences (<code>CString</code> vs <code>String</code>) and whether the buffer is null-terminated or not (<code>Substring</code> vs <code>String</code>). (Does the code actually do a good job of dynamically enforcing the <code>Substring</code> vs. <code>String</code> restriction?)<br />
<br />
TODO: buffer growth, concatenation optimizations<br />
<br />
TODO: encoding conversion, what's validated and what isn't<br />
<br />
TODO: "string API", nsAString (historical)<br />
<br />
* Code: xpcom/string/<br />
* Bugzilla: Core::String</div>Dbaronhttps://wiki.mozilla.org/index.php?title=Gecko:Overview&diff=1193182Gecko:Overview2018-05-02T20:23:23Z<p>Dbaron: /* XPCOM */ add link to video</p>
<hr />
<div>This document attempts to give an overview of the different parts of<br />
Gecko, what they do, and why they do it, say where the code for them is<br />
within the repository, and link to more specific documentation (when<br />
available) covering the details of that code. '''It is not yet complete.''' Maintainers of these<br />
areas of code should correct errors, add information, and add links to<br />
more detailed documentation (since this document is intended to remain<br />
an overview, not complete documentation).<br />
<br />
__TOC__<br />
<br />
== Browsers, Frames, and Document Navigation ==<br />
<br />
=== Docshell ===<br />
<br />
The user of a Web browser can change the page shown in that browser in<br />
many ways: by clicking a link, loading a new URL, using the forward and<br />
back buttons, or other ways. This can happen inside a space we'll call<br />
a '''browsing context'''; this space can be a browser window, a tab, or a frame<br />
or iframe within a document. The toplevel data structures within Gecko<br />
represent this browsing context; they contain other data structures<br />
representing the individual pages displayed inside of it (most<br />
importantly, the current one). In terms of implementation, these two<br />
types of navigation, the top level of a browser and the frames within<br />
it, largely use the same data structures.<br />
<br />
In Gecko, the '''docshell''' is the toplevel object responsible for<br />
managing a single browsing context. It, and the associated '''session history''' code, <br />
manage the navigation between pages inside of a<br />
docshell. (Note the difference between session history, which is a<br />
sequence of pages in a single browser session, used for recording information<br />
for back and forward navigation, and global history, which is the<br />
history of pages visited and associated times, regardless of browser<br />
session, used for things like link coloring and address autocompletion.)<br />
<br />
There are relatively few objects in Gecko that are associated with a<br />
docshell rather than being associated with a particular one of the pages<br />
inside of it. Most such objects are attached to the docshell. An important object associated with the docshell is the nsGlobalWindowOuter which is what the HTML5 spec refers to as a WindowProxy (into which Window objects, as implemented by nsGlobalWindowInner, are loaded). See the DOM section below for more information on<br />
this.<br />
<br />
The most toplevel object for managing the contents of a particular page<br />
being displayed within a docshell is a document viewer (see layout).<br />
Other important objects associated with this presentation are the<br />
document (see DOM) and the pres(entation) shell and pres(entation)<br />
context (see layout).<br />
<br />
[[File:WebNavigation.png|thumb|400px|<xul:browser>, frameloader and docshell in single process configuration]]<br />
<br />
Docshells are organized into a tree. If a docshell has a non-null parent, then it corresponds to a subframe in whatever page is currently loaded in the parent docshell, and the corresponding subframe element (for example, an iframe) is called a '''browsing context container'''. In Gecko, a browsing context container would implement <code>[https://dxr.mozilla.org/mozilla-central/rev/f9a5e9ed62103c84e4cde915f4d08f1ce71be83e/dom/base/nsIFrameLoader.idl#271 nsIFrameLoaderOwner]</code> to hold a '''frameloader''', which holds and manages the docshell. <br />
<br />
One of the most interfaces docshell implemented is <code>[https://dxr.mozilla.org/mozilla-central/source/docshell/base/nsIWebNavigation.idl nsIWebNavigation]</code>. It defines major functions of a browsing context, such as <code>loadURI</code> / <code>goBack</code> / <code>goForward</code> and <code>reload</code>. In single process configuration of desktop Firefox, <code><xul:browser></code> (which represents a tab) operates on docshell through <code>nsIWebNavigation</code>, as shown in the right figure.<br />
<br />
* code: mozilla/docshell/<br />
* bugzilla: Core::Document Navigation<br />
* documentation: [[DocShell:Home Page]]<br />
<br />
=== Session History ===<br />
<br />
In order to keep the session history of subframes after the root document is unloaded and docshells of subframes are destroyed, only the root docshell of a docshell tree manages the session history (this does not match the conceptual model in the HTML5 spec and may be subject to change).<br />
<br />
As an example to explain the structure of session history implementation in Gecko, consider there's a tab A, which loads document 1; in document 1, there are iframe B & C, which loads document 2 & 3, respectively. Later, an user navigates iframe B to document 4. The following figures show the conceptual model of the example, and the corresponding session history structure.<br />
<br />
{| <br />
| [[File:BrowsingContextExample1.png|thumb|190px|Conceptual model representation; color denotes current visible active documents]]<br />
| [[File:SHistoryExample1.png|thumb|180px|Session history structure; color denotes current transaction / entries]]<br />
|}<br />
<br />
In Gecko, a [https://dxr.mozilla.org/mozilla-central/source/docshell/shistory/nsSHistory.h session history] object holds a list of [https://dxr.mozilla.org/mozilla-central/source/docshell/shistory/nsSHTransaction.h transactions] (denoted as T1 & T2 in the figure); each transaction points to a tree of [https://dxr.mozilla.org/mozilla-central/source/docshell/shistory/nsSHEntry.h entries]; each entry records the docshell it associated to, and a URL. Now that if we navigate the tab to a different root document 5, which includes an iframe D with document 6, then it becomes:<br />
<br />
{| <br />
| [[File:BrowsingContextExample2.png|thumb|275px|Conceptual model representation]]<br />
| [[File:SHistoryExample2.png|thumb|250px|Session history structure]]<br />
|}<br />
<br />
=== Embedding ===<br />
<br />
To be written (and maybe rewritten if we get an IPC embedding API).<br />
<br />
[[File:WebNavigationE10S.png|thumb|500px|<xul:remote-browser>, frameloader and docshell in multiprocess configuration. The horizontal dash-lines represent inter-process communication]]<br />
<br />
=== Multi-process and IPC ===<br />
<br />
In a multi-process desktop Firefox, a tab is managed by <code>[https://dxr.mozilla.org/mozilla-central/source/toolkit/content/widgets/remote-browser.xml <xul:remote-browser>]</code>. It still operates on nsIWebNavigation, but in this case the docshell is in a remote process and can not be accessed directly. The encapsulation of remote nsIWebNavigation is done by the javascript-implemented <code>[https://dxr.mozilla.org/mozilla-central/source/toolkit/components/remotebrowserutils/RemoteWebNavigation.js RemoteWebNavigation]</code>.<br />
<br />
In this configuration, the frameloader of a root docshell lives in parent process, so it can not access docshell directly either. Instead, it holds a <code>[https://dxr.mozilla.org/mozilla-central/source/dom/ipc/TabParent.h TabParent]</code> instance to interact with <code>[https://dxr.mozilla.org/mozilla-central/source/dom/ipc/TabChild.h TabChild]</code> in child-process. At C/C++ level, the communication across processes for a single tab is through the '''PBrowser''' IPC protocol implemented by TabParent and TabChild, while at the javascript level it's done by '''message manager''' (which is ontop of PBrowser). RemoteWebNavigation, for example, sends messages to <code>[https://dxr.mozilla.org/mozilla-central/source/toolkit/content/browser-child.js browser-child.js]</code> in content process through message manager.<br />
<br />
== Networking ==<br />
<br />
The network library Gecko uses is called Necko. Necko APIs are largely organized around three concepts: '''URI objects''', '''protocol handlers''', and '''channels'''.<br />
<br />
=== Protocol handlers ===<br />
A '''protocol handler''' is an XPCOM service associated with a particular URI scheme or network protocol. Necko includes protocol handlers for HTTP, FTP, the data: URI scheme, and various others. Extensions can implement protocol handlers of their own.<br />
<br />
A protocol handler implements the <code>[https://dxr.mozilla.org/mozilla-central/source/netwerk/base/nsIProtocolHandler.idl nsIProtocolHandler]</code> API, which serves three primary purposes:<br />
# Providing metadata about the protocol (its security characteristics, whether it requires actual network access, what the corresponding URI scheme is, what TCP port the protocol uses by default).<br />
# Creating URI objects for the protocol's scheme.<br />
# Creating channel objects for the protocol's URI objects<br />
<br />
Typically, the built-in I/O service (<code>[https://dxr.mozilla.org/mozilla-central/source/netwerk/base/nsIIOService2.idl nsIIOService]</code>) is responsible for finding the right protocol handler for URI object creation and channel creation, while a variety of consumers queries protocol metadata. Querying protocol metadata is the recommended way to handle any sort of code that needs to have different behavior for different URI schemes. In particular, unlike whitelists or blacklists, it correctly handles the addition of new protocols.<br />
<br />
A service can register itself as a protocol handler by registering for the contract ID <code>"@mozilla.org/network/protocol;1?name=SSSSS"</code> where <code>SSSS</code> is the URI scheme for the protocol (e.g. "http", "ftp", and so forth).<br />
<br />
=== URI objects ===<br />
URI objects, which implement the <code>[https://dxr.mozilla.org/mozilla-central/source/netwerk/base/nsIURI.idl nsIURI]</code> API, are a way of representing URIs and IRIs. Their main advantage over strings is that they do basic syntax checking and canonicalization on the URI string that they're provided with. They also provide various accessors to extract particular parts of the URI and provide URI equality comparisons. URIs that correspond to hierarchical schemes implement the additional <code>[https://dxr.mozilla.org/mozilla-central/source/netwerk/base/nsIURL.idl nsIURL]</code> interface, which exposes even more accessors for breaking out parts of the URI.<br />
<br />
URI objects are typically created by calling the <code>newURI</code> method on the I/O service, or in C++ by calling the <code>NS_NewURI</code> utility function. This makes sure to create the URI object using the right protocol handler, which ensures that the right kind of object is created. Direct creation of URIs via <code>createInstance</code> is reserved for protocol handler implementations.<br />
<br />
=== Channels ===<br />
[https://dxr.mozilla.org/mozilla-central/source/netwerk/base/nsIChannel.idl Channels] are the Necko representation of a single request/response interaction with a server. A channel is created by calling the <code>newChannel</code> method on the [https://dxr.mozilla.org/mozilla-central/source/netwerk/base/nsIIOService.idl I/O service], or in C++ by calling the <code>[https://dxr.mozilla.org/mozilla-central/search?q=function%3ANS_NewChannel&case=true NS_NewChannel]</code> utility function. The channel can then be configured as needed, and finally its <code>asyncOpen</code> method can be called. This method takes an <code>[https://dxr.mozilla.org/mozilla-central/source/netwerk/base/nsIStreamListener.idl nsIStreamListener]</code> as an argument.<br />
<br />
If <code>asyncOpen</code> has returned successfully, the channel guarantees that it will asynchronously call the <code>onStartRequest</code> and <code>onStopRequest</code> methods on its stream listener. This will happen even if there are network errors that prevent Necko from actually performing the requests. Such errors will be reported in the channel's status and in the <code>status</code> argument to <code>onStopRequest</code>.<br />
<br />
If the channel ends up being able to provide data, it will make one or more <code>onDataAvailable</code> on its listener after calling <code>onStartRequest</code> and before calling <code>onStopRequest</code>. For each call, the listener is responsible for either returning an error or reading the entire data stream passed in to the call.<br />
<br />
If an error is returned from either <code>onStartRequest</code> or <code>onDataAvailable</code>, the channel must act as if it has been canceled with the corresponding error code.<br />
<br />
A channel has two URI objects associated with it. The <code>originalURI</code> of the channel is the URI that was originally passed to <code>newChannel</code> to create the channel that then had <code>asyncOpen</code> called on it. The <code>URI</code> is the URI from which the channel is reading data. These can be different in various cases involving protocol handlers that forward network access to other protocol handlers, as well as in situations in which a redirect occurs (e.g. following an HTTP 3xx response). In redirect situations, a new channel object will be created, but the originalURI will be propagated from the old channel to the new channel.<br />
<br />
Note that the <code>nsIRequest</code> that's passed to onStartRequest must match the one passed to onDataAvailable and onStopRequest, but need not be the original channel that asyncOpen was called on. In particular, when an HTTP redirect happens the request argument to the callbacks will be the post-redirect channel.<br />
<br />
TODO: crypto?<br />
<br />
== Document rendering pipeline ==<br />
<br />
Some of the major components of Gecko can be described as steps on the<br />
path from an HTML document coming in from the network to the graphics<br />
commands needed to render that document. An HTML document is a<br />
serialization of a tree structure. (FIXME: add diagram) The HTML<br />
parser and content sink create an in-memory representation of this tree,<br />
which we call the '''DOM tree''' or '''content tree'''.<br />
Many JavaScript APIs operate on the content tree. Then, in<br />
layout, we create a second tree, the '''frame tree''' (or<br />
'''rendering tree''') that is a similar shape to the content tree,<br />
but where each node in the tree represents a rectangle (except in SVG<br />
where they represent other shapes). We then compute the positions of<br />
the nodes in the frame tree (called '''frames''') and paint them<br />
using our cross-platform graphics APIs (which, underneath, map to<br />
platform-specific graphics APIs).<br />
<br />
See [http://dbaron.org/talks/ David Baron's "Fast CSS: How Browsers Lay Out Web Pages" talk] for an overview of the pipeline in a presentation format.<br />
<br />
=== Parser ===<br />
<br />
The parser's job is to transform a character stream into a tree<br />
structure, with the help of the content sink classes.<br />
<br />
HTML is parsed using a parser implementing the parsing algorithm in the<br />
HTML specification (starting with HTML5). Much of this parser is<br />
translated from Java, and changes are made to the Java version. This<br />
parser in parser/html/. The parser is driven by the output of the networking layer (see nsHtml5StreamParser::OnDataAvailable). The HTML5 parser is capable of parsing off the main thread which is the normal case. It also parses on the main thread to be able to synchronously handle things such as innerHTML modifications.<br />
<br />
The codebase still has the previous generation HTML parser, which is<br />
still used for a small number of things, though we hope to be able to<br />
remove it entirely soon. This parser is in parser/htmlparser/.<br />
<br />
XML is parsed using the expat library (parser/expat/) and code that<br />
wraps it (parser/xml/). This is a non-validating parser; however, it<br />
loads certain DTDs to support XUL localization.<br />
<br />
=== DOM / Content ===<br />
<br />
The content tree or DOM tree is the central data structure for Web<br />
pages. It is a tree structure, initially created from the tree<br />
structure expressed in the HTML or XML markup. The nodes in the tree<br />
implement major parts of the DOM (Document Object Model) specifications.<br />
The nodes themselves are part of a class hierarchy rooted at<br />
<code>nsINode</code>; different derived classes are used for things such<br />
as text nodes, the document itself, HTML elements, SVG elements, etc.,<br />
with further subclasses of many of these types (e.g., for specific HTML<br />
elements). Many of the APIs available to script running in Web pages<br />
are associated with these nodes. The tree structure persists while the<br />
Web pages is displayed, since it stores much of state associated with<br />
the Web page. The code for these nodes lives in the content/ directory.<br />
<br />
The DOM APIs are not threadsafe. DOM nodes can be accessed only from<br />
the main thread (also known as the UI thread (user interface thread)) of<br />
the application.<br />
<br />
There are also many other APIs available to Web pages that are not APIs<br />
on the nodes in the DOM tree. Many of these other APIs also live in the<br />
same directories, though some live in content/ and some in dom/. These<br />
include APIs such as the DOM event model.<br />
<br />
The dom/ directory also includes some of the code needed to expose Web<br />
APIs to JavaScript (in other words, the glue code between JavaScript and<br />
these APIs). For an overview, see [https://ask.mozilla.org/question/390/how-is-the-web-exposed-dom-implemented/ DOM API Implementation]. See [[#Scripting|Scripting]] below for details of the JS engine.<br />
<br />
TODO: Internal APIs vs. DOM APIs.<br />
<br />
TODO: Mutation observers / document observers.<br />
<br />
TODO: Reference counting and cycle collection.<br />
<br />
TODO: specification links<br />
<br />
=== Style System ===<br />
<br />
==== Quantum CSS (Stylo) ====<br />
<br />
Starting with Firefox 57 and later, Gecko makes use of the parallel style system written in Rust that comes from Servo. There's an [https://hacks.mozilla.org/2017/08/inside-a-super-fast-css-engine-quantum-css-aka-stylo/ overview] of this with graphics to help explain what's going on. The [https://github.com/servo/servo/wiki/Layout-Overview Servo wiki] has some more details.<br />
<br />
==== Gecko ====<br />
<br />
The rest of the style section section describes the Gecko style system used in Firefox 56 and earlier. Some bits may still apply, but it likely needs revising.<br />
<br />
In order to display the content, Gecko needs to compute the styles<br />
relevant to each DOM node. It does this based on the model described in<br />
the CSS specifications: this model applies to style specified in CSS<br />
(e.g. by a 'style' element, an 'xml-stylesheet' processing instruction<br />
or a 'style' attribute),<br />
style specified by presentation attributes, and the default style<br />
specified by our own user agent style sheets. There are two major<br />
sets of data structures within the style system:<br />
* first, data structures that represent sources of style data, such as CSS style sheets or data from stylistic HTML attributes<br />
* second, data structures that represent computed style for a given DOM node.<br />
These sets of data structures are mostly distinct (for example, they<br />
store values in different ways).<br />
<br />
The loading of CSS style sheets from the network is managed by the <br />
[https://dxr.mozilla.org/mozilla-central/source/layout/style/Loader.h CSS loader]; <br />
they are then tokenized by the <br />
[https://dxr.mozilla.org/mozilla-central/source/layout/style/nsCSSScanner.h CSS scanner] <br />
and parsed by the <br />
[https://dxr.mozilla.org/mozilla-central/source/layout/style/nsCSSParser.h CSS parser]. <br />
Those that are attached to the document also expose APIs to<br />
script that are known as the CSS Object Model, or CSSOM.<br />
<br />
The style sheets that apply to a document are managed by a class called<br />
the [https://dxr.mozilla.org/mozilla-central/source/layout/style/nsStyleSet.h style set].<br />
The style set interacts with the different types of<br />
style sheets (representing CSS style sheets, presentational<br />
attributes, and 'style' attributes) through two interfaces:<br />
[http://dxr.mozilla.org/mozilla-central/source/layout/style/nsIStyleSheet.h nsIStyleSheet] for basic management of style sheets and<br />
[http://dxr.mozilla.org/mozilla-central/source/layout/style/nsIStyleRuleProcessor.h nsIStyleRuleProcessor] for getting the style data out of them. Usually<br />
the same object implements both interfaces, except in the most important<br />
case, CSS style sheets, where there is a single rule processor for all<br />
of the CSS style sheets in each origin (user/UA/author) of the CSS cascade.<br />
<br />
The computed style data for an element/frame are exposed to the rest of<br />
Gecko through the class mozilla::ComputedStyle (previously called<br />
nsStyleContext). Rather than having a member variable for each<br />
CSS property, it breaks up the properties into groups of related<br />
properties called style structs. These style structs obey the rule that<br />
all of the properties in a single struct either inherit by default (what<br />
the CSS specifications call "Inherited: yes" in the definition of<br />
properties; we call these inherited structs) or all are not inherited by<br />
default (we call these reset structs). Separating the properties in<br />
this way improves the ability to share the structs between similar<br />
ComputedStyle objects and reduce the amount of memory needed to store<br />
the style data. The ComputedStyle API exposes a method for getting each<br />
struct, so you'll see code like<br />
<code>sc->GetStyleText()->mTextAlign</code> for getting the value of the<br />
text-align CSS property. (Frames (see the Layout section below) also<br />
have the same<br />
GetStyle* methods, which just forward the call to the frame's<br />
ComputedStyle.)<br />
<br />
The ComputedStyles form a tree structure, in a shape somewhat like the<br />
content tree (except that we coalesce identical sibling ComputedStyles<br />
rather than keeping two of them around; if the parents have been<br />
coalesced then this can apply recursively and coalasce cousins, etc.;<br />
we do not coalesce parent/child ComputedStyles).<br />
The parent of a ComputedStyle has the style data that the ComputedStyle<br />
inherits from when CSS inheritance occurs. This means that the parent<br />
of the ComputedStyle for a DOM element is generally the ComputedStyle<br />
for that DOM element's parent, since that's how CSS says inheritance<br />
works.<br />
<br />
The process of turning the style sheets into computed style data goes<br />
through three main steps, the first two of which closely relate to the<br />
[http://dxr.mozilla.org/mozilla-central/source/layout/style/nsIStyleRule.h nsIStyleRule] interface, which represents an immutable source of style<br />
data, conceptually representing (and for CSS style rules, directly<br />
storing) a set of property:value pairs. (It is similar to the idea of a<br />
CSS style rule, except that it is immutable; this immutability allows<br />
for significant optimization. When a CSS style rule is changed through<br />
script, we create a new style rule.)<br />
<br />
The first step of going from style sheets to computed style data is<br />
finding the ordered sequence of style rules that apply to an element.<br />
The order represents which rules override which other rules: if two<br />
rules have a value for the same property, the higher ranking one wins.<br />
(Note that there's another difference from CSS style rules: declarations<br />
with !important are represented using a separate style rule.) This is<br />
done by calling one of the nsIStyleRuleProcessor::RulesMatching methods.<br />
The ordered sequence is stored in a<br />
[http://en.wikipedia.org/wiki/Trie trie] called the rule tree: the path<br />
from the root of the rule tree to any (leaf or non-leaf) node in the<br />
rule tree represents a sequence of rules, with the highest ranking<br />
farthest from the root. Each rule node (except for the root) has a<br />
pointer to a rule, but since a rule may appear in many sequences, there<br />
are sometimes many rule nodes pointing to the same rule. Once we have<br />
this list we create a ComputedStyle (or find an appropriate existing<br />
sibling) with the correct parent pointer (for inheritance) and rule node<br />
pointer (for the list of rules), and a few other pieces of information<br />
(like the pseudo-element).<br />
<br />
The second step of going from style sheets to computed style data is<br />
getting the winning property:value pairs from the rules. (This only<br />
provides property:value pairs for some of the properties; the remaining<br />
properties will fall back to inheritance or to their initial values<br />
depending on whether the property is inherited by default.) We do this<br />
step (and the third) for each style struct, the first time it is needed.<br />
This is done in nsRuleNode::WalkRuleTree, where we ask each style rule<br />
to fill in its property:value pairs by calling its MapRuleInfoInto<br />
function. When called, the rule fills in only those pairs that haven't<br />
been filled in already, since we're calling from the highest priority<br />
rule to the lowest (since in many cases this allows us to stop before<br />
going through the whole list, or to do partial computation that just<br />
adds to data cached higher in the rule tree).<br />
<br />
The third step of going from style sheets to computed style data (which<br />
various caching optimizations allow us to skip in many cases) is<br />
actually doing the computation; this generally means we transform the<br />
style data into the data type described in the "Computed Value" line in<br />
the property's definition in the CSS specifications. This<br />
transformation happens in functions called nsRuleNode::Compute*Data,<br />
where the * in the middle represents the name of the style struct. This<br />
is where the transformation from the style sheet value storage format to<br />
the computed value storage format happens.<br />
<br />
Once we have the computed style data, we then store it: if a style struct<br />
in the computed style data doesn't<br />
depend on inherited values or on data from other style structs, then we<br />
can cache it in the rule tree (and then reuse it, without recomputing<br />
it, for any ComputedStyles pointing to that rule node). Otherwise, we<br />
store it on the ComputedStyle (in which case it may be shared<br />
with the ComputedStyle's descendant ComputedStyles).<br />
This is where keeping inherited and<br />
non-inherited properties separate is useful: in the common case of<br />
relatively few properties being specified, we can generally cache the<br />
non-inherited structs in the rule tree, and we can generally share the<br />
inherited structs up and down the ComputedStyle tree.<br />
<br />
The ownership models in style sheet structures are a mix of reference<br />
counted structures (for things accessible from script) and directly<br />
owned structures. ComputedStyles are reference counted, and own their<br />
parents (from which they inherit), and rule nodes are garbage collected<br />
with a simple mark and sweep collector (which often never needs to run).<br />
<br />
* code: [http://dxr.mozilla.org/mozilla-central/source/layout/style/ layout/style/], where most files have useful one line descriptions at the top that show up in DXR<br />
* Bugzilla: Style System (CSS)<br />
* specifications<br />
** [http://www.w3.org/TR/CSS21/ CSS 2.1]<br />
** [http://www.w3.org/TR/css-2010/ CSS 2010, listing stable css3 modules]<br />
** [http://dev.w3.org/csswg/ CSS WG editors drafts] (often more current, but sometimes more unstable than the drafts on the technical reports page)<br />
** [http://dbaron.org/mozilla/visited-privacy Preventing attacks on a user's history through CSS :visited selectors]<br />
* documentation<br />
** [http://www-archive.mozilla.org/newlayout/doc/style-system.html style system documentation] (somewhat out of date)<br />
<br />
=== Layout ===<br />
<br />
Much of the layout code deals with operations on the frame tree (or<br />
rendering tree). In the frame tree, each node represents a rectangle<br />
(or, for SVG, other shapes). The frame tree has a shape similar to the<br />
content tree, since many content nodes have one corresponding frame,<br />
though it differs in a few ways, since some content nodes have more than<br />
one frame or don't have any frames at all. When elements are<br />
display:none in CSS or undisplayed for certain other reasons, they won't<br />
have any frames. When elements are broken across lines or pages, they<br />
have multiple frames; elements may also have multiple frames when<br />
multiple frames nested inside each other are needed to display a single<br />
element (for example, a table, a table cell, or many types of form<br />
controls).<br />
<br />
Each node in the frame tree is an instance of a class derived from<br />
<code>nsIFrame</code>. As with the content tree, there is a substantial<br />
type hierarchy, but the type hierarchy is very different: it includes<br />
types like text frames, blocks and inlines, the various parts of tables,<br />
and the various types of HTML form controls.<br />
<br />
Frames are allocated within an arena owned by the pres shell. Each<br />
frame is owned by its parent; frames are not reference counted, and code<br />
must not hold on to pointers to frames. To mitigate potential security<br />
bugs when pointers to destroyed frames, we use<br />
[http://robert.ocallahan.org/2010/10/mitigating-dangling-pointer-bugs-using_15.html frame poisoning], which takes two parts. When a frame is destroyed<br />
other than at the end of life of the presentation, we fill its memory<br />
with a pattern consisting of a repeated pointer to inaccessible memory,<br />
and then put the memory on a per-frame-class freelist. This means that<br />
if code accesses the memory through a dangling pointer, it will either<br />
crash quickly by dereferencing the poison pattern or it will find a<br />
valid frame.<br />
<br />
Like the content tree, frames must be accessed only from the UI thread.<br />
<br />
The frame tree should not store any important data. While it does<br />
usually persist while a page is being displayed, frames are often<br />
destroyed and recreated in response to certain style changes, and in the<br />
future we may do the same to reduce memory use for pages that are<br />
currently inactive. There were a number of cases where this rule was<br />
violated in the past and we stored important data in the frame tree;<br />
however, most (though not quite all) such cases are now fixed.<br />
<br />
The rectangle represented by the frame is what CSS calls the element's<br />
border box. This is the outside edge of the border (or the inside edge<br />
of the margin). The margin lives outside the border; and the padding<br />
lives inside the border. In addition to nsIFrame::GetRect, we also have<br />
the APIs nsIFrame::GetPaddingRect to get the padding box (the outside<br />
edge of the padding, or inside edge of the border) and<br />
nsIFrame::GetContentRect to get the content box (the outside edge of the<br />
content, or inside edge of the padding). These APIs may produce out of<br />
date results when reflow is needed (or has not yet occurred).<br />
<br />
In addition to tracking a rectangle, frames also track two overflow<br />
areas: visual overflow and scrollable overflow. These overflow areas<br />
represent the union of the area needed by the frame and by all its<br />
descendants. The visual overflow is used for painting-related<br />
optimizations: it is a rectangle covering all of the area that might be<br />
painted when the frame and all of its descendants paint. The scrollable<br />
overflow represents the area that the user should be able to scroll to<br />
to see the frame and all of its descendants. In some cases differences<br />
between the frame's rect and its overflow happen because of descendants<br />
that stick out of the frame; in other cases they occur because of some<br />
characteristic of the frame itself. The two overflow areas are<br />
similar, but there are differences: for example, margins are part of<br />
scrollable overflow but not visual overflow, whereas text-shadows are<br />
part of visual overflow but not scrollable overflow.<br />
<br />
When frames are broken across lines, columns, or pages, we create<br />
multiple frames representing the multiple rectangles of the element.<br />
The first one is the primary frame, and the rest are its continuations<br />
(which are more likely to be destroyed and recreated during reflow).<br />
These frames are linked together as continuations: they have a<br />
doubly-linked list that can be used to traverse the continuations using<br />
nsIFrame::GetPrevContinuation and nsIFrame::GetNextContinuation.<br />
(Currently continuations always have the same style data, though we may<br />
at some point want to break that invariant.)<br />
<br />
Continuations are sometimes siblings of each other, and sometimes not.<br />
For example, if a paragraph contains a span which contains a link, and<br />
the link is split across lines, then the continuations of the span are<br />
siblings (since they are both children of the paragraph), but the<br />
continuations of the link are not siblings (since each continuation of<br />
the link is descended from a different continuation of the span).<br />
Traversing the entire frame tree does '''not''' require considering<br />
continuations, since all of the continuations are descendants of the<br />
element containing the break.<br />
<br />
We also use continuations for cases (most importantly, bidi reordering,<br />
where left-to-right text and right-to-left text need to be separated<br />
into different continuations since they may not form a contiguous<br />
rectangle) where the continuations should not be rewrapped during<br />
reflow: we call these continuations fixed rather than fluid.<br />
nsIFrame::GetNextInFlow and nsIFrame::GetPrevInFlow traverse only the<br />
fluid continuations and do not cross fixed continuation boundaries.<br />
<br />
If an inline frame has non-inline children, then we split the original <br />
inline frame into parts. The original inline's children are <br />
distributed into these parts like so- The children of the original <br />
inline are grouped into runs of inline and non-inline and runs of <br />
inline get an inline parent while runs of non-inline get an anonymous <br />
block parent. This is 'ib-splitting' or block-inside-inline-splitting. <br />
This splitting proceeds recursively up the frame tree until all <br />
non-inlines inside inlines are ancestors of a block frame with anonymous <br />
block wrappers in between. This splitting maintains the relative order<br />
between these child frames and the relationship between the parts of a <br />
split inline is maintained using an ib-sibling chain. It is important <br />
to note that any wrappers created during frame construction (such as <br />
for tables) may not be included in the ib-sibling chain depending on <br />
when this wrapper creation takes place. <br />
<br />
TODO: nsBox craziness from https://bugzilla.mozilla.org/show_bug.cgi?id=524925#c64<br />
<br />
TODO: link to documentation of block and inline layout<br />
<br />
TODO: link to documentation of scrollframes<br />
<br />
TODO: link to documentation of XUL frame classes<br />
<br />
Code (note that most files in base and generic have useful one line descriptions at the top that show up in DXR):<br />
* [http://dxr.mozilla.org/mozilla-central/source/layout/base/ layout/base/] contains objects that coordinate everything and a bunch of other miscellaneous things<br />
* [http://dxr.mozilla.org/mozilla-central/source/layout/generic/ layout/generic/] contains the basic frame classes as well as support code for their reflow methods (ReflowInput, ReflowOutput)<br />
* [http://dxr.mozilla.org/mozilla-central/source/layout/forms/ layout/forms/] contains frame classes for HTML form controls<br />
* [http://dxr.mozilla.org/mozilla-central/source/layout/tables/ layout/tables/] contains frame classes for CSS/HTML tables<br />
* [http://dxr.mozilla.org/mozilla-central/source/layout/mathml/ layout/mathml/] contains frame classes for MathML<br />
* [http://dxr.mozilla.org/mozilla-central/source/layout/svg/ layout/svg/] contains frame classes for SVG<br />
* [http://dxr.mozilla.org/mozilla-central/source/layout/xul/ layout/xul/] contains frame classes for the XUL box model and for various XUL widgets<br />
<br />
Bugzilla:<br />
* All of the components whose names begin with "Layout" in the "Core" product<br />
<br />
==== Frame Construction ====<br />
<br />
Frame construction is the process of creating frames. This is done when styles change in ways that require frames to be created or recreated or when nodes are inserted into the document. The content tree and the frame tree don't have quite the same shape, and the frame construction process does some of the work of creating the right shape for the frame tree. It handles the aspects of creating the right shape that don't depend on layout information. So for example, frame construction handles the work needed to implement [http://www.w3.org/TR/CSS21/tables.html#anonymous-boxes table anonymous objects] but does not handle frames that need to be created when an element is broken across lines or pages.<br />
<br />
The basic unit of frame construction is a run of contiguous children of a single parent element. When asked to construct frames for such a run of children, the frame constructor first determines, based on the siblings and parent of the nodes involved, where in the frame tree the new frames should be inserted. Then the frame constructor walks through the list of content nodes involved and for each one creates a temporary data structure called a '''frame construction item'''. The frame construction item encapsulates various information needed to create the frames for the content node: its style data, some metadata about how one would create a frame for this node based on its namespace, tag name, and styles, and some data about what sort of frame will be created. This list of frame construction items is then analyzed to see whether constructing frames based on it and inserting them at the chosen insertion point will produce a valid frame tree. If it will not, the frame constructor either fixes up the list of frame construction items so that the resulting frame tree would be valid or throws away the list of frame construction items and requests the destruction and re-creation of the frame for the parent element so that it has a chance to create a list of frame construction items that it <em>can</em> fix up.<br />
<br />
Once the frame constructor has a list of frame construction items and an insertion point that would lead to a valid frame tree, it goes ahead and creates frames based on those items. Creation of a non-leaf frame recursively attempts to create frames for the children of that frame's element, so in effect frames are created in a depth-first traversal of the content tree.<br />
<br />
The vast majority of the code in the frame constructor, therefore, falls into one of these categories:<br />
* Code to determine the correct insertion point in the frame tree for new frames.<br />
* Code to create, for a given content node, frame construction items. This involves some searches through static data tables for metadata about the frame to be created.<br />
* Code to analyze the list of frame construction items.<br />
* Code to fix up the list of frame construction items.<br />
* Code to create frames from frame construction items.<br />
<br />
Code: [http://dxr.mozilla.org/mozilla-central/source/layout/base/nsCSSFrameConstructor.h layout/base/nsCSSFrameConstructor.h] and [http://dxr.mozilla.org/mozilla-central/source/layout/base/nsCSSFrameConstructor.cpp layout/base/nsCSSFrameConstructor.cpp]<br />
<br />
==== Reflow ====<br />
<br />
Reflow is the process of computing the positions and sizes of frames. (After all,<br />
frames represent rectangles, and at some point we need to figure out<br />
exactly *what* rectangle.) Reflow is done recursively, with each<br />
frame's Reflow method calling the Reflow methods on that frame's<br />
descendants.<br />
<br />
In many cases, the correct results are defined by CSS specifications<br />
(particularly [http://www.w3.org/TR/CSS21/visudet.html CSS 2.1]). In some cases, the details are not defined by<br />
CSS, though in some (but not all) of those cases we are constrained by<br />
Web compatibility. When the details are defined by CSS, however, the<br />
code to compute the layout is generally structured somewhat differently<br />
from the way it is described in the CSS specifications, since the CSS<br />
specifications are generally written in terms of constraints, whereas<br />
our layout code consists of algorithms optimized for incremental<br />
recomputation.<br />
<br />
The reflow generally starts from the root of the frame tree, though some other<br />
types of frame can act as reflow roots and start a reflow from them.<br />
Reflow roots must obey the invariant that a change inside one of their<br />
descendants never changes their rect or overflow areas (though currently<br />
scrollbars are reflow roots but don't quite obey this invariant).<br />
<br />
In many cases, we want to reflow a part of the frame tree, and we want<br />
this reflow to be efficient. For example, when content is added or<br />
removed from the document tree or when styles change, we want the amount<br />
of work we need to redo to be proportional to the amount of content. We<br />
also want to efficiently handle a series of changes to the same content.<br />
<br />
To do this, we maintain two bits on frames:<br />
[http://dxr.mozilla.org/mozilla-central/search?q=var%3ANS_FRAME_IS_DIRTY&case=true&redirect=true NS_FRAME_IS_DIRTY]<br />
indicates that a frame and all of its descendants require reflow.<br />
[http://dxr.mozilla.org/mozilla-central/search?q=var%3ANS_FRAME_HAS_DIRTY_CHILDREN&case=true&redirect=true NS_FRAME_HAS_DIRTY_CHILDREN]<br />
indicates that a frame has a descendant that<br />
is dirty or has had a descendant removed (i.e., that it has a child that<br />
has NS_FRAME_IS_DIRTY or NS_FRAME_HAS_DIRTY_CHILDREN or it had a child<br />
removed). These bits allow coalescing of multiple updates; this<br />
coalescing is done in nsPresShell, which tracks the set of reflow roots<br />
that require reflow. The bits are set during calls to<br />
nsPresShell::FrameNeedsReflow and are cleared during reflow.<br />
<br />
The layout algorithms used by many of the frame classes are those<br />
specified in CSS, which are based on the traditional document formatting<br />
model, where widths are input and heights are output.<br />
<br />
In some cases, however, widths need to be determined based on the<br />
content. This depends on two ''intrinsic widths'': the minimum<br />
intrinsic width (see [http://dxr.mozilla.org/search?q=type%3AnsIFrame%20function%3AGetMinWidth&tree=mozilla-central nsIFrame::GetMinWidth]) and the preferred intrinsic<br />
width (see [http://dxr.mozilla.org/search?q=type%3AnsIFrame%20function%3AGetPrefWidth&tree=mozilla-central nsIFrame::GetPrefWidth]). The concept of what these widths<br />
represent is best explained by describing what they are on a paragraph<br />
containing only text: in such a paragraph the minimum intrinsic width<br />
is the width of the longest word, and the preferred intrinsic width is<br />
the width of the entire paragraph laid out on one line.<br />
<br />
Intrinsic widths are invalidated separately from the dirty bits<br />
described above. When a caller informs the pres shell that a frame<br />
needs reflow (nsIPresShell::FrameNeedsReflow), it passes one of three<br />
options:<br />
* eResize indicates that no intrinsic widths are dirty<br />
* eTreeChange indicates that intrinsic widths on it and its ancestors are dirty (which happens, for example, if new children are added to it)<br />
* eStyleChange indicates that intrinsic widths on it, its ancestors, and its descendants are dirty (for example, if the font-size changes)<br />
<br />
Reflow is the area where the XUL frame classes (those that inherit from<br />
nsBoxFrame or nsLeafBoxFrame) are most different from the rest. Instead<br />
of using nsIFrame::Reflow, they do their layout computations using<br />
intrinsic size methods called GetMinSize, GetPrefSize, and GetMaxSize<br />
(which report intrinsic sizes in two dimensions) and a final layout<br />
method called Layout. In many cases these methods defer some of the<br />
computation to a separate object called a layout manager.<br />
<br />
When an individual frame's Reflow method is called, most of the input is<br />
provided on an object called ReflowInput and the output is filled<br />
in to an object called ReflowOutput. After reflow, the caller<br />
(usually the parent) is responsible for setting the frame's size based<br />
on the metrics reported. (This can make some computations during reflow<br />
difficult, since the new size is found in either the reflow state or the<br />
metrics, but the frame's size is still the old size. However, it's<br />
useful for invalidating the correct areas that need to be repainted.)<br />
<br />
One major difference worth noting is that in XUL layout, the size of the<br />
child is set prior to its parent calling its Layout method. (Once<br />
invalidation uses display lists and is no longer tangled up in Reflow,<br />
it may be worth switching non-XUL layout to work this way as well.)<br />
<br />
==== Painting ====<br />
<br />
TODO: display lists (and event handling)<br />
<br />
TODO: layers<br />
<br />
==== Pagination ====<br />
<br />
The concepts behind pagination (also known as fragmentation) are a bit complicated, so for now we've split them off into a separate document: [[Gecko:Continuation_Model]]. This code is used for printing, print-preview, and multicolumn frames.<br />
<br />
=== Dynamic change handling along the rendering pipeline ===<br />
<br />
The ability to make changes to the DOM from script is a major feature of the Web platform. Web authors rely on the concept (though there are a few exceptions, such as animations) that changing the DOM from script leads to the same rendering that would have resulted from starting from that DOM tree. They also rely on the performance characteristics of these changes: small changes to the DOM that have small effects should have proportionally small processing time. This means that Gecko needs to efficiently propagate changes from the content tree to style, the frame tree, the geometry of the frame tree, and the screen.<br />
<br />
For many types of changes, however, there is substantial overhead to processing a change, no matter how small. For example, reflow must propagate from the top of the frame tree down to the frames that are dirty, no matter how small the change. One very common way around this is to batch up changes. We batch up changes in lots of ways, for example:<br />
* The content sink adds multiple nodes to the DOM tree before notifying listeners that they've been added. This allows notifying once about an ancestor rather than for each of its descendants, or notifying about a group of descendants all at once, which speeds up the processing of those notifications.<br />
* We batch up nodes that require style reresolution (recomputation of selector matching and processing the resulting style changes). This batching is tree based, so it not only merges multiple notifications on the same element, but also merges a notification on an ancestor with a notification on its descendant (since ''some'' of these notifications imply that style reresolution is required on all descendants).<br />
* We wait to reconstruct frames that require reconstruction (after destroying frames eagerly). This, like the tree-based style reresolution batching, avoids duplication both for same-element notifications and ancestor-descendant notifications, even though it doesn't actually do any tree-based caching.<br />
* We postpone doing reflows until needed. As for style reresolution, this maintains tree-based dirty bits (see the description of NS_FRAME_IS_DIRTY and NS_FRAME_HAS_DIRTY_CHILDREN under Reflow).<br />
* We allow the OS to queue up multiple invalidates before repainting (though we will likely switch to controlling that ourselves). This leads to a single repaint of some set of pixels where there might otherwise have been multiple (though it may also lead to more pixels being repainted if multiple rectangles are merged to a single one).<br />
<br />
Having changes buffered up means, however, that various pieces of information (layout, style, etc.) may not be up-to-date. Some things require up-to-date information: for example, we don't want to expose the details of our buffering to Web page script since the programming model of Web page script assumes that DOM changes take effect "immediately", i.e., that the script shouldn't be able to detect any buffering. Many Web pages depend on this.<br />
<br />
We therefore have ways to flush these different sorts of buffers. There are methods called FlushPendingNotifications on nsIDocument and nsIPresShell, that take an argument of what things to flush:<br />
* Flush_Content: create all the content nodes from data buffered in the parser<br />
* Flush_ContentAndNotify: the above, plus notify document observers about the creation of all nodes created so far<br />
* Flush_Style: the above, plus make sure style data are up-to-date<br />
* Flush_Frames: the above, plus make sure all frame construction has happened (currently the same as Flush_Style)<br />
* Flush_InterruptibleLayout: the above, plus perform layout (Reflow), but allow interrupting layout if it takes too long<br />
* Flush_Layout: the above, plus ensure layout (Reflow) runs to completion<br />
* Flush_Display (should never be used): the above, plus ensure repainting happens<br />
<br />
The major way that notifications of changes propagate from the content code to layout and other areas of code is through the nsIDocumentObserver and nsIMutationObserver interfaces. Classes can implement this interface to listen to notifications of changes for an entire document or for a subtree of the content tree.<br />
<br />
WRITE ME: ... layout document observer implementations<br />
<br />
TODO: how style system optimizes away rerunning selector matching<br />
<br />
TODO: style changes and nsChangeHint<br />
<br />
=== Refresh driver ===<br />
<br />
== Graphics ==<br />
[https://wiki.mozilla.org/Platform/GFX Wiki page] | [https://wiki.mozilla.org/index.php?title=Platform/GFX/Contribute contribute]<br />
<br />
==== Painting/Rasterizing ====<br />
<br />
Painting/rendering/rasterizing is the step where graphical primitives (such as a command to fill an [https://developer.mozilla.org/en-US/docs/Web/SVG SVG] circle, or a [https://developer.mozilla.org/en-US/docs/Web/Guide/Graphics/Drawing_graphics_with_canvas canvas] command to stroke a path between x, y, z, or the internally produced command to draw the edge of an HTML div's border) are used to color in the pixels of a surface so that the surface "displays" those rasterized primitives.<br />
<br />
The platform independent library that gecko uses to render is [http://dxr.mozilla.org/mozilla-central/source/gfx/2d/2D.h Moz2D]. Gecko code paints into Moz2D DrawTarget objects (the DrawTarget baseclass having multiple platform dependent subclasses). (At least this is where gecko is going - for now there is still significant amounts of code that uses [http://dxr.mozilla.org/mozilla-central/source/gfx/thebes/gfxContext.h Thebes gfxContext] objects or the even older nsRenderingContext objects. Objects of these types now always wrap a DrawTarget so all painting does now go through Moz2D, but conversion to use the wrapped DrawTargets directly is taking time since consumer code can sometimes need to be radically rewritten to fit the Moz2D API and immediate mode paradigm.)<br />
<br />
==== Compositing ====<br />
<br />
The compositing stage of the rendering pipeline is operated by the [http://dxr.mozilla.org/mozilla-central/source/gfx/layers/ gfx/layers] module.<br />
<br />
Different parts of a web page can sometimes be painted into intermediate surfaces retained by layers. It can be convenient to think of layers as the layers in image manipulation programs like The Gimp or Photoshop. Layers are organized as a tree. Layers are primarily used to minimize invalidating and repainting when elements are being animated independently of one another in a way that can be optimized using layers (e.g. opacity or transform animations), and to enable some effects (such as transparency and 3D transforms).<br />
<br />
Compositing is the action of flattening the layers into the final image that is shown on the screen.<br />
<br />
On some platform, compositing happens on the Content thread. However, on other platforms we composite on a separate thread (Off-main-thread compositing, or OMTC). OMTC is at the moment the default behavior on mobile platforms, but the goal is to do it on all platforms in the long run.<br />
<br />
The Layers architecture is built on the following notions:<br />
* Compositor: an object that can draw quads on the screen (or on an off-screen render target).<br />
* Texture: an object that contains image data.<br />
* Compositable: an object that can manipulate one or several textures, and knows how to present them to the compositor<br />
* Layer: an element of the layer tree. A layer usually doesn't know much about compositing: it uses a compositable to do the work. Layers are mostly nodes of the layer tree.<br />
<br />
[[File:LayersRefactoring.png|thumb|650px|New layers architecture, with OGL backend]]<br />
<br />
The above abstractions are sufficient to perform compositing on the main thread, but on the OMTC case, we need a mechanism to synchronize a client layer tree that is constructed on the content thread, and a host layer tree that is used for compositing on the compositor thread.<br />
This synchronization process must ensure that the host layer tree reflects the state of the current layer tree while remaining in a consistent state, and must transfer texture data from a thread to the other. Moreover, on some platforms the content and compositor threads may live in separate processes.<br />
<br />
To perform this synchronization, we use the IPDL IPC framework. IPDL lets us describe communications protocols and actors in a domain specific language. for more information about IPDL, read https://wiki.mozilla.org/IPDL<br />
<br />
When the client layer tree is modified, we record modifications into messages that are sent together to the host side within a transaction. A transaction is basically a list of modifications to the layer tree that have to be applied all at once to preserve consistency in the state of the host layer tree.<br />
<br />
Texture transfer is done by synchronizing texture objects across processes/threads using a couple TextureClient/TextureHost that wrap shared data and provide access to it on both sides. TextureHosts provide access to one or several TextureSource, which has the necessary API to actually composite the texture (TextureClient/Host being more about IPC synchronization than actual compositing.<br />
The logic behind texture transfer (as in single/double/triple buffering, texture tiling, etc) is operated by the CompositableClient and CompositableHost.<br />
<br />
It is important to understand the separation between layers and compositables. Compositables handle all the logic around texture transfer, while layers define the shape of the layer tree. a Compositable is created independently from a layer and attached to it on both sides. While layers transactions can only originate from the content thread, this separation makes it possible for us to have separate compositable transactions between any thread and the compositor thread. We use the ImageBridge IPDL protocol to that end. The Idea of ImageBridge is to create a Compositable that is manipulated on the ImageBridgeThread, and that can transfer/synchronize textures without using the content thread at all. This is very useful for smooth Video compositing: video frames are decoded and passed into the ImageBridge without ever touching the content thread, which could be busy processing reflows or heavy javascript workloads.<br />
<br />
It is worth reading the inline code documentation in the following files:<br />
* [http://dxr.mozilla.org/mozilla-central/source/gfx/layers/Compositor.h gfx/layers/Compositor.h]<br />
* [http://dxr.mozilla.org/mozilla-central/source/gfx/layers/ShadowLayers.h gfx/layers/ShadowLayers.h]<br />
* [http://dxr.mozilla.org/mozilla-central/source/gfx/layers/Layers.h gfx/layers/Layers.h]<br />
* [http://dxr.mozilla.org/mozilla-central/source/gfx/layers/host/TextureHost.h gfx/layers/host/TextureHost.h]<br />
* [http://dxr.mozilla.org/mozilla-central/source/gfx/layers/client/CompositableClient.h gfx/layers/client/CompositableClient.h]<br />
<br />
To visualize how a web page is layered, turn on the pref "layers.draw-borders" in about:config. When this pref is on, the borders of layers and tiles are displayed on top of the content. This only works when using the new Compositor API, that is when off-main-thread compositing is activated. OMTC is activated by default on all mobile platforms, and will progressively get activated on desktop platforms (not yet, though). On platforms where OMTC is not used, this pref has no effect. <br />
<br />
Blog posts with information on Layers that should be integrated here:<br />
<br />
* [http://www.basschouten.com/blog1.php/layers-cross-platform-acceleration Layers: Cross-Platform Acceleration]<br />
* [http://robert.ocallahan.org/2010/04/layers_01.html Layers]<br />
* [http://robert.ocallahan.org/2010/07/retained-layers_16.html Retained Layers]<br />
* [http://chrislord.net/index.php/2011/07/25/shadow-layers-and-learning-by-failing/ Shadow Layers, and learning by failing]<br />
* [http://chrislord.net/index.php/2011/08/16/accelerated-layer-rendering-and-learning-by-some-success/ Accelerated layer-rendering, and learning by (some) success]<br />
* [http://featherweightmusings.blogspot.co.uk/2012/05/mask-layers_26.html Mask Layers]<br />
* [http://featherweightmusings.blogspot.co.uk/2012/05/building-mask-layer.html Building a mask layer]<br />
* [http://featherweightmusings.blogspot.co.uk/2012/06/mask-layers-on-direct3d-backends.html Mask Layers on the Direct3D backends]<br />
* [http://robert.ocallahan.org/2011/09/graphics-api-design.html Graphics API Design]<br />
<br />
==== Async Panning and Zooming ====<br />
<br />
On some of our mobile platforms we have some code that allows the user to do asynchronous (i.e. off-main-thread) panning and zooming of content. This code is the Async Pan/Zoom module (APZ) code and is further documented at [[Platform/GFX/APZ]].<br />
<br />
== Scripting ==<br />
<br />
=== JavaScript Engine ===<br />
<br />
Gecko embeds the SpiderMonkey JavaScript engine (located in js/src). The JS engine includes a number of Just-In-Time compilers (or JITs). SpiderMonkey provides a powerful and extensive embedding API (called the JSAPI). Because of its complexity, using the JSAPI directly is frowned upon, and a number of abstractions have been built in Gecko to allow interacting with the JS engine without using JSAPI directly. Some JSAPI concepts are important for Gecko developers to understand, and they are listed below:<br />
<br />
* Global object: The '''global object''' is the object on which all global variables/properties/methods live. In a web page this is the 'window' object. In other things such as XPCOM components or sandboxes XPConnect creates a global object with a small number of builtin APIs.<br />
* Compartments: A '''compartment''' is a subdivision of the JS heap. The mapping from global objects to compartments is one-to-one; that is, every global object has a compartment associated with it, and no compartment is associated with more than one global object. (NB: There are compartments associated with no global object, but they aren't very interesting). When JS code is running SpiderMonkey has a concept of a "current" compartment. New objects that are created will be created in the "current" compartment and associated with the global object of that compartment.<br />
* When objects in one compartment can see objects in another compartment (via e.g. iframe.contentWindow.foo) '''cross-compartment wrappers''' or '''CCWs''' mediate the interaction between the two compartments. By default CCWs ensure that the current compartment is kept up-to-date when execution crosses a compartment boundary. SpiderMonkey also allows embeddings to extend wrappers with custom behavior to implement security policies, which Gecko uses extensively (see the Security section for more information).<br />
<br />
=== XPConnect ===<br />
<br />
'''XPConnect''' is a bridge between C++ and JS used by XPCOM components exposed to or implemented in JavaScript. XPConnect allows two XPCOM components to talk to each other without knowing or caring which language they are implemented in. XPConnect allows JS code to call XPCOM components by exposing XPCOM interfaces as JS objects, and mapping function calls and attributes from JS into virtual method calls on the underlying C++ object. It also allows JS code to implement an XPCOM component that can be called from C++ by faking the vtable of an interface and translating calls on the interface into JS calls. XPConnect accomplishes this using the vtable data stored in XPCOM TypeLibs (or XPT files) by the XPIDL compiler and a small layer of platform specific code called [https://developer.mozilla.org/en-US/docs/xptcall_FAQ xptcall] that knows how to interact with and impersonate vtables of XPCOM interfaces.<br />
<br />
XPConnect is also used for a small (and decreasing) number of legacy DOM objects. At one time all of the DOM used XPConnect to talk to JS, but we have been replacing XPConnect with the WebIDL bindings (see the next section for more information). Arbitrary XPCOM components are not exposed to web content. XPCOM components that want to be accessible to web content must provide class info (that is, they must QI to nsIClassInfo) and must be marked with the nsIClassInfo::DOM_OBJECT flag. Most of these objects also are listed in dom/base/nsDOMClassInfo.cpp, where the interfaces that should be visible to the web are enumerated. This file also houses some "scriptable helpers" (classes ending in "SH" and implementing nsIXPCScriptable), which are a set of optional hooks that can be used by XPConnect objects to implement more exotic behaviors (such as indexed getters or setters, lazily resolved properties, etc). This is all legacy code, and any new DOM code should use the WebIDL bindings.<br />
<br />
=== WebIDL Bindings ===<br />
<br />
The '''WebIDL bindings''' are a separate bridge between C++ and JS that is specifically designed for use by DOM code. We intend to replace all uses of XPConnect to interface with content JavaScript with the WebIDL bindings. [https://developer.mozilla.org/en-US/docs/Mozilla/WebIDL_bindings Extensive documentation] on the WebIDL bindings is available, but the basic idea is that a binding generator takes WebIDL files from web standards and some configuration data provided by us and generates at build time C++ glue code that sits between the JS engine and the DOM object. This setup allows us to produce faster, more specialized code for better performance at the cost of increased codesize.<br />
<br />
The WebIDL bindings also implement all of the behavior specified in WebIDL, making it possible for new additions to the DOM to behave correctly "out of the box". The binding layer also provides C++ abstractions for types that would otherwise require direct JSAPI calls to handle, such as typed arrays. <br />
<br />
=== Security ===<br />
<br />
Gecko's JS security model is based on the concept of compartments. Every compartment has a '''principal''' associated with it that contains security information such as the '''origin''' of the compartment, whether or not it has system privileges, etc. For the following discussion, '''wrappee''' refers to the underlying object being wrapped, '''scope''' refers to the compartment the object is being wrapped for use in, and '''wrapper''' refers to the object created in '''scope''' that allows it to interact with '''wrappee'''. "Chrome" refers to JS that is built in to the browser or part of an extension, which runs with full privileges, and is contrasted with "content", which is web provided script that is subject to security restrictions and the same origin policy.<br />
<br />
* Xray wrappers: Xray wrappers are used when the scope has chrome privileges and the wrappee is the JS reflection of an underlying DOM object. Beyond the usual CCW duties of making sure that content code does not run with chrome privileges, Xray wrappers also ensure that calling methods or accessing attributes on the wrappee has the "expected" effect. For example, a web page could replace the <code>close</code> method on its window with a JS function that does something completely different. (e.g. <code>window.close = function() { alert("This isn't what you wanted!") };</code>). Overwriting methods in this way (or creating entirely new ones) is referred to as '''expando''' properties. Xrays see through expando properties, invoking the original method/getter/setter if the expando overwrites a builtin or seeing undefined in the expando creates a new property. This allows chrome code to call methods on content DOM objects without worrying about how the page has changed the object.<br />
* Waived xray wrappers: The xray behavior is not always desirable. It is possible for chrome to "waive" the xray behavior and see the actual JS object. The wrapper still guarantees that code runs with the correct privileges, but methods/getters/setters may not behave as expected. This is equivalent to the behavior chrome sees when it looks at non-DOM content JS objects.<br />
* For more information, see the [https://developer.mozilla.org/en-US/docs/Mozilla/Gecko/Script_security MDN page]<br />
* bholley's [https://air.mozilla.org/enter-the-compartment/ Enter the Compartment] talk also provides an overview of our compartment architecture.<br />
<br />
== Images ==<br />
<br />
== Plugins ==<br />
<br />
== Platform-specific layers ==<br />
<br />
* widget<br />
* native theme<br />
* files, networking, other low-level things<br />
* Accessibility APIs<br />
* Input. Touch-input stuff is somewhat described at [[Platform/Input/Touch]].<br />
<br />
== Editor ==<br />
<br />
== Base layers ==<br />
<br />
=== NSPR ===<br />
<br />
NSPR is a library for providing cross-platform APIs for various<br />
platform-specific functions. We tend to be trying to use it as little<br />
as possible, although there are a number of areas (particularly some<br />
network-related APIs and threading/locking primitives) where we use it<br />
quite a bit.<br />
<br />
=== XPCOM ===<br />
<br />
XPCOM is a cross-platform modularity library, modeled on Microsoft COM. It<br />
is an object system in which all objects inherit from the <code>nsISupports</code> interface.<br />
<br />
components and services, contract IDs and CIDs<br />
<br />
prior overuse of XPCOM; littering with XPCOM does not produce modularity<br />
<br />
Base headers (part of xpcom/base/) and data structures. See also mfbt.<br />
<br />
Threading<br />
<br />
xptcall, proxies<br />
<br />
reference counting, cycle collection<br />
<br />
Further documentation:<br />
* XPCOM and Internal Strings in Gecko (talk by David Baron): [https://air.mozilla.org/xpcom-and-internal-strings-in-gecko/ video], [https://dbaron.org/talks/2014-03-20-xpcom-string-taipei/speaking-notes speaking notes]<br />
<br />
=== String ===<br />
<br />
XPCOM has string classes for representing sequences of characters. Typical C++ string classes have the goals of encapsulating the memory management of buffers and the issues needed to avoid buffer overruns common in traditional C string handling. Mozilla's string classes have these goals, and also the goal of reducing copying of strings.<br />
<br />
(There is a second set of string classes in xpcom/glue for callers outside of libxul; these classes are partially source-compatible but have different (worse) performance characteristics. This discussion does not cover those classes.)<br />
<br />
We have two parallel sets of classes, one for strings with 1-byte units (<code>char</code>, which may be signed or unsigned), and one for strings with 2-byte units (<code>char16_t</code>, always unsigned). The classes are named such that the class for 2-byte characters ends with <code>String</code> and the corresponding class for 1-byte characters ends with <code>CString</code>. 2-byte strings are almost always used to encode [http://en.wikipedia.org/wiki/UTF-16 UTF-16]. 1-byte strings are usually used to encode either [http://en.wikipedia.org/wiki/ASCII ASCII] or [http://en.wikipedia.org/wiki/UTF-8 UTF-8], but are sometimes also used to hold data in some other encoding or just byte sequences.<br />
<br />
The string classes distinguish, as part of the type hierarchy, between strings that must have a null-terminator at the end of their buffer (<code>ns[C]String</code>) and strings that are not required to have a null-terminator (<code>ns[C]Substring</code>). <code>ns[C]Substring</code> is the base of the string classes (since it imposes fewer requirements) and <code>ns[C]String</code> is a class derived from it. Functions taking strings as parameters should generally take one of these four types.<br />
<br />
In order to avoid unnecessary copying of string data (which can have significant performance cost), the string classes support different ownership models. All string classes support the following three ownership models dynamically:<br />
* reference counted, copy-on-write, buffers (the default)<br />
* adopted buffers (a buffer that the string class owns, but is not reference counted, because it came from somewhere else)<br />
* dependent buffers, that is, an underlying buffer that the string class does not own, but that the caller that constructed the string guarantees will outlive the string instance<br />
In addition, there is a special string class, <code>nsAuto[C]String</code>, that ''additionally'' contains an internal 64-unit buffer (intended primarily for use on the stack), leading to a fourth ownership model:<br />
* storage within an auto string's stack buffer<br />
Auto strings will prefer reference counting an existing reference-counted buffer over their stack buffer, but will otherwise use their stack buffer for anything that will fit in it.<br />
<br />
There are a number of additional string classes, particularly <code>nsDependent[C]String</code>, <code>nsDependent[C]Substring</code>, and the <code>NS_LITERAL_[C]STRING</code> macros which construct an <code>nsLiteral[C]String</code> which exist primarily as constructors for the other types. These types are really just convenient notation for constructing an <code>ns[C]S[ubs]tring</code> with a non-default ownership mode; they should not be thought of as different types. (The <code>Substring</code>, <code>StringHead</code>, and <code>StringTail</code> functions are also constructors for dependent [sub]strings.) Non-default ownership modes can also be set up using the <code>Rebind</code> and <code>Adopt</code> methods, although the <code>Rebind</code> methods actually live on the derived types, which is probably a mistake (although moving them up would require some care to avoid making an API that easily allows assigning a non-null-terminated buffer to a string whose static type indicates that it is null-terminated).<br />
<br />
Note that the presence of all of these classes imposes some awkwardness in terms of distinctions being available as both static type distinctions and dynamic type distinctions. In general, the only distinctions that should be made statically are 1-byte vs. 2-byte sequences (<code>CString</code> vs <code>String</code>) and whether the buffer is null-terminated or not (<code>Substring</code> vs <code>String</code>). (Does the code actually do a good job of dynamically enforcing the <code>Substring</code> vs. <code>String</code> restriction?)<br />
<br />
TODO: buffer growth, concatenation optimizations<br />
<br />
TODO: encoding conversion, what's validated and what isn't<br />
<br />
TODO: "string API", nsAString (historical)<br />
<br />
* Code: xpcom/string/<br />
* Bugzilla: Core::String</div>Dbaronhttps://wiki.mozilla.org/index.php?title=Standards/GitHub_IPR_Organization&diff=1186507Standards/GitHub IPR Organization2018-01-09T16:43:25Z<p>Dbaron: bold correctly</p>
<hr />
<div>The [https://github.com/mozilla-standards mozilla-standards GitHub organization] exists for interactions between Mozilla and standards bodies that use GitHub organizations to track organization-wide IPR commitments.<br />
<br />
Many standards organizations require contributors to make intellectual property rights (IPR) commitments regarding copyrights and patents. These generally need to be made by the company the contributor works for. So this organization is designed to contain people who are paid to work for Mozilla, so that standards development organizations that use GitHub organizations can track who Mozilla's IPR commitment applies to.<br />
<br />
For now, ask [https://mozillians.org/u/dbaron/ dbaron] or [https://mozillians.org/u/annevk/ annevk] to be added. This will likely be more automated in the future.<br />
<br />
Standards organizations that currently use this:<br />
* [https://whatwg.org/ WHATWG]<br />
<br />
Please note that you must '''make your membership public''' for this to work. This can be done in the [https://github.com/orgs/mozilla-standards/people UI for the organization].</div>Dbaronhttps://wiki.mozilla.org/index.php?title=Standards/GitHub_IPR_Organization&diff=1186506Standards/GitHub IPR Organization2018-01-09T16:42:48Z<p>Dbaron: membership must be public</p>
<hr />
<div>The [https://github.com/mozilla-standards mozilla-standards GitHub organization] exists for interactions between Mozilla and standards bodies that use GitHub organizations to track organization-wide IPR commitments.<br />
<br />
Many standards organizations require contributors to make intellectual property rights (IPR) commitments regarding copyrights and patents. These generally need to be made by the company the contributor works for. So this organization is designed to contain people who are paid to work for Mozilla, so that standards development organizations that use GitHub organizations can track who Mozilla's IPR commitment applies to.<br />
<br />
For now, ask [https://mozillians.org/u/dbaron/ dbaron] or [https://mozillians.org/u/annevk/ annevk] to be added. This will likely be more automated in the future.<br />
<br />
Standards organizations that currently use this:<br />
* [https://whatwg.org/ WHATWG]<br />
<br />
Please note that you must **make your membership public** for this to work. This can be done in the [https://github.com/orgs/mozilla-standards/people UI for the organization].</div>Dbaronhttps://wiki.mozilla.org/index.php?title=Modules/Core&diff=1186206Modules/Core2018-01-03T21:56:42Z<p>Dbaron: hand off style system module ownership to Cameron McCormack, as described in my 17 December governance post</p>
<hr />
<div><noinclude><br />
'''Only module owners may edit this page.''' <br />
<br />
They may:<br />
<br />
* update any information about their module except the name of the owner<br />
* add or remove sub-modules<br />
* change the owner of a sub-module <br />
* add emeritus owners or peers<br />
<br />
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].<br />
</noinclude><br />
{{Module<br />
|name=Accessibility<br />
|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.<br />
|owner=[mailto:surkov.alexander@gmail.com Alexander Surkov]<br />
|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]<br />
|ownersemeritus=[mailto:aaron@moonset.net. Aaron Leventhal]<br />
|peersemeritus=[mailto:tbsaunde+mozbugs@tbsaunde.org Trevor Saunders], [mailto:ginn.chen@oracle.com Ginn Chen], Evan Yan<br />
|group=dev-accessibility<br />
|source_dirs=accessible/<br />
|url=http://www.mozilla.org/access/<br />
|components=Core::Disability Access APIs<br />
}}<br />
<br />
{{Module<br />
|name=Browser WebAPI<br />
|description=Web API for rendering apps, browser windows and widgets.<br />
|owner=[mailto:kchen@mozilla.com Kan-Ru Chen]<br />
|peers=[mailto:Olli.Pettay@helsinki.fi Olli Pettay], [mailto:fabrice@mozilla.com Fabrice Desré]<br />
|group=dev-webapi<br />
|source_dirs=dom/browser-element/<br />
|url=<br />
|components=Core::DOM<br />
}}<br />
<br />
{{Module<br />
|name=Build and Release Tools<br />
|description=Tools related to build and release automation and configuration of release builds.<br />
|owner=[mailto:nthomas@mozilla.com Nick Thomas]<br />
|peers=[mailto:bhearsum@mozilla.com Ben Hearsum], [mailto:coop@mozilla.com Chris Cooper]<br />
|group=release-engineering<br />
|source_dirs=browser/config/mozconfigs/, mobile/android/config/mozconfigs/, xulrunner/config/mozconfigs/, b2g/config/, tools/update-packaging/<br />
|url=https://wiki.mozilla.org/ReleaseEngineering<br />
|components=Release Engineering::*<br />
}}<br />
<br />
{{Module<br />
|name=Build Config<br />
|description=The build system for Gecko and several mozilla.org hosted Gecko-based applications.<br />
|owner=[mailto:gps@mozilla.com Gregory Szorc] (:gps)<br />
|peers=[mailto:mh@glandium.org Mike Hommey] (:glandium), [mailto:mshal@mozilla.com Mike Shal] (:mshal), [mailto:ted@mielczarek.org Ted Mielczarek] (:ted), [mailto:cmanchester@mozilla.com Chris Manchester](:chmanchester), [mailto:nfroyd@mozilla.com Nathan Froyd] (:froydnj), [mailto:rgiles@mozilla.com Ralph Giles] (:rillian)<br />
|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]), <br />
|group=dev-builds<br />
|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/<br />
|url=http://www.mozilla.org/build/<br />
|components=Core::Build Config<br />
}}<br />
<br />
{{Module<br />
|name=Code Analysis and Debugging Tools<br />
|description=Tools for debugging Mozilla code or for analyzing speed, memory use, and other characteristics of it.<br />
|owner=[mailto:dbaron@dbaron.org David Baron]<br />
|peers=<br />
|group=dev-performance<br />
|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/, <br />
|url=<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=Content HTTP Headers<br />
|description=HTTP headers related to content, e.g. User-Agent, Content-Type, Accept. (Transport-related headers are the responsibility of the Necko module owner.)<br />
|owner=[mailto:gerv@mozilla.org Gervase Markham]<br />
|peers=[mailto:lmandel@mozilla.com Lawrence Mandel]<br />
|group=dev-platform<br />
|source_dirs= <br />
|url=https://developer.mozilla.org/en/Gecko_user_agent_string_reference<br />
|components=Core::Networking: HTTP<br />
}}<br />
<br />
{{Module<br />
|name=Content Security<br />
|description=Native content-based security features, including: Content Security Policy (CSP), Mixed Content Blocker (MCB), Subresource Integrity (SRI) and CORS.<br />
|owner=[mailto:ckerschbaumer@mozilla.com Christoph Kerschbaumer]<br />
|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] <br />
|group=dev-security<br />
|source_dirs=dom/security<br />
|components=Core::DOM: Security<br />
}}<br />
<br />
{{Module<br />
|name=Cookies and Permissions<br />
|description=<br />
|owner=Monica Chew<br />
|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)]<br />
|group=dev-tech-network<br />
|source_dirs=extensions/cookie/, netwerk/cookie/<br />
|url=<br />
|components=Core::Networking: Cookies<br />
}}<br />
{{Module<br />
|name=Cycle Collector<br />
|description=Code to break and collect objects within reference cycles<br />
|owner=[https://mozillians.org/en-US/u/mccr8/ Andrew McCreight]<br />
|peers=Peter Van der Beken, Olli Pettay, David Baron<br />
|source_dirs=xpcom/base/nsCycleCollector.* and some support headers<br />
|components=Core::XPCOM<br />
|group=dev-platform<br />
}}<br />
{{Module<br />
|name=C++/Rust usage, tools, and style<br />
|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<br />
|owner=[mailto:nfroyd@mozilla.com Nathan Froyd] (while Ehsan is away)<br />
|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]<br />
|source_dirs=non-third-party C++ and Rust code in the tree<br />
|components=Various components<br />
|group=dev-platform<br />
}}<br />
{{Module<br />
|name=docshell<br />
|description=<br />
|owner=[mailto:bzbarsky@mit.edu Boris Zbarsky]<br />
|peers=[mailto:Olli.Pettay@helsinki.fi Olli Pettay], [mailto:sawang@mozilla.com Samael Wang]<br />
|peersemeritus=[mailto:jstenback@gmail.com Johnny Stenback],[mailto:cbiesinger@gmail.com Christian Biesinger],[mailto:justin.lebar@gmail.com Justin Lebar]<br />
|group=dev-platform<br />
|source_dirs=docshell/, uriloader/<br />
|url=<br />
|components=Core::Document Navigation<br />
}}<br />
<br />
{{Module<br />
|name=Document Object Model<br />
|description=<br />
|owner=[mailto:peterv@propagandism.org Peter Van der Beken]<br />
|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],<br />
[mailto:ehsan@mozilla.com Ehsan Akhgari], [mailto:bkelly@mozilla.com Ben Kelly], [mailto:wmccloskey@mozilla.com Bill McCloskey], [mailto:kyle@nonpolynomial.com Kyle Machulis]<br />
|ownersemeritus=[mailto:jstenback@gmail.com Johnny Stenback]<br />
|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]<br />
|group=dev-tech-dom<br />
|source_dirs=dom/*, except directories covered by other modules<br />
|url=http://developer.mozilla.org/en/docs/DOM<br />
|components=Core::DOM, Core::DOM: CSS Object Model, Core::DOM: Core & HTML<br />
}}<br />
<br />
{{Module<br />
|name=DOM File<br />
|description=DOM Blob, File and FileSystem APIs <br />
|owner=[mailto:amarchesini@Mozilla.com Andrea Marchesini]<br />
|peers=[mailto:olli@pettay.fi Olli Pettay]<br />
|group=dev-platform<br />
|source_dirs=dom/file, dom/filesystem<br />
|url=http://developer.mozilla.org/en/docs/DOM<br />
|components=Core::DOM: File<br />
}}<br />
<br />
{{Module<br />
|name=Event Handling<br />
|description=DOM Events and Event Handling <br />
|owner=[mailto:olli@pettay.fi Olli Pettay], [mailto:masayuki@d-toybox.com Masayuki Nakano]<br />
|peers=[mailto:sshih@mozilla.com Stone Shih]<br />
|group=dev-platform<br />
|source_dirs=dom/events and event handling related code elsewhere <br />
|url=http://developer.mozilla.org/en/docs/DOM<br />
|components=Core::DOM: Events, Core::Event Handling<br />
}}<br />
<br />
{{Module<br />
|name=Web Workers<br />
|description=<br />
|owner=[mailto:baku@mozilla.com Andrea Marchesini]<br />
|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]<br />
|ownersemeritus=[mailto:bent.mozilla@gmail.com Ben Turner]<br />
|group=dev-platform<br />
|source_dirs=dom/workers/<br />
|url=https://developer.mozilla.org/En/Using_web_workers<br />
|components=Core::DOM: Workers<br />
}}<br />
<br />
{{Module<br />
|name=IndexedDB<br />
|description=<br />
|owner=[mailto:jvarga@mozilla.com Jan Varga]<br />
|peers=[mailto:btseng@mozilla.com Bevis Tseng], [mailto:bugmail@asutherland.org Andrew Sutherland], [mailto:baku@mozilla.com Andrea Marchesini]<br />
|ownersemeritus=[mailto:bent.mozilla@gmail.com Ben Turner]<br />
|peersemeritus=[mailto:jonas@sicking.cc Jonas Sicking], [mailto:me@kylehuey.com Kyle Huey]<br />
|group=dev-platform<br />
|source_dirs=dom/indexedDB/<br />
|url=https://developer.mozilla.org/en/IndexedDB<br />
|components=Core::DOM: IndexedDB<br />
}}<br />
<br />
{{Module<br />
|name=Editor<br />
|description=<br />
|owner=[mailto:masayuki@d-toybox.com Masayuki Nakano]<br />
|peers=<br />
|ownersemeritus=[mailto:ehsan@mozilla.com Ehsan Akhgari]<br />
|group=dev-platform<br />
|source_dirs=editor/<br />
|url=http://www.mozilla.org/editor/<br />
|components=Core::Editor<br />
}}<br />
<br />
{{Module<br />
|name=Embedding<br />
|description=Gecko embedding APIs and frameworks<br />
|owner=[mailto:myk@mykzilla.org Myk Melez]<br />
|ownersemeritus=[mailto:benjamin@smedbergs.us Benjamin Smedberg], [mailto:doug.turner@gmail.com Doug Turner]<br />
|peers=[mailto:bdahl@mozilla.com Brendan Dahl], [mailto:tbsaunde@tbsaunde.org Trevor Saunders]<br />
|peersemeritus=[mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:jstenback@gmail.com Johnny Stenback]<br />
|group=dev-platform<br />
|source_dirs=embedding/<br />
|url=<br />
|components=Core::Embedding: APIs<br />
}}<br />
<br />
{{Module<br />
|name=Find As You Type<br />
|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.<br />
|owner=<br />
|peers=<br />
|group=dev-accessibility<br />
|source_dirs=extensions/typeaheadfind/<br />
|url=http://www.mozilla.org/access/type-ahead/<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=Gecko Profiler<br />
|description=Gecko's built-in profiler<br />
|owner=[mailto:mstange@themasta.com Markus Stange]<br />
|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].<br />
|group=dev-platform<br />
|source_dirs=tools/profiler/<br />
|url=https://developer.mozilla.org/en-US/docs/Mozilla/Performance/Profiling_with_the_Built-in_Profiler<br />
|components=Core::Gecko Profiler<br />
}}<br />
<br />
{{Module<br />
|name=Geolocation<br />
|description=Implementation of the Geolocation W3C Spec, location provider apis, and wifi scanning code.<br />
|owner=[mailto:josh@joshmatthews.net Josh Matthews], [mailto:kchen@mozilla.com Kan-Ru Chen]<br />
|ownersemeritus=[mailto:doug.turner@gmail.com Doug Turner], Garvan Keeley<br />
|peers=<br />
|group=dev-tech-dom<br />
|source_dirs=dom/geolocation, dom/system/, netwerk/wifi<br />
|url=https://developer.mozilla.org/En/Using_geolocation<br />
|components=Core::Geolocation<br />
}}<br />
<br />
{{Module<br />
|name=Global Key Bindings<br />
|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.<br />
|owner=Aaron Leventhal<br />
|peers=[mailto:neil@parkwaycc.co.uk Neil Rashbrook]<br />
|group=dev-accessibility<br />
|source_dirs=dom/xbl/builtin/<br />
|url=http://www.mozilla.org/projects/ui/accessibility/mozkeyintro.html<br />
|components=Core::Keyboard: Navigation<br />
}}<br />
<br />
{{Module<br />
|name=Graphics<br />
|description=Mozilla graphics API<br />
|owner=[mailto:jrmuizel@mozilla.com Jeff Muizelaar](Thebes, QCMS, YCbCr, Cairo/Pixman, Regions, OS X, Other)<br />
|ownersemeritus=[mailto:robert@ocallahan.org Robert O'Callahan]<br />
|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]<br />
|group=dev-platform<br />
|source_dirs=gfx/, dom/canvas/<br />
|url=https://wiki.mozilla.org/Platform/GFX https://wiki.mozilla.org/Gecko:Layers https://wiki.mozilla.org/Gecko:2DGraphicsSketch<br />
|components=Core::Graphics, Core::Graphics: Layers, Core::Graphics: Text, Core::GFX: Color Management, Core::Canvas: 2D, Core::Canvas: WebGL<br />
}}<br />
<br />
{{Module<br />
|name=APZ (Graphics submodule)<br />
|description=Asynchronous panning and zooming<br />
|owner=[mailto:kgupta@mozilla.com Kartikaya Gupta]<br />
|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]<br />
|group=dev-platform<br />
|source=gfx/layers/apz<br />
|url=https://wiki.mozilla.org/Platform/GFX/APZ<br />
|components=Core::Panning and Zooming<br />
}}<br />
<br />
{{Module<br />
|name=Moz2D (Graphics submodule)<br />
|description=Platform independent 2D graphics API<br />
|owner=[mailto:bschouten@mozilla.com Bas Schouten]<br />
|peers=[mailto:jmuizelaar@mozilla.com Jeff Muizelaar], [mailto:gwright@mozilla.com George Wright], [mailto:jwatt@jwatt.org Jonathan Watt]<br />
|group=dev-platform<br />
|source=gfx/2d<br />
|url=https://wiki.mozilla.org/Platform/GFX/Moz2D<br />
|components=Core::Graphics<br />
}}<br />
<br />
{{Module<br />
|name=Legacy HTML Parser<br />
|description=<br />
|owner=[mailto:mrbkap@gmail.com Blake Kaplan]<br />
|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]<br />
|peersemeritus=[mailto:jstenback@gmail.com Johnny Stenback]<br />
|source_dirs=parser/htmlparser<br />
|url=http://www.mozilla.org/newlayout/doc/parser.html<br />
|components=Core::HTML: Parser<br />
}}<br />
<br />
{{Module<br />
|name=HAL<br />
|description=Hardware Abstraction Layer<br />
|owner=[https://mozillians.org/u/dhylands/ Dave Hylands]<br />
|peers=[mailto:gsvelto@mozilla.com Gabriele Svelto]<br />
|group=dev-platform<br />
|source_dirs=hal/<br />
|components=Core::Hardware Abstraction Layer (HAL)<br />
}}<br />
<br />
{{Module<br />
|name=HTML Parser<br />
|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++.<br />
|owner=[mailto:hsivonen@iki.fi Henri Sivonen]<br />
|peers=[mailto:wchen@mozilla.com William Chen]<br />
|group=dev-platform<br />
|source_dirs=parser/html<br />
|url=http://about.validator.nu/<br />
|components=Core::HTML: Parser<br />
}}<br />
<br />
{{Module<br />
|name=I18N Library<br />
|description=<br />
|owner=[mailto:jshin1987@gmail.com Jungshik Shin], [mailto:smontagu@smontagu.org Simon Montagu]<br />
|peers=[mailto:VYV03354@nifty.ne.jp Masatoshi Kimura]<br />
|group=dev-i18n<br />
|source_dirs=intl/<br />
|url=http://mozilla.org/projects/intl/index.html<br />
|components=Core::Internationalization<br />
}}<br />
<br />
{{Module<br />
|name=ImageLib<br />
|description=<br />
|owner=[mailto:tnikkel@gmail.com Timothy Nikkel]<br />
|peers=[mailto:aosmond@mozilla.com Andrew Osmond], [mailto:jmuizelaar@mozilla.com Jeff Muizelaar], [mailto:seth.bugzilla@blackhail.net Seth Fowler]<br />
|peersemeritus=[mailto:netzen@gmail.com Brian Bondy], [mailto:justin.lebar@gmail.com Justin Lebar]<br />
|group=dev-platform<br />
|source_dirs=media/libjpeg/, media/libpng/, image/, modules/zlib/<br />
|url=<br />
|components=Core::ImageLib<br />
}}<br />
<br />
{{Module<br />
|name=IPC<br />
|description=Message-passing between threads and processes<br />
|owner=[mailto:jmathies@mozilla.com Jim Mathies]<br />
|peers=[mailto:danderson@mozilla.com David Anderson], [mailto:kchen@mozilla.com Kan-Ru Chen], [mailto:jld@mozilla.com Jed Davis], [mailto:nfroyd@mozilla.com Nathan Froyd], [mailto:bkelly@mozilla.com Ben Kelly], [mailto:wmccloskey@mozilla.com Bill McCloskey], [mailto:amccreight@mozilla.com Andrew McCreight], [mailto:btseng@mozilla.com Bevis Tseng]<br />
|group=dev-platform<br />
|source_dirs=ipc/glue/, ipc/ipdl/, ipc/chromium/<br />
|url=<br />
|components=Core::IPC}}<br />
<br />
{{Module<br />
|name=JavaScript<br />
|description=JavaScript engine (SpiderMonkey)<br />
|owner=[mailto:jorendorff@mozilla.com Jason Orendorff]<br />
|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<br />
|group=dev-tech-js-engine<br />
|source_dirs=js/src<br />
|url=http://www.mozilla.org/js/spidermonkey,<br />
http://developer.mozilla.org/en/docs/About_JavaScript<br />
|components=Core::JavaScript Engine<br />
}}<br />
<br />
{{Module<br />
|name=JavaScript JIT<br />
|description=JavaScript engine's JIT compilers (IonMonkey, Baseline)<br />
|owner=[mailto:jdemooij@mozilla.com Jan de Mooij]<br />
|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]<br />
|group=dev-tech-js-engine-internals<br />
|source_dirs=js/src/jit<br />
|url=http://www.mozilla.org/js/spidermonkey<br />
|components=Core::JavaScript Engine: JIT<br />
}}<br />
<br />
{{Module<br />
|name=JavaScript Debugger Backend<br />
|description=JavaScript debugging hooks<br />
|owner=[mailto:timeless@mozdev.org Josh 'timeless' Soref]<br />
|peers=[mailto:brendan@mozilla.org Brendan Eich], [mailto:rginda@hacksrus.com Rob Ginda]<br />
|group=dev-apps-js-debugger<br />
|source_dirs=js/jsd/<br />
|url=http://www.mozilla.org/js/jsd<br />
|components=Other Applications::Venkman JS Debugger<br />
}}<br />
<br />
{{Module<br />
|name=jsat<br />
|description=Javascript screen reader that is used in Android and B2G<br />
|owner=[mailto:eitan@monotonous.org Eitan Isaacson]<br />
|peers=[mailto:yzenevich@mozilla.com Yura Zenevich]<br />
|group=dev-accessibility<br />
|source_dirs=accessible/jsat/<br />
|url=http://www.mozilla.org/access/<br />
|components=Core::Disability Access APIs<br />
}}<br />
<br />
{{Module<br />
|name=js-ctypes<br />
|description=A foreign function interface which allows privileged JS code to interact with binary code without using XPCOM/XPConnect.<br />
|owner=[mailto:jorendorff@mozilla.com Jason Orendorff]<br />
|peers=[mailto:bobbyholley@gmail.com Bobby Holley]<br />
|group=dev-tech-js-engine<br />
|source_dirs=js/src/ctypes/<br />
|url=https://wiki.mozilla.org/JSctypes<br />
|components=Core::js-ctypes<br />
}}<br />
<br />
{{Module<br />
|name=js-tests<br />
|description=JavaScript test suite<br />
|owner=[mailto:bclary@bclary.com Bob Clary]<br />
|peers=<br />
|group=dev-tech-js-engine<br />
|source_dirs=js/tests/<br />
|url=http://www.mozilla.org/js/tests/library.html<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=Layout Engine<br />
|description=rendering tree construction, layout (reflow), etc.<br />
|owner=[mailto:dbaron@dbaron.org David Baron]<br />
|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]<br />
|group=dev-tech-layout<br />
|source_dirs=layout/%, layout/base/, layout/build/, layout/doc/, layout/forms/, layout/generic/, layout/html/, layout/printing/, layout/tables/, layout/tools/<br />
|url=http://mozilla.org/newlayout/doc/ ,<br />
http://lxr.mozilla.org/mozilla/source/layout/doc/<br />
|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<br />
}}<br />
<br />
{{Module<br />
|name=libjar<br />
|description=The JAR handling code (protocol handler, stream implementation, and zipreader/zipwriter).<br />
|owner=[mailto:mwu@mozilla.com Michael Wu]<br />
|peers=[mailto:aklotz@mozilla.com Aaron Klotz]<br />
|group=dev-platform<br />
|source_dirs=modules/libjar<br />
|url=<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=MathML<br />
|description=MathML is a low-level specification for describing mathematics which provides a foundation for the inclusion of mathematical expressions in Web pages.<br />
|owner=[mailto:karlt+@karlt.net Karl Tomlinson]<br />
|peers=[mailto:robert@ocallahan.org Robert O'Callahan]<br />
|group=dev-tech-mathml<br />
|source_dirs=layout/mathml/<br />
|url=http://www.mozilla.org/projects/mathml/<br />
|components=Core::MathML<br />
}}<br />
<br />
{{Module<br />
|name=Media Playback<br />
|description=HTML Media APIs, including Media Source Extensions and non-MSE video/audio element playback, and Encrypted Media Extensions. (WebRTC and WebAudio not included).<br />
|owner=[mailto:cpearce@mozilla.com Chris Pearce]<br />
|ownersemeritus=[mailto:robert@ocallahan.org Robert O'Callahan]<br />
|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]<br />
|group=dev-media<br />
|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/<br />
|url=<br />
|components=Core::Audio/Video<br />
}}<br />
<br />
{{Module<br />
|name=Media Transport<br />
|description=Pluggable transport for real-time media<br />
|owner=[mailto:ekr@rtfm.com Eric Rescorla]<br />
|peers=[mailto:bcampen@mozilla.com Byron Campen], [mailto:abr@mozilla.com Adam Roach], [mailto:nohlmeier@mozilla.com Nils Ohlmeier]<br />
|group=dev-media<br />
|source_dirs=media/mtransport<br />
|url=<br />
|components=Core::WebRTC::Networking<br />
}}<br />
<br />
{{Module<br />
|name=Memory Allocator<br />
|description=Most things related to memory allocation in Gecko, including jemalloc, replace-malloc, DMD (dark matter detector), logalloc, etc.<br />
|owner=[mailto:mh+mozilla@glandium.org Mike Hommey]<br />
|peers=[mailto:n.nethercote@gmail.com Nicholas Nethercote], [mailto:erahm@mozilla.com Eric Rahm]<br />
|group=dev-platform<br />
|source_dirs=memory/<br />
|components=Core::DMD, Core::jemalloc<br />
}}<br />
<br />
{{Module<br />
|name=mfbt<br />
|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).<br />
|owner=[mailto:jwalden@mit.edu Jeff Walden]<br />
|peers=[mailto:froydnj@mozilla.com Nathan Froyd], [mailto:Ms2ger@gmail.com Ms2ger], [mailto:mh+mozilla@glandium.org Mike Hommey]<br />
|group=dev-platform<br />
|source_dirs=mfbt/<br />
|url=<br />
|components=Core::MFBT<br />
}}<br />
<br />
{{Module<br />
|name=mozApps API & UI<br />
|description=Implementation of the navigator.mozApps API<br />
|owner=[mailto:fabrice@mozilla.com Fabrice Desré], [mailto:ehsan@mozilla.com Ehsan Akhgari]<br />
|peers=[mailto:myk@mozilla.org Myk Melez], [mailto:mar.castelluccio@studenti.unina.it Marco Castelluccio], [mailto:ferjmoreno@gmail.com Fernando Jiménez]<br />
|group=dev-webapi<br />
|source_dirs=dom/apps/, dom/interfaces/apps, product specific files implementing UI hooks.<br />
|url=<br />
|components=Core::DOM: Apps<br />
}}<br />
<br />
{{Module<br />
|name=Mozglue<br />
|description=Glue library containing various low-level functionality, including a dynamic linker for Android, a DLL block list for Windows, etc.<br />
|owner=[mailto:mh+mozilla@glandium.org Mike Hommey]<br />
|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)<br />
|group=dev-platform<br />
|source_dirs=mozglue/<br />
|components=Core::mozglue<br />
}}<br />
<br />
{{Module<br />
|name=mozilla-toplevel<br />
|description=The top level directory for the mozilla tree.<br />
|owner=[mailto:brendan@mozilla.org Brendan Eich]<br />
|peers=<br />
|group=<br />
|source_dirs=tools/README<br />
|url=<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=MSCOM<br />
|description=Integration with Microsoft Distributed COM<br />
|owner=[mailto:aklotz@mozilla.com Aaron Klotz]<br />
|peers=[mailto:jmathies@mozilla.com Jim Mathies]<br />
|group=dev-platform<br />
|source_dirs=ipc/mscom/%<br />
|url=<br />
|components=Core::IPC: MSCOM}}<br />
<br />
{{Module<br />
|name=Necko<br />
|description=The Mozilla Networking Library<br />
|owner=[mailto:mcmanus@ducksong.com Patrick McManus]<br />
|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 ], [mailto:schien@mozilla.com ShihChiang Chien]<br />
|peersemeritus= [mailto:cbiesinger@gmail.com Christian Biesinger], [mailto:sworkman@mozilla.com Steve Workman], [mailto:bzbarsky@mit.edu Boris Zbarsky]<br />
|group=dev-tech-network<br />
|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/<br />
|url=http://www.mozilla.org/projects/netlib/, https://developer.mozilla.org/en/Necko<br />
|components=Core::Networking, Core::Networking: Cache, Core::Networking: Cookies, Core::Networking: FTP, Core::Networking: File, Core::Networking: HTTP, Core::Networking: JAR, Core::Networking: Websockets<br />
}}<br />
<br />
{{Module<br />
|name=NSPR<br />
|description=Netscape Portable Runtime<br />
|owner=[mailto:kaie@kuix.de Kai Engert]<br />
|peers=[mailto:wtc@google.com Wan-Teh Chang], [mailto:mh@glandium.org Mike Hommey]<br />
|group=dev-tech-nspr<br />
|source_dirs=nsprpub/<br />
|url=http://www.mozilla.org/projects/nspr/<br />
http://www.mozilla.org/projects/nspr/reference/html/<br />
http://www.mozilla.org/projects/nspr/release-notes/<br />
|components=NSPR<br />
}}<br />
<br />
{{Module<br />
|name=PDF<br />
|description=Rendering code to display documents encoded in the ISO 32000-1 `PDF' format.<br />
|owner=Chris Jones, Andreas Gal<br />
|peers=[mailto:aadib@mozilla.com Artur Adib], [mailto:bdahl@mozilla.com Brendan Dahl], [mailto:vnicolas@mozilla.com Vivien Nicolas]<br />
|group=dev-platform<br />
|source_dirs=media/pdf/<br />
|url=https://github.com/mozilla/pdf.js<br />
|components=Core::PDF<br />
}}<br />
<br />
{{Module<br />
|name=Plugins<br />
|description= NPAPI Plugin support.<br />
|owner=[mailto:jmathies@mozilla.com Jim Mathies]<br />
|peers=[mailto:joshmoz@gmail.com Josh Aas]<br />
|peersemeritus=[mailto:john@pointysoftware.net John Schoenick], [mailto:robert@ocallahan.org Robert O'Callahan], [mailto:jstenback@gmail.com Johnny Stenback], Benjamin Smedberg<br />
|group=<br />
|source_dirs=dom/plugins/, modules/plugin/<br />
|url=https://wiki.mozilla.org/Plugins<br />
|components=Core::Plug-ins<br />
}}<br />
<br />
{{Module<br />
|name=Preferences<br />
|description=Preference library<br />
|owner=[mailto:nnethercote@mozilla.com Nicholas Nethercote]<br />
|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]<br />
|group=dev-platform<br />
|source_dirs=modules/libpref/<br />
|url=<br />
|components=Core::Preferences: Backend<br />
}}<br />
<br />
{{Module<br />
|name=Private Browsing<br />
|description=Implementation of the Private Browsing mode, and the integration of other modules with Private Browsing APIs.<br />
|owner=[mailto:josh@joshmatthews.net Josh Matthews] (while Ehsan is away)<br />
|peers=[mailto:ehsan@mozilla.com Ehsan Akhgari]<br />
|group=dev-platform<br />
|source_dirs=Implementation and consumers of Private Browsing APIs in nsILoadContext, nsIPrivateBrowsingChannel, PrivateBrowsingUtils.jsm and the related glue code. <br />
|url=https://wiki.mozilla.org/Private_Browsing<br />
|components=Firefox::Private Browsing<br />
}}<br />
<br />
{{Module<br />
|name=Privilege Manager<br />
|description="caps"<br />
|owner=[mailto:bobbyholley@gmail.com Bobby Holley]<br />
|peers=[mailto:bzbarsky@mit.edu Boris Zbarsky]<br />
|peersemeritus=[mailto:brendan@mozilla.org Brendan Eich], [mailto:jstenback@gmail.com Johnny Stenback], [mailto:dveditz@mozilla.com Dan Veditz]<br />
|group=dev-tech-dom<br />
|source_dirs=caps/<br />
|url=http://www.mozilla.org/projects/security/components/index.html<br />
|components=Core::Security: CAPS<br />
}}<br />
<br />
{{Module<br />
|name=Push Notifications<br />
|description=Push is a way for application developers to send messages to their web applications.<br />
|owners=<br />
|ownersemeritus=[mailto:doug.turner@gmail.com Doug Turner]<br />
|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]<br />
|group=<br />
|source_dirs=dom/push, dom/simplepush<br />
|url=<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=PyXPCOM<br />
|description=The Python to XPCOM bridge.<br />
|owner=Todd Whiteman<br />
|peers=[mailto:mhammond@skippinet.com.au Mark Hammond]<br />
|group=<br />
|source_dirs=extension/python<br />
|url=https://developer.mozilla.org/en/PyXPCOM<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=RDF<br />
|description=<br />
|owner=[mailto:axel@pike.org Axel Hecht]<br />
|peers=<br />
|group=dev-tech-rdf<br />
|source_dirs=rdf/<br />
|url=http://www.mozilla.org/rdf/doc/<br />
|components=Core::RDF<br />
}}<br />
<br />
{{Module<br />
|name=security<br />
|description=Crypto/PKI code, including NSS (Network Security Services) and JSS (NSS for Java)<br />
|owner=[mailto:rrelyea@redhat.com Bob Relyea], [mailto:ttaubert@mozilla.com Tim Taubert]<br />
|peers=[mailto:emaldona@redhat.com Elio Maldonado], [mailto:kaie@kuix.de Kai Engert], [mailto:ryan.sleevi@gmail.com Ryan Sleevi], [mailto:ekr@rtfm.com Eric Rescorla], [mailto:franziskuskiefer@gmail.com Franziskus Kiefer], [mailto:martin.thomson@gmail.com Martin Thomson], [mailto:wtc@google.com Wan-Teh Chang]<br />
|group=dev-tech-crypto<br />
|source_dirs=dbm/, security/coreconf/, security/dbm/, security/jss/, security/nss/, security/tinderbox/, security/tinderlight/<br />
|url=http://mozilla.org/projects/security/pki/<br />
|components=NSS, JSS, Core::Security, Core::Security: S/MIME<br />
}}<br />
<br />
{{Module<br />
|name=Security - Mozilla PSM Glue<br />
|description=Personal Security Manager<br />
|owner=[mailto:dkeeler@mozilla.com David Keeler]<br />
|peers=[mailto:honzab.moz@firemni.cz Honza Bambas], [mailto:cykesiopka.bmo@gmail.com Cykesiopka]<br />
|group=dev-tech-crypto<br />
|source_dirs=security/manager/<br />
|url=<br />
|components=Core::Security: PSM, Core::Security: UI<br />
}}<br />
<br />
{{Module<br />
|name=Static analysis & rewriting for C++<br />
|description=Tools for checking C++ code looking for problems at compile time, plus tools for automated rewriting of C++ code.<br />
|owner=[mailto:nika@thelayzells.com Nika Layzell] (while Ehsan is away)<br />
|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]<br />
|group=dev-platform<br />
|source_dirs=build/clang-plugin, tools/rewriting among other out of tree tools<br />
|url=<br />
|components=Core::Rewriting & Analysis<br />
}}<br />
{{Module<br />
|name=storage<br />
|description=Storage APIs with a SQLite backend<br />
|owner=[mailto:mak77@bonardo.net Marco Bonardo]<br />
|peers=[mailto:bugmail@asutherland.org Andrew Sutherland], [mailto:jvarga@mozilla.com Jan Varga]<br />
|group=dev-platform<br />
|source_dirs=db/sqlite3/, storage/<br />
|url=http://developer.mozilla.org/en/docs/Storage<br />
|components=Toolkit::Storage, Core::SQL<br />
}}<br />
<br />
{{Module<br />
|name=String<br />
|description=<br />
|owner=[mailto:dbaron@dbaron.org David Baron]<br />
|peers=[https://mozillians.org/en-US/u/froydnj/ Nathan Froyd], [mailto:erahm@mozilla.com Eric Rahm]<br />
|group=dev-tech-xpcom<br />
|source_dirs=string/, xpcom/string/<br />
|url=https://developer.mozilla.org/En/Mozilla_internal_string_guide<br />
|components=Core::String<br />
}}<br />
<br />
{{Module<br />
|name=Style System<br />
|description=CSS style sheet handling; style data computation<br />
|owner= [mailto:cam@mcc.id.au Cameron McCormack]<br />
|peers=[mailto:dbaron@dbaron.org David Baron], [mailto:bzbarsky@mit.edu Boris Zbarsky]<br />
|group=dev-tech-layout<br />
|source_dirs=layout/style/<br />
|url=https://wiki.mozilla.org/Gecko:Overview#Style_System<br />
|components=Core::CSS Parsing and Computation<br />
}}<br />
<br />
{{Module<br />
|name=SVG<br />
|description=Scalable Vector Graphics<br />
|owner=[mailto:jwatt@jwatt.org Jonathan Watt]<br />
|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]<br />
|group=dev-tech-svg<br />
|source_dirs=dom/svg/, layout/svg/, dom/smil/<br />
|url=https://developer.mozilla.org/en-US/docs/Web/SVG<br />
|components=Core::SVG<br />
}}<br />
<br />
{{Module<br />
|name=Tamarin<br />
|description=VM for ActionScript and JavaScript<br />
|owner=Edwin Smith, [mailto:jodyer@adobe.com Jeff Dyer]<br />
|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]<br />
|group=dev-tech-js-engine<br />
|source_dirs=js/tamarin<br />
|url=http://www.mozilla.org/projects/tamarin/<br />
http://wiki.mozilla.org/tamarin/<br />
http://hg.mozilla.org/tamarin-central/<br />
http://hg.mozilla.org/tamarin-tracing/<br />
|components=Tamarin<br />
}}<br />
<br />
{{Module<br />
|name=Test Harness<br />
|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.<br />
|owner=[mailto:ted@mielczarek.org Ted Mielczarek]<br />
|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), <br />
<br />
|group=dev-quality<br />
|source_dirs=/testing<br />
|url=http://wiki.mozilla.org/SoftwareTesting<br />
|components=Testing::General, Testing::Mochitest, Testing::Mochitest Chrome, Testing::Marionette, Testing::Mozmill, Testing::Reftest, Testing::XPCShell Harness, Testing::httpd.js<br />
}}<br />
<br />
{{Module<br />
|name=Testing Infrastructure<br />
|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<br />
|owner=[mailto:jmaher@mozilla.com Joel Maher]<br />
|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é]<br />
|group=dev-quality<br />
|source_dirs=testing/, tools/httptester/, tools/page-loader/, tools/test-harness/, tools/tests/, tools/testserver/, tools/testy/<br />
|url=http://wiki.mozilla.org/SoftwareTesting<br />
|components=Testing::Infrastructure<br />
}}<br />
<br />
{{Module<br />
|name=JS Marionette<br />
|description=NodeJS test harness, marionette client, and other utilities for running marionette tests (submodule of Test Infrastructure)<br />
|owner=[mailto:jlal@mozilla.com James Lal] <lightsofapollo>, [mailto:gaye@mozilla.com Gareth Aye] <gaye><br />
|peers=[mailto:aus@mozilla.com Ghislain "Aus" Lacroix] <auswerk><br />
|source_dirs=gaia/tests/jsmarionette<br />
|components=Testing::JSMarionette<br />
|group=dev-gaia<br />
}}<br />
<br />
{{Module<br />
|name=XPCShell Test Harness<br />
|description=The XPCShell Harness<br />
|owner=[mailto:ted@mielczarek.org Ted Mielczarek]<br />
|peers=[mailto:jmaher@mozilla.com Joel Maher]<br />
|source_dirs=testing/xpcshell<br />
|components=Testing::XPCShell Harness<br />
}}<br />
<br />
{{Module<br />
|name=Update Service<br />
|description=server code for Mozilla Update services (aus, addons, pfs)<br />
|owner=Mike Morgan<br />
|peers=[mailto:jscott@mozilla.com Justin Scott], [mailto:shaver@mozilla.org Mike Shaver], [mailto:wclouser@mozilla.com Will Clouser]<br />
|group=dev-amo<br />
|source_dirs=webtools/addons/, webtools/aus/, webtools/update/<br />
|url=http://wiki.mozilla.org/wiki/AMO<br />
|components=AUS::Administration, AUS::Systems<br />
}}<br />
<br />
{{Module<br />
|name=View System<br />
|description=The View Manager is responsible for handling "heavyweight" rendering (some clipping, compositing) and event handling tasks.<br />
|owner=[mailto:mstange@themasta.com Markus Stange]<br />
|ownersemeritus=[mailto:robert@ocallahan.org Robert O'Callahan]<br />
|peers=[mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:dbaron@dbaron.org David Baron]<br />
|group=dev-tech-layout<br />
|source_dirs=view/<br />
|url=<br />
|components=Core::Layout: View Rendering<br />
}}<br />
<br />
{{Module<br />
|name=Web Audio<br />
|description=Support for the W3C Web Audio API specification.<br />
|owner=[mailto:padenot@mozilla.com Paul Adenot]<br />
|ownersemeritus=[mailto:ehsan@mozilla.com Ehsan Akhgari]<br />
|peers=[mailto:robert@ocallahan.org Robert O'Callahan], [mailto:karlt+@karlt.net Karl Tomlinson]<br />
|group=dev-platform<br />
|source_dirs=dom/media/webaudio<br />
|url=https://wiki.mozilla.org/Web_Audio_API<br />
|components=Core::Web Audio<br />
}}<br />
<br />
{{Module<br />
|name=Web Painting<br />
|description=painting, display lists, and layer construction<br />
|owner=[mailto:matt.woodrow@gmail.com Matt Woodrow]<br />
|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]<br />
|group=dev-tech-layout<br />
|source_dirs= layout/painting, the display list and layer related methods on nsIFrame and its subclasses<br />
|url=http://mozilla.org/newlayout/doc/ ,<br />
http://lxr.mozilla.org/mozilla/source/layout/doc/<br />
|components=Core::Layout: Web Painting<br />
}}<br />
<br />
{{Module<br />
|name=WebRTC<br />
|description=WebRTC is responsible for realtime audio and video communication, as well as related issues like low-level camera and microphone access<br />
|owner=[mailto:rjesup@mozilla.com Randell Jesup]<br />
|peers=[mailto:ekr@mozilla.com Eric Rescorla], [mailto:bcampen@mozilla.com Byron Campen] [mailto:abr@mozilla.com Adam Roach]<br />
|peersemeritus=[mailto:ehugg@cisco.com Ethan Hugg]<br />
|group=dev-media<br />
|source_dirs=netwerk/sctp (also see submodules "WebRTC Media" and "WebRTC Signaling")<br />
|url=https://wiki.mozilla.org/Media/webrtc<br />
|components=Core::WebRTC, Core::WebRTC Networking<br />
}}<br />
<br />
{{Module<br />
|name=WebVR<br />
|description=Gecko's implementation of WebVR (Virtual Reality) functionality, including API, devices, graphics and integration<br />
|owner=[mailto:kgilbert@mozilla.com Kip Gilbert]<br />
|peers=[mailto:dmu@mozilla.com Daosheng Mu]<br />
|peersemeritus=[mailto:vladimir@pobox.com Vladimir Vukicevic]<br />
|group=dev-platform<br />
|source_dirs=dom/vr, gfx/vr<br />
|url=https://mozvr.com/<br />
|components=Core::WebVR<br />
}}<br />
<br />
{{Module<br />
|name=Widget<br />
|description=<br />
|owner=[mailto:vladimir@pobox.com Vladimir Vukicevic]<br />
|ownersemeritus=[mailto:robert@ocallahan.org Robert O'Callahan]<br />
|peersemeritus=[mailto:pavlov@pavlov.net Stuart Parmenter], <br />
|group=dev-platform<br />
|source_dirs=widget/, widget/xpwidgets/<br />
|url=<br />
|components=Core::Drag and Drop, Core::Widget, Core::Printing: Setup<br />
}}<br />
<br />
{{Module<br />
|name=Widget - Android<br />
|description=The Android Port<br />
|owner=[mailto:blassey.bugs@lassey.us Brad Lassey]<br />
|peers=[mailto:jwillcox@mozilla.com James Willcox]<br />
|group=dev-platforms-mobile<br />
|source_dirs=widget/android/, embedding/android<br />
|url=<br />
|components=Core::Widget: Android<br />
}}<br />
<br />
{{Module<br />
|name=Widget - GTK<br />
|description=supported X widgetry and gfx<br />
|owner=[mailto:karlt+@karlt.net Karl Tomlinson]<br />
|ownersemeritus=[mailto:robert@ocallahan.org Robert O'Callahan]<br />
|group=dev-platform<br />
|source_dirs=widget/gtk/, widget/gtk2/, widget/gtksuperwin/, widget/gtkxtbin/<br />
|url=http://www.mozilla.org/unix/, http://www.gtk.org, http://www.mozilla.org/ports/gtk/<br />
|components=Core::Widget: Gtk<br />
}}<br />
<br />
{{Module<br />
|name=Widget - OS X<br />
|description= Gecko's OS X compatibility layer.<br />
|owner=[mailto:mstange@themasta.com Markus Stange]<br />
|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]<br />
|group=dev-platform<br />
|source_dirs=widget/cocoa/<br />
|url=<br />
|components=Core::Widget: Cocoa<br />
}}<br />
<br />
{{Module<br />
|name=Widget - Windows<br />
|description=Windows widgets and desktop integration<br />
|owner=[mailto:jmathies@mozilla.com Jim Mathies]<br />
|peers=[mailto:neil@parkwaycc.co.uk Neil Rashbrook], [mailto:vladimir@pobox.com Vladimir Vukicevic], [mailto:jmathies@mozilla.com Jim Mathies]<br />
|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]<br />
|group=dev-platform<br />
|source_dirs=widget/windows/<br />
|url=<br />
|components=Core::Widget: Win32<br />
}}<br />
<br />
{{Module<br />
|name=XBL<br />
|description=eXtensible Binding Language<br />
|owner=[mailto:bzbarsky@mit.edu Boris Zbarsky]<br />
|peers=[mailto:mrbkap@gmail.com Blake Kaplan], [mailto:bobbyholley@gmail.com Bobby Holley], [mailto:jonas@sicking.cc Jonas Sicking]<br />
|ownersemeritus=[mailto:jonas@sicking.cc Jonas Sicking]<br />
|group=dev-tech-xbl<br />
|source_dirs=dom/xbl/<br />
|url=http://www.mozilla.org/projects/xbl/<br />
|components=Core::XBL<br />
}}<br />
<br />
{{Module<br />
|name=XML<br />
|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.<br />
|owner=[mailto:peterv@propagandism.org Peter Van der Beken]<br />
|peers=[mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:erahm@mozilla.com Eric Rahm]<br />
|peersemeritus=[mailto:jonas@sicking.cc Jonas Sicking], [mailto:jstenback@gmail.com Johnny Stenback]<br />
|group=dev-tech-xml<br />
|source_dirs=dom/xml/, extensions/xmlextras/, parser/expat/<br />
|url=http://www.mozilla.org/newlayout/xml/<br />
|components=Core::XML<br />
}}<br />
<br />
{{Module<br />
|name=XPApps<br />
|description=Cross-Platform Applications, mostly Navigator front end and application shell.<br />
|owner=[mailto:neil@parkwaycc.co.uk Neil Rashbrook]<br />
|peers=[mailto:dean_tessman@hotmail.com Dean Tessman], [mailto:timeless@mozdev.org Josh 'timeless' Soref]<br />
|group=dev-apps-seamonkey<br />
|source_dirs=xpfe/<br />
|url=http://www.mozilla.org/xpapps/<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=XPCOM<br />
|description=The cross-platform object model and core data structures.<br />
|owner=[https://mozillians.org/en-US/u/froydnj/ Nathan Froyd]<br />
|peers=[mailto:erahm@mozilla.com Eric Rahm]<br />
|ownersemeritus=Benjamin Smedberg<br />
|peersemeritus=[https://mozillians.org/en-US/u/dougt/ Doug Turner]<br />
|group=dev-platform<br />
|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/<br />
|url=http://developer.mozilla.org/en/XPCOM<br />
|components=Core::XPCOM<br />
}}<br />
<br />
{{Module<br />
|name=XPConnect<br />
|description=Deep Magic<br />
|owner=[mailto:bobbyholley@gmail.com Bobby Holley]<br />
|peers=[mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:peterv@propagandism.org Peter Van der Beken], [mailto:mrbkap@gmail.com Blake Kaplan], [mailto:gkrizsanits@mozilla.com Gabor Krizsanits], [mailto:amccreight@mozilla.com Andrew McCreight], [mailto:kmaglione@mozilla.com Kris Maglione]<br />
|peersemeritus=[mailto:gal@uci.edu Andreas Gal], [mailto:jstenback@gmail.com Johnny Stenback]<br />
|group=<br />
|source_dirs=js/xpconnect/<br />
|url=<br />
|components=Core::XPConnect<br />
}}<br />
<br />
{{Module<br />
|name=XPIDL<br />
|description=Cross-platform IDL compiler; produces .h C++ header files and .xpt runtime type description files from .idl interface description files.<br />
|owner=[mailto:me@kylehuey.com Kyle Huey]<br />
|peersemeritus=[mailto:shaver@mozilla.org Mike Shaver], [mailto:timeless@mozdev.org Josh 'timeless' Soref]<br />
|group=dev-tech-xpcom<br />
|source_dirs=xpcom/typelib/<br />
|url=http://www.mozilla.org/scriptable/xpidl<br />
http://www.mozilla.org/scriptable<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=XPInstall<br />
|description=<br />
|owner=[mailto:dveditz@mozilla.com Dan Veditz]<br />
|peers=[mailto:benjamin@smedbergs.us Benjamin Smedberg]<br />
|group=dev-tech-xpinstall<br />
|source_dirs=xpinstall/<br />
|url=<br />
|components=Core::Installer: XPInstall Engine<br />
}}<br />
<br />
{{Module<br />
|name=XPToolkit<br />
|description=Cross-platform user interface toolkit<br />
|owner=<br />
|peers=[mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:Jan.Varga@gmail.com Jan Varga]<br />
|group=dev-tech-xul<br />
|source_dirs=dom/xul/, layout/xul/<br />
|url=http://www.mozilla.org/xpfe/<br />
|components=Core::XP Toolkit/Widgets: Menus, Core::XP Toolkit/Widgets: XUL<br />
}}<br />
<br />
{{Module<br />
|name=XSLT Processor<br />
|description=XSLT transformations processor<br />
|owner=[mailto:peterv@propagandism.org Peter Van der Beken]<br />
|peers=[mailto:axel@pike.org Axel Hecht], [mailto:erahm@mozilla.com Eric Rahm]<br />
|peersemeritus=[mailto:jonas@sicking.cc Jonas Sicking]<br />
|group=dev-tech-xslt<br />
|source_dirs=dom/xslt/<br />
|url=http://www.mozilla.org/projects/xslt/, http://www.w3.org/TR/xslt.html<br />
|components=Core::XSLT<br />
}}<br />
<br />
{{Module<br />
|name=Sandboxing<br />
|description=Cross platform sandboxing<br />
|owner=[mailto:gcp@mozilla.com Gian-Carlo Pascutto]<br />
|peers=[mailto:bowen@mozilla.com Bob Owen], [mailto:aklotz@mozilla.com Aaron Klotz], [https://mozillians.org/en-US/u/TimAbraldes Tim Abraldes], [mailto:gDestuynder@mozilla.com Guillaume Destuynder], [mailto:jld@mozilla.com Jed Davis]<br />
|group=dev-platform <br />
|source_dirs=security/sandbox<br />
|url=https://wiki.mozilla.org/Security/Sandbox <br />
|components=Core::Security: Process Sandboxing<br />
}}<br />
<br />
{{Module<br />
|name=Sandboxing - Windows <br />
|description=Sandboxing for the Windows platform <br />
|owner=[mailto:bowen@mozilla.com Bob Owen]<br />
|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]<br />
|group=dev-platform<br />
|source_dirs=security/sandbox/win <br />
|url=https://wiki.mozilla.org/Security/Sandbox <br />
|components=Core::Security: Process Sandboxing<br />
}}<br />
<br />
{{Module<br />
|name=Sandboxing - OSX <br />
|description=Sandboxing for the OSX platform <br />
|owner=[mailto:haftandilian@mozilla.com Haik Aftandilian]<br />
|peers=<br />
|group=dev-platform <br />
|source_dirs=security/sandbox/mac <br />
|url=https://wiki.mozilla.org/Security/Sandbox <br />
|components=Core::Security: Process Sandboxing<br />
}}<br />
<br />
{{Module<br />
|name=Sandboxing - Linux & B2G<br />
|description=Sandboxing for the Linux & B2G platforms<br />
|owner=[mailto:jhector@mozilla.com Julian Hector]<br />
|peers=[mailto:jld@mozilla.com Jed Davis] [mailto:gcp@mozilla.com Gian-Carlo Pascutto]<br />
|group=dev-platform<br />
|source_dirs=security/sandbox/linux<br />
|url=https://wiki.mozilla.org/Security/Sandbox <br />
|components=Core::Security: Process Sandboxing<br />
}}<br />
<br />
===Submodules===<br />
{{Module<br />
|name=Build Config - Fennec<br />
|description=Submodule of the build config covering Fennec's build system in mobile/android.<br />
|owner=[mailto:nalexander@mozilla.com Nicholas Alexander]<br />
|peers=Same as Build Config<br />
|group=dev-builds<br />
|components=Core::Build Config<br />
}}<br />
<br />
{{Module<br />
|name=WebRTC Media<br />
|description=Submodule of WebRTC responsible for access to media input devices (microphones, cameras, screen capture), as well as realtime audiovisual codecs and packetization.<br />
|owner=[mailto:rjesup@mozilla.com Randell Jesup]<br />
|peers=[mailto:jib@mozilla.com Jan-Ivar Bruaroey], [mailto:dminor@mozilla.com Dan Minor], [mailto:apehrson@mozilla.com Andreas Pehrson], <br />
|peersemeritus=[mailto:pkerr@mozilla.com Paul Kerr], [mailto:ehugg@cisco.com Ethan Hugg]<br />
|group=dev-media<br />
|source_dirs=/media/webrtc, /dom/media/webrtc, /dom/media/systemservices<br />
|url=https://wiki.mozilla.org/Media/webrtc<br />
|components=Core::WebRTC (Audio/Video)<br />
}}<br />
<br />
{{Module<br />
|name=WebRTC Signaling<br />
|description=Submodule of WebRTC responsible for implementation of PeerConnection API, WebRTC identity, and SDP/JSEP handling<br />
|owner=[mailto:bcampen@mozilla.com Byron Campen]<br />
|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]<br />
|peersemeritus=[mailto:ehugg@cisco.com Ethan Hugg]<br />
|group=dev-media<br />
|source_dirs=/media/webrtc/signaling/<br />
|url=https://wiki.mozilla.org/Media/webrtc<br />
|components=Core::WebRTC (Signaling)<br />
}}<br />
<br />
<br />
<noinclude><br />
<br />
===Unassigned Bugzilla Components===<br />
<br />
The following Bugzilla components in the Core project have not been assigned to a module (this list is not exhaustive):<br />
<br />
<pre><br />
Core::Find Backend<br />
Core::General<br />
Core::HTML: Form Submission<br />
Core::History: Global<br />
Core::Image Blocking<br />
Core::Localization<br />
Core::Networking: Domain Lists<br />
Core::Selection<br />
Core::Serializers<br />
Core::Spelling checker<br />
Core::X-remote<br />
Core::XUL<br />
</pre><br />
</noinclude></div>Dbaronhttps://wiki.mozilla.org/index.php?title=CSS&diff=1185834CSS2017-12-15T21:27:03Z<p>Dbaron: /* CSS Color Level 4 */ mention color mgmt</p>
<hr />
<div>This is the Mozilla wiki home page for Cascading Style Sheets (CSS), one of several areas of Open Web [[Standards]].<br />
<br />
<span style="float:right">__TOC__</span><br />
= CSS =<br />
== Platform priorities ==<br />
The following CSS specs/proposals are a priority for the [[Platform]].<br />
<br />
=== 2018 Priorities ===<br />
These are *in progress* 2018 Priorities for CSS features in Firefox.<br />
<br />
(currently being discussed at [[Yallhands]] in Austin, Texas)<br />
* Bugzilla: https://bugzilla.mozilla.org/show_bug.cgi?id=1424418<br />
* Some public input: https://twitter.com/t/status/939273644043366400<br />
<br />
==== Critical Fixes ====<br />
Critical fixes to features or larger specs we already support (more important than new features in general)<br />
* https://bugzilla.mozilla.org/show_bug.cgi?id=1398482<br />
* ...<br />
<br />
==== Shapes ====<br />
* [https://drafts.csswg.org/css-shapes/ CSS Shapes] (CR, another CR expected any moment now in 2017) [https://bugzilla.mozilla.org/show_bug.cgi?id=1040714 metabug]<br />
** [https://bugzilla.mozilla.org/show_bug.cgi?id=1098939 shape-outside]<br />
<br />
==== Grid Level 2 ====<br />
Grid Level 2 AKA subgrid (use-cases, a11y implications)<br />
* [https://drafts.csswg.org/css-grid-2/ CSS Grid level 2] specifically [https://bugzilla.mozilla.org/buglist.cgi?quicksearch=subgrid for subgrid]<br />
* doing some exploratory implementing, design may (hopefully likely) change accordingly<br />
* see also for quick use-cases / tutorial:<br />
** http://fantasai.inkedblade.net/style/discuss/subgrid-markup/<br />
<br />
==== Box Alignment ====<br />
* [https://drafts.csswg.org/css-align/ CSS Box Alignment] ([https://www.w3.org/TR/css-align-3/ WD]), [https://bugzilla.mozilla.org/show_bug.cgi?id=1105570 metabug]<br />
** all properties for blocks (e.g. [https://bugzilla.mozilla.org/show_bug.cgi?id=1105571 1105571])<br />
** and some details for flexbox (see metabug 1105570 Depends on)<br />
** spec CR depends on resolving [https://github.com/w3c/csswg-drafts/labels/css-align-3 open css-align-3 issues]<br />
<br />
==== Scroll Snap update ====<br />
* [https://drafts.csswg.org/css-scroll-snap-1/ Scroll Snap] ([https://www.w3.org/TR/css-scroll-snap-1/ CR]), [https://bugzilla.mozilla.org/show_bug.cgi?id=1231777 metabug]<br />
** Fix [https://bugzilla.mozilla.org/buglist.cgi?quicksearch=%22scroll+snap%22 related bugs]<br />
<br />
==== Scrollbar Styling ====<br />
Spec in editor's draft - many requests for this<br />
* https://drafts.csswg.org/css-scrollbars-1/<br />
<br />
==== text-decoration-skip ====<br />
* Bugzilla: https://bugzilla.mozilla.org/show_bug.cgi?id=812990 <br />
* parity with Chrome<br />
<br />
==== Sizing ====<br />
[https://drafts.csswg.org/css-sizing-3/ CSS Intrinsic & Extrinsic Sizing Module Level 3] ([https://www.w3.org/TR/css-sizing-3/ WD]) [https://bugzilla.mozilla.org/show_bug.cgi?id=1312587 metabug]<br />
* intrinsic size keywords: fix [https://bugzilla.mozilla.org/show_bug.cgi?id=567039 #567039] & [https://bugzilla.mozilla.org/show_bug.cgi?id=1055887 #1055887], and unprefix ([https://bugzilla.mozilla.org/show_bug.cgi?id=1322780 #1322780]<br />
<br />
==== Containment ====<br />
* [https://drafts.csswg.org/css-containment/ CSS Containment Module Level 1] ([https://www.w3.org/TR/2017/WD-css-contain-1-20170221/ FPWD]) 'contain' property, size/layout, style, paint. [https://bugzilla.mozilla.org/show_bug.cgi?id=1150081 metabug]<br />
<br />
==== Multi-column ====<br />
* [https://drafts.csswg.org/css-multicol/ CSS Multi-column Layout] ([https://www.w3.org/TR/css3-multicol/ TR WD]), [https://bugzilla.mozilla.org/show_bug.cgi?id=684062 metabug]<br />
** unprefixing, [https://bugzilla.mozilla.org/show_bug.cgi?id=616436 column-span], a11y bug hack removal, column-break<br />
** Alias page-break-* to break-*: https://bugzilla.mozilla.org/show_bug.cgi?id=775618 <br />
(Jen has a demo of bugs / test page at http://labs.jensimmons.com/examples/multicolumn-3-bug-demo.html)<br />
<br />
==== Fonts Level 4 ====<br />
For Variable Fonts support in particular:<br />
* Bugzilla for Variable Fonts: https://bugzilla.mozilla.org/show_bug.cgi?id=1302685<br />
* [https://drafts.csswg.org/css-fonts-4/ Fonts 4], [https://bugzilla.mozilla.org/show_bug.cgi?id=css-fonts-4 metabug]<br />
(reprioritize Fonts Level 4 accordingly once we have Variable Fonts)<br />
<br />
==== Values and Units 3 ====<br />
[https://www.w3.org/TR/css3-values/ CSS Values and Units Module Level 3] (CR) [https://bugzilla.mozilla.org/show_bug.cgi?id=741643 metabug]<br />
* [ ] calc() function in particular. [https://bugzilla.mozilla.org/show_bug.cgi?id=1376206 metabug]<br />
* re-prioritize Values and Units 3 once calc fixes have landed.<br />
* [ ] attr function (at risk) — very useful in combination with CSS Shapes, in the context of a CMS<br />
<br />
==== CSS Color Level 4 ====<br />
[https://drafts.csswg.org/css-color-4/ CSS Color Module Level 4] (ED), [https://bugzilla.mozilla.org/show_bug.cgi?id=1352753 metabug]<br />
* Color improvements (wide gamut, color correction, note CSS color correction preffed off)<br />
<br />
Implement correct color management of CSS colors (which is really earlier levels of CSS color).<br />
<br />
==== Inline Layout ====<br />
* [https://drafts.csswg.org/css-inline/ CSS Inline Layout Module Level 3] ([https://www.w3.org/TR/css-inline-3/ TR WD]), [https://bugzilla.mozilla.org/show_bug.cgi?id=1312611 metabug]<br />
** focusing for now on CSS Initial-letter related features ([https://bugzilla.mozilla.org/show_bug.cgi?id=1273019 initial-letter * metabug])<br />
*** one (implementation design) blocker issue: https://github.com/w3c/csswg-drafts/issues/743<br />
<br />
==== SVG properties in CSS ====<br />
This bit from SVG2:<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1383650 1383650: Implement SVG geometry properties in CSS]<br />
<br />
==== Media Queries 4 ====<br />
* [https://drafts.csswg.org/mediaqueries-4/ Media Queries 4] (note: [https://drafts.csswg.org/mediaqueries-4/#changes-2012 new features in 4]), [https://bugzilla.mozilla.org/show_bug.cgi?id=1312621 metabug]<br />
** full support of numerical comparators (&lt;, &lt;=, =>, >)<br />
** expansion of negation syntax (and, or, not)<br />
** [https://drafts.csswg.org/mediaqueries-4/#mf-interaction interaction features] [https://bugzilla.mozilla.org/show_bug.cgi?id=1035774 #1035774]<br />
** [https://logs.csswg.org/irc.w3.org/css/2017-08-02/#e841291 2017-08-02 CSSWG resolved to take to CR]<br />
<br />
==== Container Queries Prerequisites ====<br />
There's a lot of anecdotal demand for Container Queries / Element Queries. See replies here:<br />
* https://twitter.com/t/status/939273644043366400<br />
<br />
We should at least figure out what features / bug fixes we would need to address to even consider something like Container Queries (which we should also give input on)<br />
* RICG cq-usecases: https://github.com/ResponsiveImagesCG/cq-usecases ([https://github.com/ResponsiveImagesCG/cq-usecases/issues/36#issuecomment-287917442 Requirements section? #36])<br />
* one proposal: https://tomhodgins.github.io/element-queries-spec/element-queries.html<br />
<br />
==== Better Print Support ====<br />
Start looking at what specs and features would significantly improve print support. Much of this is testing and bugfixing edgecases of existing features, some of it may require or benefit from new specs/features.<br />
* [https://drafts.csswg.org/css-page-3/ CSS Paged Media Module Level 3] ([https://www.w3.org/TR/css3-page/ old 2013 WD]) [https://bugzilla.mozilla.org/show_bug.cgi?id=286443 metabug]<br />
More specs / features in particular TBD.<br />
<br />
=== Actively Implementing ===<br />
Beyond the above priorities, we should continue to actively implement, fix bugs on the following:<br />
<br />
* [[Stylo]] ([https://bugzilla.mozilla.org/show_bug.cgi?id=1243581 metabug])<br />
<br />
==== Flexbox ====<br />
Mozilla has a pretty solid complete [https://www.w3.org/TR/css-flexbox-1/ Flexbox] (W3C CR, just waiting on feature-interaction tests to go PR) implementation. We are working on some fixes to make it even better, e.g.<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1055888 Metabug for to-be-implemented spec changes]<br />
<br />
==== Grid ====<br />
* [https://drafts.csswg.org/css-grid/ CSS Grid] ([https://www.w3.org/TR/2017/CR-css-grid-1-20170509/ CR]) [https://bugzilla.mozilla.org/show_bug.cgi?id=1312610 metabug]<br />
** [https://bugzilla.mozilla.org/buglist.cgi?quicksearch=%5Bcss-grid%5D lots of work] <br />
<br />
==== 3D Transforms ====<br />
* 3D Transform interop / spec changes, [https://bugzilla.mozilla.org/buglist.cgi?quicksearch=%223d%20transform%22 3D transform bugs]<br />
<br />
==== Masking ====<br />
* [https://drafts.fxtf.org/css-masking-1/ CSS Masking] (W3C [https://www.w3.org/TR/css-masking-1/ CR]), [https://bugzilla.mozilla.org/show_bug.cgi?id=1312613 metabug]<br />
** another clip-path ticket — path(): https://bugzilla.mozilla.org/show_bug.cgi?id=1246764<br />
<br />
==== Text Decoration ====<br />
[https://drafts.csswg.org/css-text-decor-3/ CSS Text Decoration Module Level 3] ([https://www.w3.org/TR/2013/CR-css-text-decor-3-20130801/ 2013 CR]) ([https://bugzilla.mozilla.org/show_bug.cgi?id=1221864 metabug]), e.g.:<br />
* focusing on text-decoration-skip https://bugzilla.mozilla.org/show_bug.cgi?id=812990 <br />
* text-emphasis ([https://bugzilla.mozilla.org/show_bug.cgi?id=1225012 remaining bugs])<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=770780 text-underline-position]<br />
* What else left for this module? (JS)<br />
** See "Depends on" in [https://bugzilla.mozilla.org/show_bug.cgi?id=1221864 metabug 1221864] (TÇ)<br />
<br />
==== Writing Modes ====<br />
[https://drafts.csswg.org/css-writing-modes-3/ CSS Writing Modes Level 3] ([https://www.w3.org/TR/css-writing-modes/ 2015 CR]) ([https://bugzilla.mozilla.org/show_bug.cgi?id=145503 metabug])<br />
* [https://logs.csswg.org/irc.w3.org/css/2017-08-04/#e847806 2017-08-04 CSSWG Resolved] to publish an updated CR<br />
<br />
==== Fonts Level 3 ====<br />
Wrap-up the few remaining bugs, or declare that we're done (e.g. font-variant as a descriptor?)<br />
* [https://drafts.csswg.org/css-fonts-3/ Fonts 3], [https://bugzilla.mozilla.org/show_bug.cgi?id=651693 metabug]<br />
<br />
==== Under the hood and related ====<br />
* Intersection observer ([https://groups.google.com/forum/#!searchin/mozilla.dev.platform/Intersection$20observer%7Csort:relevance/mozilla.dev.platform/YdKTMvQygl0/etZvkSkeDQAJ Intent to ship thread])<br />
* Resize observer (intent to implement coming)<br />
* [https://w3c.github.io/web-animations/ Web Animations API] ([https://bugzilla.mozilla.org/show_bug.cgi?id=875219 metabug])<br />
<br />
=== Evaluating ===<br />
==== Font Rendering Controls ====<br />
[https://tabatkins.github.io/specs/css-font-display/ CSS Font Rendering Controls Module Level 1] (ED)<br />
* focusing on font-display descriptor https://bugzilla.mozilla.org/show_bug.cgi?id=1317445 (implemented behind a flag, other browsers too)<br />
<br />
==== Font Loading ====<br />
[https://www.w3.org/TR/css-font-loading/ CSS Font Loading Module Level 3] https://developer.mozilla.org/en-US/docs/Web/API/CSS_Font_Loading_API shipped in 41<br />
* CSS Font Loading Improvements, Multiple bugs<br />
<br />
==== Other ====<br />
* font inflation removed<br />
* CSS Transform properties (shorthands)<br />
<br />
=== Related HTML5 ===<br />
[[HTML5]] layout and presentation related work:<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1149357 srcset intrinsic size]<br />
* ...<br />
<br />
=== Recent CRs ===<br />
==== Cascading and Inheritance ====<br />
* [https://drafts.csswg.org/css-cascade-3/ CSS Cascading and Inheritance Level 3] ([https://www.w3.org/TR/css-cascade-3/ CR]), [https://bugzilla.mozilla.org/show_bug.cgi?id=1312619 metabug]<br />
** [https://drafts.csswg.org/css-cascade-3/#changes-2 New features since CSS2.x]<br />
*** scoped styles, animations, and transitions in the cascade. <br />
<br />
=== Upcoming CRs ===<br />
These CRs are expected in 2017:<br />
<br />
For all potential CRs:<br />
* Which browsers have openly announced implementations or intent to implement? (links?)<br />
<br />
* Box Alignment (see above)<br />
<br />
==== Text Level 3 ====<br />
* [https://drafts.csswg.org/css-text/ Text] (need list of [https://www.w3.org/Style/CSS/Tracker/actions/799 changes since CSS 2.1]), [https://bugzilla.mozilla.org/show_bug.cgi?id=104960 metabug]<br />
<br />
==== Selectors 4 ====<br />
[https://drafts.csswg.org/selectors-4/ Selectors 4] (need list of [https://github.com/w3c/csswg-drafts/issues/622 changes since 3]), [https://bugzilla.mozilla.org/show_bug.cgi?id=693083 metabug]<br />
* No explicit dependency on Stylo, just lower priority<br />
* Selectors4 remaining features<br />
** CSS ::selection fixes + unprefixing<br />
** ... remaining new features? (JS)<br />
<br />
=== Shipping Soon ===<br />
As the above priorities get implemented, moving down here to note we're waiting for them to ship.<br />
<br />
==== Image Values and Replaced Content ====<br />
[https://www.w3.org/TR/css3-images/ CSS Image Values and Replaced Content Module Level 3] (CR)<br />
* image() function<br />
* [ ] xywh fragment syntax<br />
<br />
==== Style sheet APIs for Add-ons ====<br />
* style sheet APIs in add-ons SDK / loading async APIs (to be handled by stylo)<br />
<br />
==== Filter Effects Level 2 ====<br />
* [https://drafts.fxtf.org/filters-2/#BackdropFilterProperty Filter Effects Module Level 2: backdrop-filter]<br />
** [https://bugzilla.mozilla.org/show_bug.cgi?id=1178765 backdrop-filter bug] (caniuse: only Safari supports)<br />
** also on Trello Future Backlog<br />
<br />
==== Motion Path Module ====<br />
https://www.w3.org/TR/motion-1/ (currently Working Draft)<br />
<br />
==== Device Adaptation ====<br />
[https://drafts.csswg.org/css-device-adapt/ CSS Device Adaptation Module Level 1] ([https://www.w3.org/TR/css-device-adapt-1/ WD])<br />
<br />
==== Houdini ====<br />
* [[CSS/Houdini|CSS Houdini]] - see inside for Houdini implementation thoughts/plan<br />
<br />
== properties ==<br />
Please add subpages for each (unprefixed) CSS property in alphabetical order.<br />
<br />
* ...<br />
* [[CSS/overflow|overflow]]<br />
* ...<br />
* [[CSS/text-overflow|text-overflow]]<br />
* ...<br />
<br />
=== in development ===<br />
CSS properties which have not yet made it to a Candidate Recommendation (or later), or are only implemented in the wild in prefixed form.<br />
<br />
==== new pseudo-classes ====<br />
* ...<br />
* [[CSS/:autofill|:autofill]]<br />
* ...<br />
<br />
==== new properties ====<br />
* ...<br />
* [[CSS/text-size-adjust|text-size-adjust]] (-moz-, -ms-, -webkit-)<br />
* ...<br />
<br />
== See Also ==<br />
{{Special:PrefixIndex/{{FULLPAGENAME}}/}}<br />
* [[CSS3]]<br />
* [[HTML5]]<br />
* [[Standards]]<br />
* [https://developer.mozilla.org/en/CSS MDN: CSS home page]<br />
* [http://mozdevs.github.io/devrel-dashboard/ Mozilla DevRel Dashboard] - dynamic overview of [META] and other high level bugs in [[CSS]], [[DOM]], [[DevTools]], [[MDN]], [[Toolkit]], etc.<br />
* [https://wiki.csswg.org/ CSS Working Group Wiki]</div>Dbaronhttps://wiki.mozilla.org/index.php?title=Standards/GitHub_IPR_Organization&diff=1185657Standards/GitHub IPR Organization2017-12-11T17:30:24Z<p>Dbaron: link to mozillians.org</p>
<hr />
<div>The [https://github.com/mozilla-standards mozilla-standards GitHub organization] exists for interactions between Mozilla and standards bodies that use GitHub organizations to track organization-wide IPR commitments.<br />
<br />
Many standards organizations require contributors to make intellectual property rights (IPR) commitments regarding copyrights and patents. These generally need to be made by the company the contributor works for. So this organization is designed to contain people who are paid to work for Mozilla, so that standards development organizations that use GitHub organizations can track who Mozilla's IPR commitment applies to.<br />
<br />
For now, ask [https://mozillians.org/u/dbaron/ dbaron] or [https://mozillians.org/u/annevk/ annevk] to be added. This will likely be more automated in the future.<br />
<br />
Standards organizations that currently use this:<br />
* [https://whatwg.org/ WHATWG]</div>Dbaronhttps://wiki.mozilla.org/index.php?title=Standards/Github_IPR_Organization&diff=1185654Standards/Github IPR Organization2017-12-11T17:09:01Z<p>Dbaron: redirect to correct spelling</p>
<hr />
<div>#REDIRECT [[Standards/GitHub IPR Organization]]</div>Dbaronhttps://wiki.mozilla.org/index.php?title=Standards/GitHub_IPR_Organization&diff=1185653Standards/GitHub IPR Organization2017-12-11T17:08:35Z<p>Dbaron: create page on mozilla-standards github org</p>
<hr />
<div>The [https://github.com/mozilla-standards mozilla-standards github organization] exists for interactions between Mozilla and standards bodies that use github organizations to track organization-wide IPR commitments.<br />
<br />
Many standards organizations require contributors to make intellectual property rights (IPR) commitments regarding copyrights and patents. These generally need to be made by the company the contributor works for. So this organization is designed to contain people who are paid to work for Mozilla, so that standards development organizations that use github organizations can track who Mozilla's IPR commitment applies to.<br />
<br />
For now, ask dbaron to be added. This will likely be more automated in the future.<br />
<br />
Standards organizations that currently use this:<br />
* [https://whatwg.org/ WHATWG]</div>Dbaronhttps://wiki.mozilla.org/index.php?title=GitHub&diff=1185652GitHub2017-12-11T17:06:55Z<p>Dbaron: /* Is "mozilla" the only github "organization" related to Mozilla? */ add mozilla-standards</p>
<hr />
<div>This page is specifically about [https://github.com/mozilla the "mozilla" organization on github]. There are several other github organizations you may be interested in, cf. the incomplete list [[#other_github|below]].<br />
<div id="contact"><br />
{| class="wikitable"<br />
|-<br />
! [[File:Red_question_mark.png|144px|Send us an email!|link=]] Got a question?<br />
|-<br />
| Email {{emailentry|github-owners|mozilla.org|at=is}} <br /><br />
Bugzilla [https://bugzilla.mozilla.org/enter_bug.cgi?comment=I%27ve%20read%20https%3A%2F%2Fwiki.mozilla.org%2FGithub%2C%20and%20need%20help%20with%20the%20following.%0D%0A%0D%0A&component=Github%3A%20Administration&form_name=enter_bug&product=mozilla.org& mozilla.org :: Github: Administration] <br /><br />
irc #github on [[IRC|moznet]]<br />
|}<br />
<br />
== News ==<br />
* As of June 20, 2016, all members [https://groups.google.com/forum/#!topic/mozilla.dev.platform/UmHOOh3qtiM must have 2FA enabled]. You have been notified if this impacts you.<br />
<br />
== Recommendations and FAQ ==<br />
<br />
=== Where should I ask additional questions? ===<br />
* Send an email to '''{{emailentry|github-owners|mozilla.org|at=is}}''' and we'll respond right away! We're also available on #github on irc.<br />
<br />
=== How do I hook up a new 3rd party application to a repository in the mozilla org? ===<br />
{{note|There are now multiple 3rd pary application types. "GitHub Apps" (nee integrations) are the new approach and preferred.|gotcha}}<br />
{{note|Some 3rd party apps use GitHub as an OAuth identity provider for their website (e.g. for a dashboard). An ''OAuth Application'' will block the installation process if the app is not already approved. The "Request access" block is what this section describes.|gotcha}}<br />
<br />
3rd party applications can easily impact many other repositories than the initial one. For that reason, the following steps are strongly encouraged. Note that there are three ways 3rd party apps can be associated with the entire organization, or a specific repository:<br />
# via a manually configured webhook. This type of installation is not automatically affected by the other approaches.<br />
# via an "GitHub App" (nee integration), which is connected by "Installing" it into the target. Both of those steps require an "owner" to perform. Please open a bug. (This is the new, preferred way.)<br />
# via granting access via OAUTH tied to the installer's credentials. Please open a bug. Some services will OAuth just as an Identitdy Provider for access to a dashboard on their site. You only need to file if you get to a "Request access" prompt.<br />
<br />
<br />
You can help speed up the approval process by opening a bug as the way to contact the owners and provide answers to the questions they will have (the owners will open a bug for a security review if needed):<br />
* Use this [https://bugzilla.mozilla.org/enter_bug.cgi?cc=gene%40mozilla.com&comment=I%20want%20to%20use%20the%20NAME_HERE%20addon%20in%20ORG_NAME_HERE%20for%20the%20following%20reasons%3A%0D%0A%0D%0ABelow%20are%20my%20answers%20to%20your%20stock%20questions%3A%0D%0A%0D%0A%2A%2A%20Which%20repositories%20do%20you%20want%20to%20have%20access%3F%20%28all%20or%20list%29%0D%0A%0D%0A%2A%2A%20Are%20any%20of%20those%20repositories%20private%3F%0D%0A%0D%0A%2A%2A%20Provide%20link%20to%20vendor%27s%20description%20of%20permissions%20needed%20and%20why%0D%0A%0D%0A%2A%2A%20Provide%20the%20Install%20link%20for%20a%20GitHub%20app%0D%0A&component=Github%3A%20Administration&product=mozilla.org&short_desc=Assess%20use%20of%20external%20addon%20NAME_HERE%20in%20Mozilla%27s%20GitHub%20organization%20ORG_NAME_HERE bug template]<br />
* Include answers to these questions:<br />
** Which repositories do you want to have access? (all or list)<br />
** Are any of those repositories private?<br />
** Provide link to vendor's description of permissions needed and why<br />
** Provide installation instructions (both may be needed):<br />
*** For GitHub Apps, the "install" link<br />
*** For OAuth apps, request the approval of the app for the organization (part of their workflow).<br />
<br />
<br />
==== GitHub Apps ====<br />
<br />
GitHub Apps (formerly called "integrations") are "Installed" into either the entire organization, or into individual repositories. Each integration has a documented, granular, access to various of the repository resources. This is good.<br />
<br />
However, the GitHub App installation can only be done by an organization owner, who may have to do additional housekeeping. This is not so good, so please plan accordingly (you may need to coordinate with [[#contact|GitHub owners]]).<br />
<br />
===== Initial Installation =====<br />
If this is the first time this GitHub App is being installed in the organization, a few extra checks and coordination are needed. An organization owner will need to perform these steps:<br />
* Determine if the GitHub App previously had an OAUTH version.<br />
** If so, it is likely that installing the integration will disable all repositories in the organization using the OAUTH version of the application.<br />
** Find all current repositories using the classic OAUTH application (this is non-trivial, scripts exist to help)<br />
** Install the Integration for all current repositories, and the new one (organization owner permissions needed.)<br />
<br />
**Please do not install GitHub apps with organization wide scope without first discussing with [[#contact|GitHub owners]].**<br />
<br />
===== Additional Installations or Removals =====<br />
If the GitHub App has already been installed in the organization, the new repository simply needs to be added or removed from the list. An organization owner has to make this change.<br />
<br />
==== OAUTH (classic) Applications ====<br />
<br />
* Authorizing an application to work with GitHub utilizes the permissions your account has -- so, any repositories you have access to the application will have access to as well (including private ones). If you want to grant access to an application that no one else has used with the Mozilla organization yet you'll see a "Request access" button during the set up flow. You'll need to click that button to request approval. See below for an example:<br />
<br />
<br />
[[File:github_approval.png]]<br />
<br />
* In some cases, the application does not need to be "approved" to function correctly, as it has read only access to any public repository. (Some applications only want write access to help you configure the application first time.)<br />
<br />
* In other cases, the application does need write permission, and/or permission to read a private repository. In these cases, it is helpful to send the details to the owner's team, either by [https://bugzilla.mozilla.org/enter_bug.cgi?cc=gene%40mozilla.com&comment=I%20want%20to%20use%20the%20NAME_HERE%20addon%20in%20ORG_NAME_HERE%20for%20the%20following%20reasons%3A%0D%0A%0D%0ABelow%20are%20my%20answers%20to%20your%20stock%20questions%3A%0D%0A%0D%0A%2A%2A%20Which%20repositories%20do%20you%20want%20to%20have%20access%3F%20%28all%20or%20list%29%0D%0A%0D%0A%2A%2A%20Are%20any%20of%20those%20repositories%20private%3F%0D%0A%0D%0A%2A%2A%20Provide%20link%20to%20vendor%27s%20description%20of%20permissions%20needed%20and%20why%0D%0A%0D%0A%2A%2A%20Provide%20the%20Install%20link%20for%20a%20GitHub%20app%0D%0A&component=Github%3A%20Administration&product=mozilla.org&short_desc=Assess%20use%20of%20external%20addon%20NAME_HERE%20in%20Mozilla%27s%20GitHub%20organization%20ORG_NAME_HERE opening a bug] or [[#contact|email]].<br />
<br />
=== Reviewing owners and permissions ===<br />
As an owner or repository admin you're responsible for maintaining the list of people with access to your projects. Please be active and prudent about maintaining this list.<br />
<br />
=== Can I be an Owner of the Mozilla Organization? ===<br />
The Owners group on GitHub has complete administrative power and will be limited to a minimal number of people and reviewed regularly. If a person is an owner, they are expected to actively participate in the group and assist others as requested. Owners will be added as a need arises (for example, support in another timezone) as determined by the current owners.<br />
<br />
=== Can I be a Member of the Mozilla Organization? ===<br />
<div id="join"> </div><br />
==== Contributor Information ====<br />
Good news! You do not need to be a member of the Mozilla organization on GitHub before you can contribute to Mozilla!!!! We have several sites which can help you find the best fit for contribution:<br />
* General [https://www.mozilla.org/en-US/contribute/ volunteering options],<br />
* Or pick from [http://whatcanidoformozilla.org/ these areas],<br />
* Or jump right into [http://www.joshmatthews.net/bugsahoy/ fixing a bug].<br />
* If you're already a contributor (THANK YOU!) looking for a place to have your work recognized (even if not coding related), please see the [https://www.mozilla.org/credits/FAQ Credits FAQ] for inclusion in the [https://www.mozilla.org/credits/ credits].<br />
<br />
Once you're working on a project, the project leaders can help you get access to anything you need.<br />
<br />
==== Team Maintainers & Project Leads ====<br />
<br />
Project owners and team maintainers may find the following information helpful when asking for access for a new team member:<br />
<br />
*With recent GitHub enhancements (2015), we encourage the following (rough) guidelines, which strongly prefers using github teams. As a reminder, all members of the [https://github.com/mozilla/ Mozilla organization on github] agree to be bound by [https://www.mozilla.org/en-US/about/governance/policies/commit/requirements/ Mozilla's Commit Access Requirements], and should follow the intent of the [https://www.mozilla.org/en-US/about/governance/policies/commit/access-policy/ Mozilla's Commit Access Policy] as much as practical.<br />
** "Outside Collaborator": repository admins can grant outside collaborator to any GitHub account. "Outside Collaborator" is roughly analogous to "Level 1a" access to Mozilla-hosted repositories.<br />
** "Team Member": team maintainers can add GitHub users to a team, if they are already a member of the organization. If you are not yet a member of the organization, the team maintainer should [[#contact|request your addition]] to their team, as a form of vouching. "Team Member" is roughly analogous to "Level 2" or "Level 3", with the distinction being the content of the repositories managed by the team.<br />
<br />
{{note| As of January 6, 2017, we will start cancelling any invitation to the organization which is not accepted within 2 weeks of the invitation.}}<br />
<br />
{{note| As of June 30, 2016, all members of the Mozilla organization on GitHub '''MUST''' have [https://help.github.com/articles/about-two-factor-authentication/ 2FA enabled].|reminder}}<br />
<br />
{{note| Automation accounts are also required to have 2FA enabled. Scripts should use [https://help.github.com/articles/creating-an-access-token-for-command-line-use/ access tokens] with minimum permissions to accomplish the task.}}<br />
<br />
The best way to ask for a Contributor to be invited to the organization is to [https://bugzilla.mozilla.org/enter_bug.cgi?comment=I%27ve%20read%20https%3A%2F%2Fwiki.mozilla.org%2FGithub%2C%20and%20need%20help%20with%20the%20following.%0D%0A%0D%0A&component=Github%3A%20Administration&form_name=enter_bug&product=mozilla.org& open a bug] including the contributor's GitHub login, and the team(s) they need access to. A team maintainer or manager should approve in the bug.<br />
<br />
=== Should I make a separate github organization or just create a repository in an existing one? ===<br />
This is a personal preference. If you have a large enough project or organization feel free. We suggest you use the strategies and recommendations here as a model to manage the details.<br />
<br />
=== Forking vs Transferring ===<br />
'''Do not "fork" a repository into a Mozilla organization.''' Doing so gives ''every team in the org'' rights to it.<br />
<br />
If you have created a repo on your own account (for example, myuser/myrepo) and it should live under the Mozilla organization, here are the steps:<br />
<br />
{{note|As soon as you transfer, your repository will be in "limbo" (only you will have write access) until you get the assistance of an [[#contact|org admin]] who can make the changes. Please plan in advance if timing is critical.}}<br />
<br />
# If you're not a member of any team, talk to an [[#contact|org admin]].<br />
# Under the repo admin, transfer ownership to the Mozilla organization. If you don't see this option, return to step 1.<br />
# Choose which teams should be given access. All chosen teams will have only 'read' access at this point.<br />
# Ask an [[#contact|org admin]] to grant team permissions higher than read ('write' and 'admin' are the other choices). (Team maintainers do not have the ability to change a repositories status.)<br />
# Fork the repo from Mozilla (mozilla/myrepo) back to your account (recreating myuser/myrepo). While the transferred repo becomes the root of the network on GitHub (e.g. all forks are now forks of mozilla/myrepo) other users may be pointing to your repo by URL. (Optional, github will redirect old URLs for transfers, but you probably want a local repo if you use the PR workflow.)<br />
<br />
=== Do I need to be an owner to create repositories? ===<br />
No. If a person has read/write access to another repository in that organization they can make more repositories in that organization. However, it's preferred that you create repositories in the context of a team. Teams are created [https://github.com/orgs/mozilla/teams here], if necessary. Once you have created a repo, you can configure it to give rights to members of particular teams.<br />
<br />
=== Are there requirements for when or how I should create a new team? ===<br />
No. When requirements were proposed they all seemed too rigid and time consuming. Instead we recommend staying flexible and using good naming and documentation for projects (similar to naming CSS classes or variables).<br />
<br />
On large teams we recommend you separate teams for read/write and repository administration.<br />
<br />
<div id="other_github"></div><br />
=== Is "mozilla" the only github "organization" related to Mozilla? ===<br />
No, there are plenty of Mozilla-related "organizations" on github. As a rule of thumb, initiatives that create a large number of sub-repositories will create their own "organization". Here is a (probably incomplete) list of them:<br />
{| class="wikitable sortable"<br />
|-<br />
! Organization !! Description !! Contact Owner<br />
|-<br />
| [https://github.com/mozilla-it mozilla-it] || Mozilla IT's repositories || ?<br />
|-<br />
|[https://github.com/mozillabrasil mozillabrasil] || Mozilla Brazil|| ?<br />
|-<br />
| [https://github.com/bugzilla bugzilla] || Bugzilla (the product, not bugzilla.mozilla.org) || #bugzilla<br />
|- <br />
| [https://github.com/drumbeat-badge-sprint drumbeat-badge-sprint] || Drumbeat Badge Lab || ?<br />
|-<br />
| [https://github.com/hackasaurus hackasaurus] || Hackasaurus || ?<br />
|-<br />
| [https://github.com/jetpack-labs jetpack-labs] || Jetpack Labs || ?<br />
|-<br />
| [https://github.com/mdn mdn] || Mozilla Developer Network || [https://github.com/jwhitlock John Whitlock]<br />
|-<br />
| [https://github.com/mozbrick mozbrick] || Mozilla Brick (web components library) || ?<br />
|-<br />
| [https://github.com/mozilla-appmaker mozilla-appmaker] || Mozilla Appmaker || ?<br />
|-<br />
| [https://github.com/mozilla-b2g mozilla-b2g] || Mozilla Boot2Gecko / Firefox OS || ?<br />
|-<br />
| [https://github.com/mozilla-bteam mozilla-bteam] || Bugzilla.Mozilla.org || #bteam<br />
|-<br />
| [https://github.com/mozilla-cit mozilla-cit] || Mozilla Community Ops || {{Mozillians|tanner|Tanner Filip}} or {{Mozillians|yalam96|Yousef Alam}}<br />
|-<br />
| [https://github.com/mozilla-comm mozilla-comm] || Calendaring and Messaging related projects || ?<br />
|-<br />
| [https://github.com/mozilla-cordova mozilla-cordova] || Firefox OS Support for Apache Cordova || ?<br />
|-<br />
| [https://github.com/mozilla-iam mozilla-iam] || Mozilla's identity and access management || kang<br />
|-<br />
| [https://github.com/mozilla-platform-ops mozilla-platform-ops] || Mozilla Platform Operations || [[Platform_Operations]]<br />
|-<br />
| [https://github.com/mozilla-metrics mozilla-metrics] || Mozilla Metrics || ?<br />
|-<br />
| [https://github.com/mozilla-raptor mozilla-raptor] || Mozilla Raptor / Firefox OS Performance || {{Mozillian|eliperelman|Eli Perelman}}, {{Mozillian|rwood|Rob Wood}}<br />
|-<br />
| [https://github.com/mozilla-releng mozilla-releng] || Mozilla Release Engineering || #releng<br />
|-<br />
| [https://github.com/mozilla-services mozilla-services] || Mozilla Services || [https://github.com/orgs/mozilla-services/people?utf8=%E2%9C%93&query=role%3Aowner mozilla-services owners]<br />
|-<br />
| [https://github.com/mozilla-standards mozilla-standards] || Mozilla Standards (for IPR Contributions) || [https://mozillians.org/u/dbaron/ dbaron], [https://mozillians.org/u/annevk/ annevk]<br />
|-<br />
| [https://github.com/mozilla-svcops mozilla-svcops] || Mozilla Cloud Services Ops || {{Mozillian|relud|Daniel Thornton}}<br />
|-<br />
| [https://github.com/Mozilla-TWQA Mozilla-TWQA] || Mozilla Taiwan QA || ?<br />
|-<br />
| [https://github.com/mozillahispano mozillahispano] || Mozilla Hispano || ?<br />
|-<br />
| [https://github.com/MozillaScience MozillaScience] || Mozilla Science Lab || ?<br />
|-<br />
| [https://github.com/MozillaSecurity MozillaSecurity] || Mozilla Platform Fuzzing Team master repo with many fuzzing tools under it. || ?<br />
|-<br />
| [https://github.com/MozillaWiki MozillaWiki] || MozillaWiki (wiki.mozilla.org) || {{Mozillian|ckoehler|Christie Koehler}}, {{Mozillian|gphemsley|Gordon P. Hemsley}}<br />
|-<br />
| [https://github.com/mozillayvr mozillayvr] || Mozilla Vancouver @MozillaYVR || {{Mozillian|bclark|Brian Clark}}, {{Mozillian|shobson|Stephanie Hobson}}<br />
|-<br />
| [https://github.com/mozfr mozfr] || Mozilla Francophone || Pascal Chevrel https://mozillians.org/fr/u/pascalc/<br />
|-<br />
| [https://github.com/opennews opennews] || Knight-Mozilla OpenNews || ?<br />
|-<br />
| [https://github.com/rust-lang rust-lang] || The Rust Programming Language || {{Mozillian|aturon|Aaron Turon}}<br />
|-<br />
| [https://github.com/servo servo] || Servo (browser engine written in Rust) || {{Mozillian|larsberg|Lars Bergstrom}}, Jack Moffitt<br />
|-<br />
| [https://github.com/tabulapdf tabulapdf] || Tabula project (extract data from PDF files) || ?<br />
|-<br />
| [https://github.com/webcompat webcompat] || Web Compatibility Team || {{Mozillian|miketaylr|Mike Taylor}}<br />
|-<br />
| [https://github.com/mozilla-l10n mozilla-l10n] || Mozilla l10n-drivers team || Pascal Chevrel https://mozillians.org/fr/u/pascalc/<br />
|-<br />
| [https://github.com/taskcluster taskcluster] || [[TaskCluster]] Team || [https://github.com/gregarndt Greg Arndt]<br />
|-<br />
| [https://github.com/MozillaCH MozillaCH] || Mozilla [[Switzerland]] || {{Mozillian|mkohler|Michael Kohler}}, {{Mozillian|freaktechnik|freaktechnik}}<br />
|-<br />
| [https://github.com/mozmar mozmar] || Mozilla [[Marketing]] || {{Mozillian|bensternthal|Benjamin Sternthal}}, {{Mozillian|pmac|Paul McLanahan}}<br />
|-<br />
| [https://github.com/mozilla-payments mozilla-payments] || Implementation of Web Payment APIs || {{Mozillian|Marcos Caceres}}<br />
|-<br />
| [https://github.com/mozilla-jetpack mozilla-jetpack] || Resources for Mozilla's Add-on SDK || ?<br />
|-<br />
| [https://github.com/web-ext-experiments web-ext-experiments] || WebExtension API Experiments || {{Mozillian|andym|Andy McKay}}<br />
|-<br />
| [https://github.com/mozilla-conduit mozilla-conduit] || Mozilla Conduit work || {{Mozillian|mcote|Mark Côté}}<br />
|}<br />
<br />
=== Are there other unofficial or Mozilla-related repositories hosted on Github? ===<br />
Why, yes! In no particular order:<br />
<br />
* [https://github.com/kinetiknz/nestegg/ https://github.com/kinetiknz/nestegg/] : WebM demuxer<br />
* [https://github.com/xiph/opus/ https://github.com/xiph/opus/] : Modern audio compression for the internet.<br />
* [https://github.com/webmproject/libvpx https://github.com/webmproject/libvpx] : Mirror only. Please do not send pull requests.<br />
* [https://github.com/campd/fxdt-adapters https://github.com/campd/fxdt-adapters] : Firefox Developer Tools protocol adapters<br />
* [https://github.com/kripken/emscripten https://github.com/kripken/emscripten] : Emscripten: An LLVM-to-JavaScript Compiler<br />
* [https://github.com/bbondy/codefirefox https://github.com/bbondy/codefirefox] : Video and exercise based tutorial site for coding Firefox and other Mozilla related technology<br />
* [https://github.com/nickdesaulniers/where-is-firefox-os https://github.com/nickdesaulniers/where-is-firefox-os] : A map showing where in the world Firefox OS phones are being sold.<br />
* [https://github.com/jdm/bugsahoy https://github.com/jdm/bugsahoy] : A landing page to make finding relevant bugs easier for new Mozilla contributors.<br />
* [https://github.com/w3c/web-platform-tests https://github.com/w3c/web-platform-tests] : Test Suites for Web Platform specifications<br />
* [https://github.com/w3c/wptserve https://github.com/w3c/wptserve] : Web server designed for use with web-platform-tests<br />
* [https://github.com/w3c/wptrunner https://github.com/w3c/wptrunner] : Cross-browser and multi-platform test runner for web-platform-tests. Used in mozilla-central and servo.<br />
* [https://github.com/w3c/testharness.js https://github.com/w3c/testharness.js] : (no description)<br />
* [https://github.com/jdm/asknot https://github.com/jdm/asknot] : Ask not what Mozilla can do for you but what you can do for Mozilla.<br />
* [https://github.com/jeffbryner/MozDef https://github.com/jeffbryner/MozDef]: Mozilla Defense Platform.<br />
* [https://github.com/jgraham/webdriver-rust https://github.com/jgraham/webdriver-rust]: WebDriver library for Rust.<br />
* [https://github.com/ehsan/mozilla-cvs-history https://github.com/ehsan/mozilla-cvs-history]: A git conversion of the full Mozilla CVS history, useful for code archaeology.</div>Dbaronhttps://wiki.mozilla.org/index.php?title=Standards/Github_IPR_Organization&diff=1185651Standards/Github IPR Organization2017-12-11T17:04:21Z<p>Dbaron: formatting</p>
<hr />
<div>The [https://github.com/mozilla-standards mozilla-standards github organization] exists for interactions between Mozilla and standards bodies that use github organizations to track organization-wide IPR commitments.<br />
<br />
Many standards organizations require contributors to make intellectual property rights (IPR) commitments regarding copyrights and patents. These generally need to be made by the company the contributor works for. So this organization is designed to contain people who are paid to work for Mozilla, so that standards development organizations that use github organizations can track who Mozilla's IPR commitment applies to.<br />
<br />
For now, ask dbaron to be added. This will likely be more automated in the future.<br />
<br />
Standards organizations that currently use this:<br />
* [https://whatwg.org/ WHATWG]</div>Dbaronhttps://wiki.mozilla.org/index.php?title=Standards/Github_IPR_Organization&diff=1185650Standards/Github IPR Organization2017-12-11T17:03:54Z<p>Dbaron: initial description of mozilla-standards github org</p>
<hr />
<div>The [https://github.com/mozilla-standards mozilla-standards github organization] exists for interactions between Mozilla and standards bodies that use github organizations to track organization-wide IPR commitments.<br />
<br />
Many standards organizations require contributors to make intellectual property rights (IPR) commitments regarding copyrights and patents. These generally need to be made by the company the contributor works for. So this organization is designed to contain people who are paid to work for Mozilla, so that standards development organizations that use github organizations can track who Mozilla's IPR commitment applies to.<br />
<br />
For now, ask dbaron to be added. This will likely be more automated in the future.<br />
<br />
Standards organizations that currently use this:<br />
* [https://whatwg.org/ WHATWG]</div>Dbaronhttps://wiki.mozilla.org/index.php?title=All_Hands/Austin&diff=1181761All Hands/Austin2017-10-04T03:59:09Z<p>Dbaron: /* Dates, Location and Weather */ add ⁰C forecast link, and tweak links slightly</p>
<hr />
<div>'''What is it?''' -- Multiple team meetings, happening in the same city, at the same time + some opportunity to get together as one big group as well as with other teams as it makes sense. Then, on the last day, we have a fun social event for all, Mozilla-style! <br />
<br />
'''''The information on this wiki primarily applies to Full time and contractor staff. If you are a volunteer contributor or intern, please inquire to your coordinator. '''''<br />
<br />
=='''Dates, Location and Weather'''==<br />
Monday, December 11 - Friday, December 15, 2017 (travel days are Monday the 11th & Saturday the 16th*) in Austin, TX.<br />
<br />
We are staying at [http://www.marriott.com/hotels/fact-sheet/travel/ausjw-jw-marriott-austin/ JW Marriott Austin] & [http://www3.hilton.com/en/hotels/texas/hilton-austin-AUSCVHH/index.html Hilton Austin]. Pre/post links will be available once hotels are assigned in late October. <br />
<br />
''*For those countries where rest time is required on weekends (vs. work travel), Mozilla will cover a return on the next available work day, if you choose. This needs to pre-approved and pre-arranged.''<br />
<br />
Weather:<br />
* National Weather Service: [http://forecast.weather.gov/MapClick.php?smap=1&lat=30.264&lon=-97.742&unit=1&mp=1 forecast in ⁰C], [http://forecast.weather.gov/MapClick.php?smap=1&lat=30.264&lon=-97.742&mp=1 forecast in ⁰F]<br />
<br />
=='''Registration'''==<br />
This is an invite-only event.<br />
<br />
Advance registration is required. Attendees will need to wear their event badge at all times, including to evening events. We will have security at our events who will be ensuring everyone in our space should be there. <br />
<br />
=====New Hires=====<br />
We have a process to identify new hires each Monday and will invite them to book travel. No action necessary from managers other than to let them know about the event. Please work closely with your recruiting manager as they are aware of all deadlines.<br />
<br />
==== Volunteer contributor participation ====<br />
The process for this is [[All Hands/Austin/Volunteer nominations|outlined on this page]]. <br />
<br />
All nominations will be done by employees, with a coordinator from each of the Firefox, Emerging Technologies, Marketing, Open Innovation and Operations parts of the organization. There will be no open call for nominations from volunteer Mozillians.<br />
<br />
=='''Week at a Glance'''==<br />
===Monday===<br />
Arrivals, registration & welcome reception<br />
<br />
===Tuesday, Wednesday, Thursday===<br />
Plenary, Team meetings, [https://wiki.mozilla.org/All_Hands/Austin/electives Electives]<br />
<br />
===Friday===<br />
Team meetings, Closing Party<br />
<br />
===Saturday===<br />
Departures<br />
<br />
=='''Food & Drink'''==<br />
Breakfast, lunch & snacks will be provided and paid for centrally for attendees. Breakfast is provided Tuesday - Saturday and lunch is provided Tuesday - Friday. <br />
<br />
Allergies/preferences: We will ensure that all food/environmental allergies are taken into consideration and will always have gluten-free and vegan options. If you have severe allergies that we need to know about; you can indicate in registration.<br />
<br />
=='''Safety & Security'''==<br />
=====Device Security=====<br />
If you are traveling to the Austin All Hands with a device that has Mozilla data (laptop, personal cell phone/tablet with @mozilla gmail, etc) on it and your device has been retained for further inspection by border agents, or if your device has been inspected outside your immediate presence - and you believe your credentials have been compromised - you must notify the Enterprise Information Security team as soon as possible at infosec@mozilla.com or by calling Mozilla End User Services at +1 650-963-8811. (This number will be staffed 24x7)<br />
<br />
We will work with you to reset your credentials and help you get your device back to a known good state either by getting you a new one (if it’s been taken), or by resetting it back to a verifiable Mozilla-approved installation.<br />
<br />
=='''Hotel'''==<br />
Hotels are reserved during registration. Mozilla will pay for your hotel room with a check in date of Monday, December 11 and a check-out of Saturday, December 16. Once hotels are assigned, we will share a link to self-book any pre/post stays at your hotel, should that be part of your plan. Please do not book your hotel through Egencia. <br />
<br />
====Payment on Check-in====<br />
Everyone will be required to present a form of payment on check-in for incidentals at $50 per day. This is a US hotel standard and we aren't able to waive it (we tried).<br />
<br />
We recommend providing a credit card. You can provide a debit card, but they do put a hold of funds on your card and has been problematic for some international travelers in the past. If you are not able to provide a credit or debit card, email mozilla@shworldwide.com and we'll work with the hotel on accommodating. <br />
<br />
====Pre/post====<br />
Links will be shared after hotels are assigned. <br />
<br />
=='''Travel'''==<br />
Booking instructions have been emailed. Deadline to book travel is October 5.<br />
<br />
====Arriving Early/Departing Late Guidelines====<br />
<br />
Our standard travel guidelines apply (pre-populated in Egencia) when booking with a few additional budget constraints. Anything booked outside of them will require approval. Most people will arrive on Monday, December 11 and leave on Saturday, December 16. Here are some exceptions: <br />
* If you live in a country where work travel is prohibited on weekends, you may travel on Friday, December 8 and Monday, December 18, if you’d prefer (not required). For hotel, you will book and pay on your own, and expense the manager approved amount (which is coded to your cost center).<br />
* If you live in a country where work travel is prohibited on Sunday (ex France), you may travel on Saturday, December 9 and Saturday, December 16, if you’d prefer (not required). You will get your Monday, December 11 and 18 off. For hotel, you will book and pay on your own, and expense the manager approved amount (which is coded to your cost center).<br />
* If you plan to spend some extra personal time in Austin (choosing to arrive before Monday, December 11 or depart after Saturday, December 16), you'll need to create an itinerary in Egencia for standard dates/locations within the Austin Portal and compare to the custom dates you'd like. Please share the difference via email to bmark@mozilla.com or through the approval comment box when you submit the flight. You can sway up to +$100 over and Mozilla will cover it. Otherwise you'll need to come with an alternate itinerary that fits within the pricing (like a round trip in and out of AUS w/ longer dates, and you personally book & cover the rest). We do not have the ability for employees to reimburse Mozilla for any overage.<br />
* If you are attending the Monday Core Influencer's event (by invite).<br />
* If you would like to arrive early to recover from jetlag, you will need manager approval for any additional costs associated with the extension. There is no unilateral "All Hands" approval based upon timezone to arrive early. For hotel, you will book and pay on your own, and expense the manager approved amount (which is coded to your cost center).<br />
<br />
====Booking Family Travel====<br />
Once travel has opened to staff, you may book family, whether they will accompany you on your flight or join us later; and you have two options: Direct or through Egencia. <br />
<br />
If you choose to book family through Egencia, please first book your own flight and then call Egencia with your airline confirmation number (staff do have to go through Egencia). Otherwise, you can book family direct (either through the airline or through another third party) and call the ticketing airline(s) with both confirmation numbers and ask them to link your reservations, so they know you are traveling together. They should also be able to assign seats together. You will avoid the limited hours Egencia offers and avoid paying their ticketing fee. <br />
<br />
If you prefer to book your family through Egencia, you can pay (including the Egencia booking fees) and coordinate with your own travel (recommend to book and then call/email Egencia with your itinerary number to match for family). Note that booking through Egencia does not put you on the same reservation, nor guarantee the reservations will be linked (you would still need to call the airline to link them). <br />
* '''Call:''' +1 (877) 264-1622 or +1 (417) 521-0273; Monday - Friday 9 am - 6 pm EST. If you call outside these hours, you will get an after hours agent, who may not be as helpful. <br />
* '''Email:''' egegrp@expedia.com. The email is monitored Monday - Friday 9 am - 6 pm EST. If you email, you will eventually need to call with a credit card (for fares & fees for family) and personal details of travelers, but the email can get the flights set-up. The agents will need to following information in the initial email to search for flights: Departure City (hometown) & Arrival City (should be AUS), Travel dates & Number of people traveling together + legal names<br />
<br />
====Travel Insurance====<br />
Mozilla provides emergency medical accident and illness cover for all global MoCo & MoFo employees/interns and their dependents. You can view more information on [https://mana.mozilla.org/wiki/display/PR/Travel+Insurance+-+Business Mana]. This coverage begins at the time the you leave home to start your business trip. It also has a provision for a 14 day extension for leisure travel outside of the business travel. If you have additional questions, please email benefits@mozilla.com. <br />
<br />
Mozilla does not cover travel insurance for elancers, upworkers, contractors, vendors, or volunteers/community members.<br />
<br />
=====''Air Travel Fine Print''=====<br />
Change fees will be covered by Mozilla for business reasons only. If you need a change and have manager approval, email bmark@mozilla.com prior to requesting the change with Egencia. Once you have approval, call Egencia to make the change at +1 (702) 939-2530 or +1-877-264-1622 (note this will not be possible without prior approval so be sure to get that by way of an email from your manager to Brianna Mark). If you are changing for personal reasons, the change in airfare, change fee and Egencia fee is your responsibility.<br />
<br />
Mozilla will not reimburse for Business/First class upgrades or tickets. Mozilla Frequent Flyer perks do not apply for All Hands. <br />
<br />
Any submitted expenses needs to have an itinerary attached to ensure it is employee expenses only and within policy.<br />
<br />
=='''Ground Transportation'''==<br />
=====Airport Shuttle=====<br />
All Mozillians and guests who have flights arriving anytime on Monday, December 11th in Austin-Bergstrom International Airport (AUS) and out on Saturday, December 16th, will be transferred to/from the hotels. If you arrive into another airport; or on a different date - ground transportation is on your own.<br />
<br />
'''Arrivals to Austin-Bergstrom International Airport (AUS)'''<br />
<br />
The airport has two terminals, however most people will arrive in Barbara Jordan Terminal. Regional carriers fly into the new South Terminal. <br />
<br />
'''Departures from Austin-Bergstrom International Airport (AUS)'''<br />
<br />
Everyone departing on Saturday, December 16th, will receive transportation to AUS.<br />
<br />
====Alternate Transportation Options====<br />
Options can be found on the [http://www.austintexas.gov/department/ground-transportation AUS website].<br />
<br />
The airport is 7.5 miles or ~15 minutes for the hotels. <br />
<br />
=='''Accessibility'''==<br />
<br />
'''[http://www.marriott.com/hotels/fact-sheet/travel/ausjw-jw-marriott-austin/ JW Marriott Austin]'''<br />
Accessible guest rooms have a 32 inch wide opening, Hotel has on site accessible self-parking, Meeting spaces are all accessible, Pool entrances are all accessible, Restaurants and lounges are all accessible, Self-operating lifts or sloped entry are available for all pools, Fitness center entrance is accessible, Main entrance is accessible, Pathway to registration desk is accessible, Registration desk is accessible, Route to accessible guest rooms is accessible, Service animals allowed for persons with disabilities.<br />
<br />
'''[http://www3.hilton.com/en/hotels/texas/hilton-austin-AUSCVHH/about/amenities.html Hilton Austin]'''<br />
The Following Features Are Available: Accessible Rooms, Accessible business center, Accessible concierge desk, Accessible exercise facility, Accessible guest rooms with mobility features with entry or passage doors that provide 32” of clear width, Accessible hotel restaurant, Accessible parking, Accessible parking spaces for cars in the self-parking facility, Accessible public entrance, Accessible registration desk, Accessible route from the accessible public entrance to the accessible guestrooms, Accessible route from the accessible public entrance to the registration area, Accessible route from the hotel’s accessible entrance to the meeting room/ballroom area, Accessible route from the hotel’s accessible public entrance to at least one restaurant, Accessible route from the hotel’s accessible public entrance to the business center, Accessible route from the hotel’s accessible public entrance to the exercise facilities, Accessible route from the hotel’s accessible public entrance to the spa, Accessible route from the hotel’s accessible public entrance to the swimming pool, Accessible swimming pool, Closed captioning on televisions or closed captioning decoders, Public Areas/Facilities accessible for physically challenged, Service support animals welcome, Swimming pool hoist for pool access, TTY for guest use, Valet only parking and Van-accessible parking in the self-parking facility.<br />
<br />
=='''Immigration'''==<br />
'''Any''' questions on immigration should be sent to immigration@mozilla.com.<br />
<br />
If you are from a country that requires a B-1/B-2 business visitor visa to enter the US, please plan for it early as government processing times constantly change.<br />
<br />
Please visit the following website to learn more about the visa application process and timing for your country: http://travel.state.gov/content/visas/english/visit/visitor.html#overview. Current estimated processing times at the US Embassies and Consulates abroad can be found at: https://travel.state.gov/content/visas/en/general/wait-times.html/<br />
<br />
Some travelers may be eligible to travel to the United States without first applying for a B-1/B-2 visa, if they are eligible for the Visa Waiver Program (VWP or "ESTA"). You are eligible to apply for admission under the Visa Waiver Program (VWP) if you:<br />
<br />
*Intend to enter the United States for 90 days or less for business, pleasure or transit<br />
*Have a valid passport lawfully issued to you by a Visa Waiver Program country: http://www.esta.us/visa_waiver_countries.html<br />
*Have authorization to travel via the Electronic System for Travel Authorization: https://esta.cbp.dhs.gov/<br />
*Arrive via a Visa Waiver Program signatory carrier (all commercial airlines meet this requirement)<br />
*Have a return or onward ticket<br />
*Travel may not terminate in contiguous territory or adjacent islands unless the traveler is a resident of one of those areas<br />
<br />
=====Employee Travel FAQ=====<br />
This [https://mana.mozilla.org/wiki/display/PR/Travel+FAQ FAQ] addresses questions about how to handle security concerns and electronic devices at the border and how to engage with US Customs & Border Protection (CBP). While it specifically focuses on concerns related to travel to the United States, much of this guidance is applicable to travel elsewhere. Mana access required.<br />
<br />
=====Pocket Letter=====<br />
A pocket letter is recommended to keep on hand for those who are entering the United States. It should accompany you whether or not you are required to have a visa to enter. You may request a copy of that letter when you register. Please contact immigration@mozilla.com if you require a specific letter for your visa application or if you have any questions regarding your citizenship, visa capabilities or travel related questions.<br />
<br />
=====ESTA Point of Contact=====<br />
In the ESTA application you need to give a "U.S. Point of Contact Information". <br />
<br />
Please list Casey McGill as your US Point of Contact.<br />
Address: 331 East Evelyn Avenue, Mountain View, CA 94041 Phone: 408.505.3028<br />
<br />
=='''Austin All Hands Expense Policy'''==<br />
1. All "All Hands" Expenses must be submitted on 1 (and only 1) Expense report (e.g. Austin All Hands Expense Report)<br />
<br />
2. It must contain only those expenses relative to the All Hands Event (5-10 days of pre-post activity only)<br />
<br />
3. If your submitted expense report for All Hands is submitted outside these guidelines, it will be rejected and you will be asked to re-submit with only All Hands Expenses<br />
<br />
4. The deadline to submit the Austin All Hands Expense Report is '''December 31, 2017'''.<br />
<br />
5. Expenses related to team events, parking, room service, mini-bar charges, and food/drink costs above the vouched amounts, will not be approved. <br />
<br />
'''The intention of our all hands are to centrally organize a structure that includes:'''<br />
*Meals (two/day + snacks)<br />
*Transportation^<br />
*Accommodations<br />
*Some number of social events<br />
<br />
Due to the nature of the Austin All Hands, employees will be expensing specific meals. The amount that can be expensed will be communicated and expenses submitted can not exceed the approved amounts. Any social events that are not part of our central plan will generally be self-organized and funded by participants. <br />
<br />
=====Cell phone reimbursement policy=====<br />
Cell phone reimbursement must be approved by your manager prior to submitting the expense. Teams will decide for their staff what is appropriate to expense. <br />
<br />
=====Internet reimbursement policy=====<br />
Internet will be provided in all guestrooms and meeting space in all hotels. If you opt to upgrade/add service, those costs are not reimbursable, unless previously approved by your manager and are for business reasons. <br />
<br />
If you have questions about any of this, please reach out to bmark@mozilla.com<br />
<br />
=='''Families/Guests in Austin'''==<br />
<br />
Of course our focus, for the majority of the week, will be on Mozilla. Everyone is expected to be present and engaged each day, during work hours (as your schedule dictates). Please do what you can to make sure your loved ones understand the kind of commitment you’ve made. Family should not join you during your work sessions (other than the more tiny beings) and meals. Please note that what are able to do for families varies by each location. <br />
<br />
====Quick summary logistics====<br />
<br />
'''Air Travel'''<br />
Family travel can be booked/coordinated through Egencia by calling direct; or on your own. Employees do need to book via Egencia regardless of how families are booked.<br />
<br />
'''Hotel'''<br />
They are welcome to stay with you, however, any additional room expenses will be yours to cover. All room rates are based upon single occupancy and costs to add guests vary by hotel. Breakfast is not inlcuded in any of the guest room rates. Hotels will be assigned based upon team and a part of registration. Once hotels are assigned, we will provide a link or contact add guests.<br />
<br />
'''Breakfast'''<br />
Family members who are registered for the event and registered with the hotel are invited to join us for breakfast each morning. Breakfast will be provided on Tuesday, December 12th - Saturday, December 16th.<br />
<br />
'''Lunch & Dinner'''<br />
Family will be on their own for lunch daily and dinner on Tuesday, Wednesday & Thursday. <br />
<br />
'''Friday Night Event'''<br />
Family members who are registered for the event and registered with the hotel, are invited to join us for our Friday night event.<br />
<br />
'''Family Friendly Activities'''<br />
*[https://www.austintexas.org/visit/12-dates-of-christmas/ Trail of Lights] is the biggest event/activity for families and kids in Austin in the month of December, and it’s located in Zilker Park, which is about 1.5 miles from the core of downtown.<br />
*https://www.austintexas.org/visit/top-things-to-do-with-kids-in-austin/<br />
*https://www.austintexas.org/austin-insider-blog/post/9-awesome-things-to-do-in-austins-outdoors-with-the-whole-family/<br />
*https://www.austintexas.org/austin-insider-blog/post/kid-friendly-austin/<br />
*[https://www.sixflags.com/fiestatexas/special-events/holiday-in-the-park Six Flags Fiesta Texas] If you're staying the weekend, you can check out Six Flags in San Antonio. They have a holiday event on both weekends.<br />
*[http://www.pinballzarcade.com/ Pinball] Pinballz is an chain of arcades in Austin with an incredible selection of pinball and video games.<br />
*[https://innerspacecavern.com/ Inner Space Cavern] is located in Georgetown, just north of Austin.<br />
<br />
=='''Extracurricular Activities'''==<br />
Costs for these activities are self-funded and can not be expensed. Feel free to add activities and invite others.</div>Dbaronhttps://wiki.mozilla.org/index.php?title=Travel_Guide&diff=1177955Travel Guide2017-08-10T22:50:26Z<p>Dbaron: /* Preparing to be less-online than normal */ start section, and recommend maps.me for offline OSM</p>
<hr />
<div>----<br />
:: This page was originally created on Mozilla's internal intranet. However, it contains lots of information that could be useful to Mozillians who travel to Mozilla events, or really, anyone who travels, period. Employees can view the history and some corporate-specific info on [https://intranet.mozilla.org/Travel_Guide the original page].<br />
----<br />
<br />
Travel doesn’t have to suck. In fact, there are probably relatively few parts of your life where optimizations can make such a difference. We (the authors) have millions of miles travelled between us.<br />
<br />
* We never lose our luggage.<br />
* We can get from the airport entrance to our gate in 7 minutes.<br />
* We get free booze at the airport, upgraded flights, nicer rooms in hotels.<br />
* We don’t eat crap on the road, indeed we often discover great restaurants.<br />
* We have secrets.<br />
<br />
Let us show you them.<br />
<br />
But first, '''the 3 simplest things you can do to make travel a lot better''':<br />
<br />
# Don’t check luggage<br />
# Check in online<br />
# Pick a Frequent Flyer program<br />
<br />
Do those three and you’re already in the 80th percentile for travel success. What follows below is travel ninjitsu.<br />
<br />
= Listen To Your Fellow Travel Ninja's =<br />
[http://christianheilmann.com/2014/02/16/how-i-save-money-when-traveling-for-work-san-franciscovalleyus/ Christian Heilmann Ninjitsu]<br />
<br />
*Add Your Personal Ninja Tricks Here<br />
<br />
= Planning =<br />
<br />
== Quick Tips ==<br />
* Scan a copy of your passport and any other travel documents, and put them somewhere web accessible but password protected (like Dropbox or Google Drive). This is helpful for getting replacements, and for getting consular help in the meantime.<br />
* Let your credit card company know that you travel. Anti-fraud measures might lock your card the first time you use it on foreign soil, but they can flag your account so that doesn’t happen. This is no fun to discover after the fact.<br />
<br />
== Pick a Frequent Flyer Program ==<br />
<br />
Prices are generally going to be competitive, so figure out your most common trip(s) and figure out which airline/alliance is best for those. Use that group for everything. You can easily sign up for FF programs online, and add it to your travel agency profile (Egencia for Mozilla employees).<br />
<br />
Even if you travel rarely, you'll eventually accrue enough mileage for free travel, and having a FF number makes online check-in easier.<br />
<br />
If you travel often enough, though, (25k+/year on most airlines) you start earning preferred status. This is the difference between "scum" and "Yes sir right away sir." You have shorter lines for agents, shorter lines for security, you board first. You get access to elite lounges while you wait, and free upgrades to business class to make the trip more pleasant. These are little niceties, but they add up, and make travel much nicer. You can often share status with someone less privileged, which means your spouse likes traveling with you more, too.<br />
<br />
== Check In Online ==<br />
<br />
Every airline will let you check in online, usually 24 hours before your flight leaves. I know this will feel weird the first time, but it is an absolute necessity. With online check-in and no checked luggage, you can skip all the lines at the airport except security (and possibly customs/immigration).<br />
<br />
Checking in early may put you into a lower "group" for boarding (or at least not the suckiest, all-the-overhead-bins-are-full group). Check in as early as possible, even if you don't know how many bags you will check (correct answer: 0). You can always add (and pay for) checked bags when you get to the airport.<br />
<br />
The one '''exception''' to this guideline is that if you think your flight might be delayed or cancelled due to weather, ''don't'' check in online ahead of time. If you have to re-book, and you are already checked-in, the agent will have to "uncheck" you, which may slow down the re-booking process and cause you to miss out on alternate flight options. Keep in mind that weather problems cause ripple effects even in locations where weather is good. For example, your flight out of sunny Phoenix might be cancelled because the aircraft is grounded by a snowstorm in Chicago. (See this Egencia blog post for [http://info.egencia.com/wintertraveltips2014.html tips for avoiding weather delays].)<br />
<br />
Online check-in also lets you choose your seats, which brings us to...<br />
<br />
== Choose Your Seats ==<br />
<br />
* Take a window seat for very short flights or very long flights. Window seats have more shoulder room, less hassle from other passengers, and a window. The only downside is bladder management, but on short flights you can stick it out and on long ones you can get up when your fellow passengers do.<br />
* ''Every'' plane has some seats that suck. No recline, noisy, cold, lack of floor storage or slightly narrower than most, [http://www.seatguru.com SeatGuru] will tell you what to avoid. It'll also tell you which seats are great (extra legroom, etc) that you should take given half a chance. Usually, exit-row seats have extra legroom (good for tall people), and the last row and the row in front of the exit row do not recline (bad in general). The first row in a section (where you have a bulkhead in front of you instead of another seat) typically does not have under-seat storage, so everything must go in overhead bins, but it typically does have more legroom. (Seatguru will tell you whether or not this is the case on a particular plane.)<br />
* ''The Middle Seat Gambit'' - If you’re travelling with someone else, check in online together and look for an empty 3-person row. Take the aisle and window. Middle seats fill up last, there’s a decent chance the seat stays empty. If so, you have a lot more space to dump things during the flight, and more legroom since you can use that space instead of putting things under the seat in front of you.<br />
* If you’re traveling alone, you can still use the middle seat gambit by checking in online and looking at the seat map for someone acting as a de facto accomplice.<br />
* If there is only one (worst possible) seat left when you go to select seats, ''don't take it''. It will be claimed by someone else, and the gate agent will assign you a different seat. A flight that full might mean that someone gets bumped, but lack of a seat assignment doesn't guarantee it will be you.<br />
<br />
== Manage Layovers ==<br />
<br />
Flying nonstop to your destination is always easiest, but if that’s not a possibility for whatever reason, here are some other things to keep in mind:<br />
<br />
* Major metropolitan centers are often served by multiple airports, and each airline will have a preference. If you can’t get the flight you want with the airline you like, look to see whether you’re just pointing at the wrong airport.<br />
* If you can’t fly nonstop, you probably at least have your choice of connection airports, and the choice matters there. What’s more, a given airline will have certain preferred connection cities, so a couple trips should get you a reasonably complete list. (For example, connecting from Toronto to San Francisco on Star Alliance, it is much preferable to connect in Denver or Vancouver than it is to connect in Chicago O’Hare.) Consider the immigration/customs procedures of the country you're connecting in if it's separate from the origin or destination (e.g., prefer Vancouver over a US airport for connecting between Toronto and Auckland, since the US requires internationally-connecting passengers to go through immigration and customs).<br />
* If you have to have a connection, you might also have the opportunity to fly to a better airport (e.g., if you have to connect to Washington, DC, you are likely to be able to fly to DCA instead of IAD).<br />
* Take the season and likely weather into account when picking connecting airports; avoid snowy airports in winter, thunderstormy airports in summer.<br />
* If you have to layover overnight, prefer airports that have on-site hotels (and for god’s sake prefer Munich over Frankfurt).<br />
* If you’re crossing a border during your flight, it’s often preferable to layover in-country before crossing over. It means your first flight is domestic, so you can arrive later at the airport since there’s no immigration headache there. <br />
* Another reason not to check a bag is that when you have a connection after arriving in some countries (e.g., the USA, but not EU countries), you have to claim your bag, take it through customs (even though they rarely look at it), and then check it again for your connecting flight. More time and hassle.<br />
* Remember to account for boarding time when calculating layovers. If flight A arrives at 12:00 and flight B leaves at 1:00, you do not have an hour, you have about 20 minutes (because you need to get OFF of flight A once it arrives, transit to whichever gate/terminal flight B is in, and then be there for flight B '''boarding''', not flight B '''departure''').<br />
<br />
= Immigration and Customs =<br />
<br />
== General advice ==<br />
* Make sure you know what the requirements are for crossing all immigration and customs barriers before you do so. If you don't know what those requirements are, embassy or consulate websites are often useful, as are the US government's [http://travel.state.gov/content/passports/english/country.html country specific information] (though somewhat tending towards information useful to Americans).<br />
* Make sure you have any documentation needed in your carry-on luggage. When entering a country where you're not a citizen or resident, you should carry proof of onward travel, particularly if the reservation on which you're flying doesn't return you to your home country (e.g., because you're traveling on separate reservations).<br />
<br />
== Country-specific notes ==<br />
<br />
=== USA ===<br />
* visitors under the [http://travel.state.gov/content/visas/english/visit/visa-waiver-program.html visa waiver program] (those who don't need a visa) must apply online for an [http://www.cbp.gov/travel/international-visitors/esta ESTA].<br />
<br />
=== Canada ===<br />
* visitors who do not need a visa, are entering Canada by air, and are not US citizens or Canadian citizens or Canadian permanent residents, must apply online for an [http://www.cic.gc.ca/english/visit/eta.asp eTA].<br />
<br />
=== Schengen Area (Europe) ===<br />
* The [http://en.wikipedia.org/wiki/Schengen_Area Schengen Area] is an immigration-barrier-free zone covering most of the European Union and some additional non-EU countries, but not the UK or Ireland.<br />
* If you need a visa to visit the Schengen Area, it is easier to get such a visa if your point of arrival in the Schengen Area is the same country as your destination. (For example, if you're traveling to Spain, it is easier to arrive in Madrid after connecting in the UK or US than connecting via Amsterdam, since in the latter case getting the visa requires dealing with both the Spanish and Dutch authorities.)<br />
* If your nationality requires a visa to visit the Schengen Area and your trip does not terminate in Schengen, avoid making more than one connection in Schengen; in such a case you must get a Schengen visa, even though that's not your destination. Schengen immigration authorities look at your ''next'' point of travel (not your final one) to decide whether you need a visa; if it is Schengen, they will ask for one.<br />
<br />
=== New Zealand ===<br />
* Make sure to declare any shoes in your checked luggage. The authorities just want to look at them and maybe clean the dirt off for you, but they'll be upset if you don't declare them.<br />
* Don't even think about [http://www.nzherald.co.nz/nz/news/article.cfm?c_id=1&objectid=11404025 bringing fresh fruit] into New Zealand or you will get an instant fine.<br />
<br />
=== Australia ===<br />
* Visitors who can can enter without a visa must apply online for an [https://www.eta.immi.gov.au/ ETA].<br />
<br />
= Packing =<br />
<br />
'''Quick Tips'''<br />
* Have a toiletry bag that you keep stocked, rather than trying to remember to pack toothbrushes &c the day of. It doesn’t cost much to buy the duplicates once, and saves hassle/forgetting.<br />
* Put your favourite head, stomach, and sleep meds in the toiletry bag. You can buy most things on the road, but meds are sometimes an exception.<br />
* Throw a couple of large ziploc bags in there, too. They are immensely useful for storing wet clothing or leaking bottles or, by contrast, for putting things like passports in when you need them to stay dry. They weigh nothing and disappear into a pocket until needed.<br />
* Layers. You can adapt to a wide range of climates, even multi-city travel, by packing layers. Shirt, Sweater, Hoodie, Jacket is plenty warm, packs much more compactly than a parka, and gives you middle ground for an overwarm restaurant or an overcool office.<br />
* While you're packing, make a text list on your phone of everything you pack. Towards the end of your trip (such as waiting for your flight home), put a '+' next to every item you actually used. Next time, don't pack the things you didn't use. Also, if your bag goes missing, you have a list of what was in it.<br />
<br />
== Don’t Check Luggage ==<br />
<br />
:: Repeat after me: Checked luggage is for chumps.<br />
<br />
:: Again. Checked luggage is for chumps.<br />
<br />
:: -- George Clooney, ''Up in the Air''<br />
<br />
Every time you give your bag to the airlines, you're inviting them to lose it, abuse it, leave it in your departure city, forget about it on the tarmac during a rain delay, etc. North American airlines will allow you one carry on suitcase and one “personal bag” which usually means a purse or laptop. This is easily enough for a week of travel, and can be extended indefinitely with laundry service. Invest in a good carry-on and bring it with you.<br />
<br />
Put everything you need during the flight in your laptop bag, in case you have to gate-check your carry-on suitcase (common on short flights with smaller planes).<br />
<br />
== Choose the Right Luggage ==<br />
Checked luggage will inevitably be destroyed over time, regardless of quality. If you stick to carry on, though, good luggage will last forever; be willing to pay once for something that gets it right. Your happiness while traveling is worth it.<br />
<br />
His bias for non-rolling luggage notwithstanding, [http://www.onebag.com/bags.html this is the single best guide out there] for evaluating luggage. The highlights:<br />
<br />
* Lighter is better<br />
* Curvy designs rob you of packing volume, prefer right angles<br />
* Chain zippers are stronger than coil zippers (look for YKK as the brand of zipper)<br />
* Pocket design and positioning matters<br />
* So do tie-downs<br />
<br />
In truth, the best way to maximize quality while minimizing weight is to let go of the dependence on rolling bags. Soft-sided, non-wheeled bags are exceptionally light and versatile. [http://www.tombihn.com Tom Bihn] and [http://www.redoxx.com/ Red Oxx] are your best plays. Tom Bihn’s Aeronaut is is a full-sized carry-on that converts to a backpack for long walks across cobblestones/sprints to catch a connection/etc. The Red Oxx Air Boss was designed by the same guy who wrote the luggage-choosing guide above.<br />
<br />
If you're not ready to let go of wheeled bags, any manufacturer with a lifetime warranty is probably worth considering. These include:<br />
<br />
* [http://www.briggs-riley.com/ Briggs & Riley]<br />
* [http://www.travelpro.com Travelpro] ("the best" carry-on according to [http://thewirecutter.com/reviews/best-carry-on-luggage/ The Wirecutter])<br />
* Certain models of [http://shop.eaglecreek.com/lightweight-carry-on/l/111 Eagle Creek] (not all models have a lifetime warranty)<br />
<br />
Pay attention to the bag’s extensible arm: is it well constructed? What does it do to your interior space? 2 segments of extension or 3? Moving parts make everything more fragile -- if you are choosing moving parts in your luggage, they need to be brilliant.<br />
<br />
== Buy It There (BIT) ==<br />
<br />
Don’t try to anticipate every contingency and pack for it. You will bog yourself down with unnecessary cruft. Pack for what you ''know'' you’ll need, or at most what you reasonably expect to need the majority of the time. You can find contact solution, toothpaste, aspirin, and dental floss at almost any convenience store. For the rest, shove an extra $50 into a pocket somewhere and buy whatever you need there, if it comes up. <br />
<br />
(Good news: It comes up less often than you’d think.)<br />
<br />
BIT exceptions: <br />
There are some things you don't want to source while traveling - if you only use one specific brand of shampoo, conditioner, etc, transfer it to a small, travel-friendly bottle. Depending on where you're traveling BIT can be tough if you don't speak the language and are looking for something very specific (like Cipro in India or a flat iron in China). Goes without saying, but BIT does *not* apply to medications (remember that what requires a prescription varies by country, but you can apply it if you know that something can be bought without a prescription at your destination).<br />
<br />
=== Corollary: Wash It There ===<br />
If you’re gone for longer than a carry-on can reasonably contain (which is longer than you think), don’t fail over to multiple suitcases; just get things laundered partway through. Your hotel will offer laundry service, though it will be overpriced. Most of the time you’ll find a wash and fold place within walking distance or a service that does pick up and next day drop off.<br />
<br />
Also keep in mind that at most Mozilla or other geek events, you will probably acquire at least one or two t-shirts. You can bring one or two fewer shirts; if this guideline fails, wash one of the ones you brought.<br />
<br />
If you bring quick-drying underwear and socks, you can wash them in the sink or bathtub and dry them overnight on the towel rack (except in humid climates). You can skip bringing detergent by using the hotel's shampoo (as long as you don't mind your underwear smelling like "ginger lemongrass" or whatever); shampoo is just mild detergent. Check the plumbing before you fill the sink; some hotels don't install the lever for raising the plug. Before hanging items to dry, roll them in a towel and squeeze out excess moisture.<br />
<br />
== Counterpoint: The case for checking a suitcase ==<br />
A few heavy-traveling Mozillians are in the "checked bag" camp. Add your reasons for using this strategy here:<br />
* Problems with checked luggage are actually quite rare.<br />
* You don't have to schlep a roll-aboard through the airport with you, including squeezing it into tiny toilet stalls.<br />
* You can pack a few extra things that help you be more comfortable on an extended trip.<br />
* At least one airline (American) gives early boarding privileges (after Elite and Priority but before Zone 1) to passengers with no overhead baggage.<br />
* You aren't limited to 100ml bottles of liquid/gel/cream, and can bring home ''properly packed'' wine, booze, perfume, etc. (Wrap the bottle in at least two plastic bags and nestle it in the groove left by the extending handle, surrounded tightly by clothes.)<br />
* Having airline status often helps your bag appear on the belt faster. Also, if the final segment of your trip is an international arrival in the United States, you're unlikely to have to wait long for your bag, since all baggage goes to the same belt, so it gets there quickly.<br />
* TIP: Get a suitcase with four wheels. Baggage handlers can slide it across the floor of the cargo hold instead of tossing it, subjecting the suitcase and its contents to much less abuse. Anything that protrudes, like carry straps or zipper pulls, can get snagged and chewed up in baggage-handling equipment; go for streamlined.<br />
* TIP: Ask for your checked luggage to be marked "Fragile". It will be loaded on top of other bags, and usually be unloaded first.<br />
* TIP: If you check luggage, don't let your eyes off the bag until there's a tag on it, and if you can, check that the tag is correct (with your name and correct destination airport on it). One of the common reasons for lost/delayed luggage is getting the wrong tag on it right at the check-in desk.<br />
* TIP: Things to make sure are '''not''' in your checked bag: everything you need to get through customs and immigration and get to your final destination. Any electronics that might be stolen. Lithium-ion batteries (prohibited).<br />
<br />
Some airlines (particularly non-North American ones) have much lower limits for what you're allowed to carry on, so you'll have to check luggage anyway.<br />
<br />
Some airlines (e.g., Air France, KLM) will even want to weigh your carry-on bag (often although not reliably), and want it to be a weight that's lower than what it is with your laptop in it (e.g., 6kg, 8kg). Remember that your laptop often counts as a separate personal item and you can take it out of the bag before weighing.<br />
<br />
==Packing Techniques and Tools==<br />
Your strategy for how to put your stuff in your suitcase is very much a matter of personal preference, along with the type of travel you're doing (destination vs. touring) and the type of clothes you bring. Here are some ideas that may be helpful.<br />
<br />
* The [http://www.onebag.com/pack.html bundle method] is great for avoiding wrinkles, but it tends to require that you unbundle ''everything'' to get out any single thing.<br />
* It's extremely helpful to have some kind of containers to organize your stuff. Purpose-made packing "cubes" are great, but are absurdly expensive. You can get by with zip-top plastic bags if you don't travel often, or while you're waiting to find ready-made cubes on sale. <br />
* If you buy only one packing accessory, consider getting a [http://www.amazon.com/Eagle-Creek-Travel-Pack-It-Folder/dp/B002YIRC3O/ packing folder], which helps you fold larger items (shirts, pants, skirts) to a uniform footprint, and then encloses them like an envelope.<br />
* Compression bags, which let you squeeze all the air out of your clothes, are good only for clothes that don't easily wrinkle. However, a compression bag can be great as a laundry bag to minimize the volume of dirty clothes on your way home.<br />
<br />
= Airport Hacking =<br />
'''Quick Tips'''<br />
* ABC: Always Be Charging. Wherever you come to rest, be charging. Maybe your flight has power plugs, that's swell, but maybe they stop working, or your seatmate gets to it first, or you need it to charge your phone. If you're at rest for more than 10 minutes, find a plug. If you bring a power strip so others can plug in, too, you can make friends anywhere :-)<br />
* Watch where uniformed crew members go. They know the best eateries in any given airport, and even where to stand on the tram platform in order to get off quickly at the other end.<br />
* The internet knows about delays before your gate agents do. Bookmark [http://flightaware.com/live/ flightaware] right now, and use it from your phone at the airport to keep tabs. Caveat: Flightaware may show your flight as delayed because the inbound plane you're getting on is delayed; if the airline substitutes another aircraft, your flight could be on time or only a little delayed.<br />
* If you do see signs of a significant delay, particularly at night when it's likely you'll be put off until morning, act swiftly before the lines form. Talk to gate agents about rebooking onto other flights and if the line there is long, be on the phone with your airline as well. First to rebook means first to call hotels and taxis and all the rest. Being last to rebook means sleeping in the airport. If you have elite status, call the customer service number for elite members, not the general customer service number.<br />
* When you get off the plane, the restroom closest to your gate will be crowded with other people from your flight. Keep going to the next one further away.<br />
* No one wants to sleep in an airport, but flight delays or cancellations, or just poor planning, may require it. There is actually a whole website devoted to [http://www.sleepinginairports.net/tips.htm sleeping in airports].<br />
<br />
<br />
== Being prepared for security ==<br />
* Bring identification. [http://www.tsa.gov/traveler-information/acceptable-ids Here's a list of acceptable IDs] in the US. If you forget your ID, all is not lost. It's possible, with some extra hassle, to travel within the US even if you don't have your identification. [http://blog.tsa.gov/2013/04/tsa-travel-tips-tuesday-can-you-fly.html Here's what the TSA says to do if you don't have ID.]<br />
* Avoid getting into a screening line behind people who look like they don't travel often (families with kids, retirement-age folks, large groups).<br />
* Wear slip-on shoes (and wear socks if you don't want your feet getting dirty).<br />
* Consider not wearing a belt, or wear one with no metal, so you don't have to take it off.<br />
* Avoid clothes with extra pockets, like cargo pants. They can be flagged by the nudie-scan, and cause you to get a pat-down. Same for "travel" clothes with hidden pockets; these can be handy while touring, but not while flying. Even a hoodie can win you a pat-down for the hood and kangaroo pocket. <br />
* On the other hand, a jacket with lots of pockets is like an extra carry-on; you have to remove it for security anyway, and you can keep your in-flight necessities (gadgets, etc.) close to hand during your flight.<br />
* Know the drill with liquids, gels, and creams: containers at most 100ml/3oz, in a clear zip-top bag, 1 liter/1 quart size. Have this in an external pocket of your carry-on, ready to pull out and put in a bin. (If you travel often, you might want to get a sturdier bag than the grocery store kind. It must still be clear and zip-top.)<br />
* Avoid large metal jewelry.<br />
* Take everything, but especially metal (keys, coins, etc.), out of your pockets.<br />
* Leave your pocket knives and multitools at home.<br />
* If you're wearing an activity monitor, such as a FitBit, take it off for screening.<br />
* You should hang onto your ID and boarding pass as you go through the line, but you can't carry them through screening; put them in your bin.<br />
* Put the bin with your shoes, jacket, and liquids onto the conveyor belt first. You can be getting dressed while the rest of your stuff comes through.<br />
* Take your laptop out of your bag and put it in a separate bin. You can usually leave it in a sleeve, as long as there's nothing else in the sleeve. <br />
* Consider getting a checkpoint-friendly laptop bag, with a laptop-only section that folds out without taking out the computer. The less you handle your laptop, the less likely you are to drop it. (US TSA allows you leave the computer in this type of bag; other countries often do not.)<br />
* Don't go through the screening machine until your stuff is on the conveyor belt.<br />
<br />
== US Trusted Traveler Programs ==<br />
If you frequently cross US borders, you can save time and hassle in the long run by enrolling in one of the programs that provide expedited entry for pre-approved travelers. Enrolling involves an application fee and form, and an in-person interview at an entry point, so there is a start-up cost in time and money. Which program you should enroll in depends on the type of crossing you do most; you can enroll in more than one. <br />
<br />
* When entering the US, if you're not in a "trusted traveler" program, try to get into the immigration queue that is ''next to'' the Global Entry lane. If no one is in the Global Entry lane, the officer there will often take people from the nearby queue, making it move faster. Do likewise for NEXUS when entering Canada.<br />
* Wear Firefox gear when going through immigration, anywhere. It creates goodwill and starts pleasant conversations.<br />
<br />
===Automated Passport Control===<br />
Automated Passport Control kiosks are available to citizens of the US, Canada, and [http://www.cbp.gov/travel/international-visitors/frequently-asked-questions-about-visa-waiver-program-vwp-and-electronic-system-travel Visa Waiver Program] countries, for entry into the US, in an expanding number of North American cities. Unlike Global Entry or Nexus, these kiosks require no pre-registration. You swipe your passport, let the kiosk take a photo, answer some questions, and then get a receipt that you show to a Customs and Border Patrol officer. The kiosk replaces filling out a customs card by hand.<br />
<br />
See the [http://www.cbp.gov/travel/us-citizens/Automated%20Passport%20Control Automated Passport Control] webpage for a list of cities with APC kiosks.<br />
<br />
=== Global Entry ===<br />
[http://globalentry.gov/about.html Global Entry] provides expedited screening for entry ''into'' the US at certain airports. Once in the program, you can go to an automated kiosk instead of an immigration agent (skipping the enormous lines that result from multiple international flights arriving at about the same time), and you can answer the customs questions at the kiosk instead of filling out a paper form. Unless there is an issue with your kiosk interaction (such as it couldn't read your fingerprints), you don't need to talk to a CBP agent. Global Entry is open to U.S. citizens, lawful permanent residents of the U.S., Dutch citizens, South Korean citizens and Mexican nationals.<br />
<br />
=== NEXUS ===<br />
[http://www.globalentry.gov/nexus.html NEXUS] provides expedited screening for crossing the US-Canada border in both directions. It can be used at land and sea entry points as well as at airports. You can use the NEXUS-only lanes at land crossings only if every person in the vehicle (including children) has a NEXUS card. Using NEXUS at an airport requires scanning your irises. If you wear contact lenses, you must remove them for the initial iris scan that is taken after your enrollment interview.<br />
<br />
=== Other US programs ===<br />
* [http://www.globalentry.gov/netherlands.html FLUX] expedites passage between the US and '''the Netherlands''', and is open to US and Dutch citizens.<br />
* Global Entry members can receive expedited entry into '''[http://www.globalentry.gov/newzealand.html New Zealand]'''.<br />
* [http://www.globalentry.gov/sentri.html SENTRI] provides expedited entry into the US from '''Mexico''' at specific land crossings.<br />
* [http://www.globalentry.gov/korea.html Smart Entry Service] provides expedited entry into the Republic of '''Korea'''. It is open to US and Korean citizens.<br />
* [http://www.globalentry.gov/smartgate.html SmartGate] provides streamlined entry into '''Australia''' for US Global Entry members. Visa requirements still apply.<br />
* [http://www.globalentry.gov/tsa.html TSA PreCheck] enables US Global Entry and Canadian NEXUS members to use designated TSA airport screening lanes, without removing liquids, laptops, shoes, jackets, or belts. You must provide your membership number when booking flights with participating airlines. TSA is expanding the PreCheck program to include more people, including US military members and those invited by their airline's frequent flyer program. You must still apply, pay a fee, and go through an interview. See the [http://www.tsa.gov/tsa-precheck TSA PreCheck] website for details.<br />
<br />
== Other countries' traveler programs ==<br />
* The UK's [https://www.gov.uk/registered-traveller Registered Traveller service] enables certain citizens of Australia, Canada, Japan, New Zealand and the USA to get faster entry to the UK, without filling out a landing card. <br />
<br />
<br />
Still to write:<br />
* priority security lanes<br />
* being nice to security<br />
* priority boarding (travel with a colleague who has priority status as their guest if you don't have it yourself)<br />
* lounges<br />
* watch your crew<br />
<br />
= Flying =<br />
<br />
'''Quick Tips'''<br />
* Hydrate, hydrate, hydrate. Air in an airplane at altitude is incredibly dry and dries you out. Drink water whenever you can. Bring an empty water bottle (even better: collapsible) and fill it from a water fountain inside security. (Some airports, like SFO, have water bottle filling spots that make this a little easier.) Don't drink the water that comes out of the water tanks onboard an airplane, including coffee and tea; you don't want to know how disgusting those tanks are. If you get water in the beverage service, ask for fizzy water (club soda) to ensure it came out of a bottle or can. If you need to brush your teeth in-flight, use water from your water bottle, not the tap in the toilet.<br />
* Request an alternate meal (kosher, indian, vegan, whatever) - they tend to be tastier, and often come first. (However, the downside to the meal coming first is that the tray is going to be in your way substantially longer.)<br />
* If you're in an aisle seat, you’ll find that the aisle-side armrest won’t lift. This is annoying, because it is much easier to deplane with that thing out of the way. Reach back to where the armrest joins the back of the chair -- there may be a release latch or button. (This works on some Boeing 777s; most smaller craft do not have this feature. See [http://brokensecrets.com/2011/01/17/raising-the-airplane-aisle-armrest/ this article] for a photo.)<br />
* Always wear shoes before going to the airplane lavatories; never go barefoot or wearing socks only. <br />
<br />
== Headphones ==<br />
Enjoying music or movies during travel is much better with headphones designed for travel use. You need to consider three types: <br />
* active noise-cancelling headphones<br />
* those without noise-cancellation<br />
* in-ear monitors. <br />
Generally speaking, on airplanes, active noise-cancellation will be better on the plane but worse when you're not on the plane (in the hotel room, for instance.) A quality headphone without noise cancellation will almost always sound better when not on an airplane. In-ear monitors allow for excellent sound quality and also allow one to rest your head on a pillow without the headphone pushing against one's ear, but some are uncomfortable with putting anything in one's ear. In-ear monitors are also much more compact. For those who want the sound quality of in-ear monitors and the compactness, but find that fit is a problem, consider Comply foam tip replacements which can be selected to fit your ear size.<br />
<br />
* For active noise cancellation headphones, the Bose Quiet Comfort 15 is the most popular model sold and for good reason. However if you want the headphone to be good when the noise-cancellation is turned off, you may want to consider the [http://www.psbspeakers.com/products/headphones/M4U-2-Headphones Psb m4u 2], which is more expensive but also more versatile.<br />
* For headphones without active noise cancellation, consider rugged models that have reputations burnished by decades of use by audio professionals such as the Sennheiser HD-25 1-ii. Another popular option is the V-Moda M-80 which has similar sound quality, has a good reputation for build quality, and also comes with a nice travel case.<br />
* For in ear monitors, there are too many to list but one line that is very popular is the Shure SE series which have models from $99 on up. These are very rugged models which allow for replaceable cables, replaceable tips and have very good sound quality.<br />
Additional resources for headphones include [http://www.innerfidelity.com/content/innerfidelitys-wall-fame Innerfidelity's Wall of Fame] and Head-fi.org's [http://www.head-fi.org/t/618255/check-out-the-head-fi-summer-2012-buying-guide 2012 Summer Buying Guide].<br />
<br />
== Make friends with TSA and your flight crew ==<br />
<br />
Airplanes are a sea of grumpy, tired, unhappy people. A little friendliness goes a long way -- especially if you're regularly flying the same route with the same flight crew.<br />
<br />
== Seat etiquette ==<br />
The following tips are about showing consideration to your fellow passengers, who unfortunately may not even notice it. But violating these norms is likely to cause annoyance. You don't want to be "that guy", do you?<br />
<br />
* The person in the middle seats gets to use both armrests. The people in the window and aisle seats get a little extra space, so yielding one armrest each is the least they can do. In any case, try to keep your elbows in your own space.<br />
* Consider the person behind you before reclining your seat into their space, especially if they are trying to eat or use a laptop. Avoid reclining abruptly (though it's not always possible to control this). Raise your seat back during meals.<br />
* If you need to leave your seat during the flight, try to avoid hoisting yourself up by yanking on the seat in front of you. This may be difficult to avoid if the seat is reclined (see above).<br />
* If you have an individual touchscreen in the seat back in front of you, jabbing it forcefully doesn't make the touchscreen work any better. If it's really not responding to touch input, try controlling it from the armrest controls.<br />
<br />
* [http://www.independenttraveler.com/travel-tips/travelers-ed/the-etiquette-of-seat-backs-and-elbow-room The Independent Traveler: The etiquette of seat backs and elbow room]<br />
<br />
<br />
<br />
Still to write:<br />
* how to sleep (Needs to be written by someone who is actually able to sleep on planes)<br />
** [http://gizmodo.com/how-to-get-the-best-sleep-of-your-life-on-an-airplane-1598708044 Gizmodo: How to get the best sleep of your life on an airplane]<br />
** [http://www.independenttraveler.com/travel-tips/travelers-ed/sleeping-on-planes Independent Traveler: Sleeping on Planes]<br />
* move on long flights<br />
<br />
= Tips for specific airports =<br />
As a general rule of thumb, in any airport, the terminal or concourse that serves international flights has nicer shops and restaurants than the areas for domestic flights. So, if you're traveling domestically, have time to kill, and can get into the international terminal without going through passport control, you might want to go hang out there.<br />
<br />
== AMS Amsterdam ==<br />
* in the international section (only?), there are nice quiet places to sit on the upper level outside the lounges (even if you don't have lounge access)<br />
* if you want to take the train to/from the airport, hoard coins (€4 to Amsterdam-Centraal, less to Amsterdam-Lelylaan or Amsterdam Zuid), since the ticket machines don't take bills or American credit cards. (The city trams/buses in Amsterdam do take bills, but this is a national train.)<br />
* note that the entirety of the outside-[https://en.wikipedia.org/wiki/Schengen_Area Schengen]-immigration part of the airport does security at the gate, per flight<br />
<br />
== AUS Austin, Texas ==<br />
The food available in the airport is actually pretty good, since most of the food concessions offer menus from local restaurants. Get to the airport early enough to have a last plate of barbecue or breakfast tacos. <br />
<br />
Another reason to get to the airport early is the "Knot Anymore" chair massages available near gates 13 and 7. Austin is awash in good massage therapists, so the ones working in the airport are far better than most airport massage services.<br />
<br />
== CDG Paris / Charles de Gaulle ==<br />
* CDG airport has multiple airport hotels on premises (on the around-the-airport CDGVal shuttle train); typically at least one of the fancy ones has good prices because it isn't hosting a conference that week, but there's also an Ibis. <br />
* CDG airport has four disconnected parts:<br />
** Terminal 1 (the cylinder with pods) (United is here)<br />
** Terminal 3 (the discount airlines)<br />
** Terminal 2A-2B-2C-2D-2E-2F (the bulk of the airport) (Air France is here)<br />
*** note that there are two satellite piers attached by train (outside immigration but not inside security) attached to Terminal 2E (the attached part of terminal 2E is called K, the satellites are called L and M)<br />
** Terminal 2G<br />
* transport<br />
** there's a train (CDGVal) connecting Terminal 1, Terminal 3 / Roissypole (where most but not all of the hotels are), and Terminal 2 (the station is between 2C/2D/2E/2F)<br />
** high speed trains stop only at the terminal 2 station (between 2C/2D/2E/2F)<br />
** RER trains (Paris's suburban rail network) stop at Terminal 2 (same station, again) and at "Terminal 1" (which is actually the Terminal 3 / Roissypole station for CDGVal)<br />
** Terminal 2G is reachable only by shuttle (I think, never done it)<br />
** If you want to take the RER to/from the airport, hoard coins in advance to pay the €9.50, since foreign cards don't work, and the machines don't take bills. <br />
** The RoissyBus is only €10.50 and runs nonstop between CDG and the Paris Opera, only a few blocks from the Mozilla Paris office. Look for signs for "RoissyBus" or "Paris by bus" within each terminal to find the bus stop.<br />
<br />
== JFK New York ==<br />
* The wifi password of the British Airways' lounge is "London" (according to Reddit). You can usually get in range of the wifi hotspot without going inside the lounge.<br />
<br />
== LHR London Heathrow ==<br />
* Terminal 5 (international) <br />
** If you need to take the train to concourse B or C, go to the far end of the platform. You'll bypass the crowds at the near end, and be closest to the escalators when you exit.<br />
** If you need to backtrack from concourses B or C to concourse A, ''don't'' take the train; you'll be routed through security again. There's a pedestrian tunnel that parallels the train, and comes out next to elevators that let out inside security in concourse A. The tunnel doors are marked "Emergency Exit", but do not have alarms, and in fact open automatically, to accommodate mobility-assistance carts. Stay to the left (remember: you're in England) to keep from being run over by them.<br />
* The Piccadilly Line runs directly from Heathrow to Leicester Square (where Mozilla's office is). If you're going to near the office, it's only barely longer total transit time as the Heathrow Express (since it's direct), and a lot cheaper and easier. See [[London#Finding the Space]].<br />
<br />
== NCE Nice, France ==<br />
* if you have a really early flight, there are multiple decent airport hotels nearby. But do '''not''', under any circumstances, stay at the Etap.<br />
* if you want to avoid a really early flight, consider as an alternative doing an overnight layover at CDG, which has multiple airport hotels walking distance from Terminal 1 (but poorly signed). Make sure your layover is long enough, though.<br />
* if you're traveling to west of the airport (e.g., towards W3C's European offices near Antibes) and want to take public transit, it's possible to walk to the Nice - St. Augustin train station ('''not''' the main Nice - Ville train station) in about 15-20 minutes, but there's basically no signage. But definitely look at the train schedules before trying this. Buses from the bus station (gare routière) at the airport may be better.<br />
* there's a free shuttle between Terminals 1 and 2. Don't try walking between terminals.<br />
* There are bus stations at both terminals, but some bus routes stop at both terminal and some stop only at Terminal 1. You need to buy a ticket at the station before boarding.<br />
* the airport does not have water fountains behind security. But restaurants will probably be willing to fill up a water bottle for you, especially if you've bought something there.<br />
<br />
== NRT Tokyo/Narita ==<br />
* If you can do so just as easily, fly to Haneda Airport (HND) instead, which is closer to the city.<br />
* Don't even ''think'' of taking a taxi. It will take hours, and cost multiple hundreds of US dollars.<br />
* Two companies (JR and Keisei) run trains to Tokyo, and both have express and local services at different prices. Choices depend on where in Tokyo you're going. Google Maps might be helpful, or just figure it out when you get there.<br />
* Consider taking a [http://www.limousinebus.co.jp/en/ Limousine Bus] to somewhere close to your destination, and take a taxi from there.<br />
<br />
== ORD Chicago O'Hare ==<br />
* In Terminal 3, at the beginning of concourse G, there is a "Chicago Urban Garden" on the second floor, with aeroponic herbs and vegetables. This is a nice quiet place to wait if you don't have access to an airline lounge. <br />
<br />
== SFO San Francisco ==<br />
* if you're through security and looking for food, realize that some pairs of terminals are connected behind security. In particular, there are four separated behind-security zones at SFO right now: International-G/Terminal3-F/Terminal3-E, Terminal2-D/Terminal1-C, Terminal1-B, and International-A. In particular, if you're in C, you can probably find better food and better places to sit in D, and at some hours there's not much open in G, but you can head over to F.<br />
* The recently renovated terminal areas are the International Terminal (2000), Terminal 2 (gates D) (2011), and Terminal 3 gates E only (2014)<br />
* If you're taking BART to the airport, you can take the airtrain or walk to get around the airport from the airport BART station. You should definitely walk to International (G or A, which share a large central checkin hall but have separate gate areas), maybe walk to Terminal 3 (at least if you're ready to go straight to the security line), and you can walk to the other terminal if you like.<br />
<br />
== SJC San Jose CA ==<br />
<br />
== TPE Taipei Taoyuan ==<br />
* if you're coming from within Asia to Taipei, fly to Songshan Airport (TSA) instead<br />
* if you have Star Alliance gold, there are multiple EVA lounges to choose from. The main one, with all the good food, is on the same side of the open (to the floor below) space as the tropical bar one, with entrance across the hallway from it (not across the open space)<br />
<br />
= Hotels =<br />
<br />
'''Quick Tips'''<br />
* Ask for upgrades. I know, this sounds trite, but it works. If you don’t know how that works, just remember, when checking in, to ask “Is there a better room available?” If they say yes, you’re set. If they say no, that’s fine. If they say “yes, for a price” then you can consider that price and make the call. We’ve gotten $2000/night rooms on a $180/night booking just by asking. This tends to work well when the hotel has a lot of open inventory (particularly effective in LAS, less effective near Moscone during a conference).<br />
* When checking in, adjust your interactions with the clerk based on whether they smile when you approach. Chit-chat with a smiling clerk, but not with an unsmiling clerk. The latter is just as much a form of establishing rapport as chit-chat, because you're not wasting the time of a transaction-oriented person. And establishing rapport can make the marginal difference in whether they decide to give you an upgrade.<br />
* Expensive hotels tend to have sensors in the minibars, but most of the rest still just have housekeeping track what’s missing each visit and bill you. If you do get the munchies, just head out to a convenience store the next day before housekeeping and buy matching replacements at the saner price. <br />
* You can avoid the minibar entirely by grabbing a granola bar or two from a Mozilla kitchen before departing. They are bound to be healthier than anything you find in the minibar late night. <br />
* Every hotel has a bucket of standard toiletry items (toothbrush, razor, &c). You should have a toiletry bag stocked and ready to go (see above) but if you find yourself missing something, just call the front desk.<br />
* Likewise, every hotel has a bucket of left-behind chargers/power cables.<br />
* Set your climate controls when you first get into the room. Forgetting until you come back after dinner ready for sleep and finding the room is hot and stale is no fun.<br />
* Some hotels won’t let the climate controls work unless your room keycard is stuck into a switch by the door. This isn’t a magstripe reader, it’s just a physical switch - use a business card or a folded up piece of paper (or your library card) and have your room the way you want it.<br />
* If the drapes that don't quite meet, and therefore let in unwanted sunlight or street light, use one or two big binder clips to keep the drapes closed.<br />
* You can usually get a later check-out time just by asking. This doesn't work indefinitely, but they can't clean every room at once, so asking for 1pm instead of 11am just means they move your room to the bottom of the list for cleaning that day.<br />
* Repack for departure before you go to sleep, except for the clothes and toiletries you'll need in the morning. That way, if you oversleep for whatever reason, you can throw on your clothes, grab those last items, and go without wasting any more time.<br />
* To avoid leaving things behind:<br />
** Bring your original packing checklist, and use it to repack.<br />
** Pull all the linens off the bed and throw all used towels into the shower, so you're sure nothing's hidden, and check every wall socket for chargers.<br />
** If you unpack into drawers, check every drawer before you leave.<br />
<br />
== Pick a hotel, get into the frequent guest program ==<br />
<br />
Same deal as airlines. At the least, it eventually adds up to free stays, but getting to status means room upgrades, easier check-in, more flexibility on check-in/check-out times, and extra points for each stay. Some hotel loyalty points can also be transferred to airline loyalty programs.<br />
<br />
It can be harder to consistently stay with the same hotel group than to consistently fly the same airline (they're sold out or not convenient, the conference hotel is elsewhere, etc.). However, it's good to join the loyalty program for any hotel you stay at, before you make your reservation. You may get a better rate or a better room. Hotel staff seem to give an extra measure of courtesy and consideration when you're in the loyalty program. (When booking by phone, I've had a "sold out" group rate suddenly become available when I gave my membership number.) If you haven't joined by the time you check in, ask the clerk to sign you up; they'll get credit for signing you up, and will be even more inclined to treat you nicely.<br />
<br />
Linked below are the programs associated with the hotels that are typically used for visiting Mozilla in Mountain View.<br />
<br />
{|<br />
|-<br />
|Holiday Inn Express<br />
|[http://www.priorityclub.com/ Priority Club]<br />
|<br />
|-<br />
|Avante/Wild Palms<br />
|[http://www.joyoflifeclub.com/ Joy of Life Club]<br />
|(Does not give points for stays that are paid through corporate billing.)<br />
|}<br />
<br />
== Choose Your Room ==<br />
<br />
It's a good practice to indicate that you have any preference on your room at all. Put this into your loyalty program profile and your travel agency profile (Egencia, for Mozilla employees), so it's transmitted with your reservation. If you have no preference, they will put you in the room for people who do not indicate a preference. You know, the one in the basement. With the leaky faucet and carpet from 1973. <br />
<br />
If you have a choice between one or two beds, choose two, even though you'll only use one for sleeping. The other one makes a great surface for spreading out your stuff. Often, hotel beds are on casters, so you can shove the extra bed against the wall, to prevent stuff falling between the bed and the wall.<br />
<br />
Generally, you'll do well to ask for a high floor and a room away from the elevator. Many hotels do renovations by floor starting from the top and working their way down. So high floors have a better chance of being recently renovated. They are also further away from street noise or the bar in the atrium. A room away from the elevator means less foot traffic and not waking up at 5am to repeated "ding!" of the elevator door opening. For motels, you want upstairs (less foot traffic) and outside (away from the courtyard with the pool).<br />
<br />
If the room is awful, don't be afraid to walk back downstairs and see if they have anything a bit more updated. If the whole hotel is awful, check your luggage at the desk and walk in a square block radius around the hotel to see if there's something less frightening. <br />
<br />
Never pick a hotel based on a picture of the lobby. Lobbies are always the first thing to get renovated.<br />
<br />
== Tipping Hotel Staff ==<br />
If you believe in tipping (which varies across cultures):<br />
* If you take a hotel shuttle from the airport, be sure to tip the shuttle driver. Don't just hand it to them and walk away; look them in the eye and express genuine appreciation for their service while you give them the tip. This is your first contact with the hotel staff, and if you make a good impression, word will spread to the other staff, and you'll get great service throughout your stay. This driver may also be the person who gets you to your outbound flight, through heavy traffic, just in the nick of time.<br />
* Similarly, leave a tip for housekeeping after the first night. This paves the way for good service when you make special requests, such as extra towels or toiletries, or to come back later because you're still in the room. Leave the money on top of a note that says at least "Thanks!" so the housekeeper knows it's for them.<br />
<br />
= Money =<br />
<br />
* Exchange: Do not change money at the airport. The rates are higher there than anywhere else. If you have a local bureau de change, use that, or order currency online for pickup at the airport. If you can find a company that does that (Travelex in the UK, at least) the rates will be much better than those posted on the wall that they charge you when you are a captive customer.<br />
* Debit: Using an ATM card can be an easy and inexpensive way to secure some local currency. Make sure your card will work abroad before you travel. Common ATM networks that are broadly available include Pulse and Plus. Consider getting a debit card with no foreign transaction fees (Charles Schwab offers one).<br />
* Stay organized: It's helpful to keep your currency separate from your home currency, particularly if you're going to cycle through multiple currencies during your trip (usd > euro > pounds). Don't underestimate the power of a ziploc baggie if you're American and unaccustomed to coinage-heavy currencies.<br />
<br />
== Credit cards ==<br />
The US uses a different system (magnetic strips) for credit card security from the rest of the world (which uses the chip-and-pin system). This can cause headaches for both Americans traveling abroad, and others traveling to the US, as the systems are incompatible.<br />
<br />
* A very few US banks offer chip-and-pin cards, including Citibank and [https://www.andrewsfcu.org/credit_cards_and_loans/credit_cards/globetrek_rewards.html Andrews Federal Credit Union]. The latter also has no annual fee and no international transaction fees. See this extensive but not exhaustive [http://thepointsguy.com/2013/05/us-credit-cards-with-smart-chips/ list of US-based chip-and-pin cards]. <br />
* You can get a pre-paid, reloadable chip-and-pin card called [http://www.cashpassport.com/1/travelex/ "Cash Passport"] from Travelex. You can buy it and reload it online or at Travelex locations in the US. You can load it in multiple currencies: GBP, EUR, CAD, AUD and JPY. The security seems a bit crappy (you can't change the PIN, and their only security question is mother's maiden name), but since it's pre-paid, you can limit your financial exposure, and reload online as needed.<br />
<br />
Another issue for travelers is transaction fees when making purchases in currencies other than your home currency; these can range from 1% up to as much as 7%. US-based credit cards that don't charge international transaction fees include CapitalOne and Andrews FCU.<br />
<br />
More and more US retailers have card readers that accept chip-based cards, so the situation is improving for visitors to the US. However, they probably don't understand the PIN system, so you will still need to sign (either on the reader, or on paper).<br />
<br />
= Preparing to be less-online than normal =<br />
<br />
If your cellphone plan doesn't have reasonable data roaming, or if you might be in areas with poor cell coverage, you should be prepared to survive without your usual data connection. This might include things like:<br />
* downloading offline maps in advance. ([http://maps.me/ maps.me] for Android and iOS lets you download offline OpenStreetMap maps by country or part-of-country.)<br />
* knowing where you're going to need to be (hotels, meeting locations) before you leave<br />
<br />
= On Foreign Soil =<br />
<br />
* Data/Voice rates<br />
** You can use Skype to call US 1-800 numbers toll free from anywhere in the world.<br />
** Before you leave your home country, add $20-40 of SkypeOut credits to your account. While Skype to Skype calls are free, SkypeOut credits will let you call any number internationally for about $.02 per minute.<br />
** International text messages are typically NOT covered under your mobile plan. For US cell plans, it's usually about $.50 per SMS. If you have a good international rate, think long and hard about when you use SMS and why. A conversation about when you landed and where to meet and what time to get there on SMS may be more than a 2 minute call that covers the same details.<br />
** [http://readwrite.com/2014/06/17/5-secrets-avoiding-hefty-international-data-roaming-charges-fees 5 secrets to avoiding hefty international data roaming fees] <br />
* Finding wifi<br />
** In airports, airlines' priority lounges often have no wifi password, and you can access their hotspots from outside the lounge. (See note above for JFK airport.)<br />
** Starbucks, McDonalds, and Burger King are sadly ubiquitous, and often have free wifi.<br />
** You can sometimes find the password for a business's wifi in the comments for that business on FourSquare.<br />
* Language barriers<br />
** Grab some business cards or stationery with your hotel's address on them before you head out. You can hand one to a cabbie whose language you do not speak, to get yourself back to home base. <br />
<br />
Still to write/update:<br />
* Language barriers<br />
** Add Line2 details...<br />
<br />
==Coping with jet lag==<br />
* Do not go to sleep. Do not nap. Stay up as long as you possibly can. Eat meals at local times and get into bed when it's dark outside. It will hurt on day one but by day three, you'll be glad you did. <br />
* If you absolutely must sleep, do a 20 minute powernap and then get up, walk around, and do not fall back to sleep. (Powernapping pro tip: drink a cup of coffee, and ''then'' take a nap; the coffee will wake you up in a short while.) <br />
* In a pinch, Benedryl (dipenhydramine) can help you reset your internal clock and it's substantially gentler on your system than the prescription sleep aids. (It's also good for nausea if you get motion sickness, and of course, allergic reactions.)<br />
* If you find yourself awake when you should be sleeping (by local time), avoid bright screens (computers, phones, e-readers), because they activate wakefulness in your brain. Try reading a paper book or magazine (radical, I know). If you must use a screen, set it to white text on a black background, to reduce the overall brightness; or get an app (such as [https://justgetflux.com/ f.lux] for Mac/iOS or [https://play.google.com/store/apps/details?id=com.urbandroid.lux Twilight] for Android) that reduces the amount of blue light emitted by your device at night.<br />
* If possible, follow the [http://www.wikihow.com/Prevent-Jet-Lag-with-a-Modified-Diet Anti-Jet Lag Diet]; this is easier to do at home than while traveling, but IME even an approximation helps. <br />
** As an abbreviated version: eat as little as possible on your day of travel, avoiding caffeine and alcohol; eat a high-protein breakfast at breakfast time in your new time zone.<br />
** Bring protein bars with you to ensure that you can get protein at the right time.<br />
<br />
= Transportation =<br />
<br />
'''Quick Tips'''<br />
* Talk to cabbies. Not only do they know their city, they are less likely to have kickbacks in place than the hotel concierge, more likely to give you good answers.<br />
* Learn the taxi rules. Las Vegas doesn’t let you hail cabs on the street (creates traffic problems). New York cabs have credit card swipes in the back seat, whereas DC cabs just started actually using their meters at all. San Francisco cabs won’t let you exit except curbside.<br />
<br />
Still to write:<br />
* public transit<br />
* hotel shuttles<br />
<br />
== Rental Cars ==<br />
<br />
=== Enterprise Rent-a-Car ===<br />
<br />
Mozilla's preferred vendor<br />
<br />
=== Hertz ===<br />
<br />
If for some reason you end up with Hertz (late evening arrivals mean Enterprise might be closed) you'll want to sign up for [[HertzBusinessAccountProgram|Hertz #1 Gold]] and use that. At most airports, you walk in, your name is on a board with a parking spot number, and the keys and contract are already in the car waiting for you. Really nice after a 5+ hour flight!<br />
<br />
= Eating =<br />
<br />
Eat like a local.<br />
<br />
Never ask the front desk at your hotel for a dinner recommendation. If possible, ask anyone else to weigh in. The bellhop, your taxi driver, the barista at Starbucks, Yelp, Chowhound, etc. The best recommendations come from people who are actually living and working in the area. The concierge at the hotel will always orient toward broad, tourist-pacifying tastes. The food will be edible, but forgettable. They'll never tell you about the super tasty hole-in-the-wall joint three blocks away.<br />
<br />
= Staying healthy =<br />
* Wash hands frequently! <br />
* Carry and use hand-sanitizer wipes. (A bottle of hand-sanitizer gel takes up valuable room in your liquids bag.) Sanitize your hands in-flight before you eat or drink, and after washing your hands in the lavatory (on-board water, again). Also use them to wipe off [http://www.travelmath.com/feature/airline-hygiene-exposed/ tray tables, seatbelt buckles, and air vents], where germs lurk on airplanes.<br />
* Set the fan above your seat on the plane to low or medium, and position it to blow into your lap, just in front of your face. This will help knock airborne pathogens out of the air, so you'll be less likely to breathe them in. ([http://www.npr.org/blogs/goatsandsoda/2014/07/14/319194689/pathogens-on-a-plane-how-to-stay-healthy-in-flight?ft=1 (NPR) Pathogens on a plane: how to stay healthy in flight])<br />
* Keep your exercise routine as much as possible. Exercise burns calories, relieves stress, and helps reset your body clock, if you're in a different time zone.<br />
** Pick a hotel that has a fitness center. If you must use a hotel that doesn't have one (or you need specific equipment, like a stationary bike) call and ask; they may have an arrangement with a nearby gym.<br />
** If you're out of luck on the fitness center, bring an exercise DVD, and/or small lightweight equipment like a jump rope or tension bands. Or do a [http://well.blogs.nytimes.com/2013/05/09/the-scientific-7-minute-workout/ body-weight-only exercise routine].<br />
** Bring quick-drying workout clothes. Rinse them in the shower, and dry them over the shower rod, so they're ready for tomorrow.<br />
** Bring athletic shoes that double as casual street shoes, so you don't need to take up luggage space with extra shoes.<br />
** See the Quartz [http://qz.com/287800/the-complete-guide-to-staying-in-shape-on-the-road/ Complete guide to staying in shape on the road].<br />
<br />
= Redux =<br />
<br />
'''Most people travel infrequently, and aren’t very skilled at it...'''<br />
* and there are a lot of people, so despite the infrequency of their travel, the Don’t Know path is very crowded<br />
* Businesses on the Don’t Know path have no loyalty to you (since infrequent travellers have no meaningful loyalty to them) so their main goal is to extract money from you immediately, even at the cost of the relationship<br />
* People on the Don’t Know path have to deal with the same Don’t Know problems every single day, which is exhausting and saps their empathy<br />
<br />
'''BUT - If you know what you’re doing...'''<br />
* You can shortcut around the Don’t Know path everywhere. Airports, Hotels, Restaurants<br />
* The businesses you deal with will view you as a regular, and want to keep you happy<br />
* The people you deal with will view you as a breath of fresh air, and feel understood, and be grateful and human in the ways that travel never is for others.<br />
<br />
= More advice =<br />
* [http://www.jonobacon.org/2016/08/10/the-bacon-travel-survival-guide/ Travel Survival Guide] by Jono Bacon<br />
These podcasts have some excellent advice on business travel:<br />
* [http://www.manager-tools.com/2009/07/airline-travel-basics-1-part-1 Airline Travel Basics, part 1]<br />
* [http://www.manager-tools.com/2009/08/airline-travel-basics-1-part-2 Airline Travel Basics, part 2]<br />
* [http://www.manager-tools.com/2008/08/business-travel-packing Business Travel Packing]<br />
* [http://www.manager-tools.com/2009/07/travel-airline-seats Travel - Airline Seats]<br />
<br />
The what and how of packing only a carry-on: [http://www.onebag.com/ Onebag.com]</div>Dbaronhttps://wiki.mozilla.org/index.php?title=Travel_Guide&diff=1177954Travel Guide2017-08-10T22:46:26Z<p>Dbaron: /* Country-specific notes */ mention canadian eTA</p>
<hr />
<div>----<br />
:: This page was originally created on Mozilla's internal intranet. However, it contains lots of information that could be useful to Mozillians who travel to Mozilla events, or really, anyone who travels, period. Employees can view the history and some corporate-specific info on [https://intranet.mozilla.org/Travel_Guide the original page].<br />
----<br />
<br />
Travel doesn’t have to suck. In fact, there are probably relatively few parts of your life where optimizations can make such a difference. We (the authors) have millions of miles travelled between us.<br />
<br />
* We never lose our luggage.<br />
* We can get from the airport entrance to our gate in 7 minutes.<br />
* We get free booze at the airport, upgraded flights, nicer rooms in hotels.<br />
* We don’t eat crap on the road, indeed we often discover great restaurants.<br />
* We have secrets.<br />
<br />
Let us show you them.<br />
<br />
But first, '''the 3 simplest things you can do to make travel a lot better''':<br />
<br />
# Don’t check luggage<br />
# Check in online<br />
# Pick a Frequent Flyer program<br />
<br />
Do those three and you’re already in the 80th percentile for travel success. What follows below is travel ninjitsu.<br />
<br />
= Listen To Your Fellow Travel Ninja's =<br />
[http://christianheilmann.com/2014/02/16/how-i-save-money-when-traveling-for-work-san-franciscovalleyus/ Christian Heilmann Ninjitsu]<br />
<br />
*Add Your Personal Ninja Tricks Here<br />
<br />
= Planning =<br />
<br />
== Quick Tips ==<br />
* Scan a copy of your passport and any other travel documents, and put them somewhere web accessible but password protected (like Dropbox or Google Drive). This is helpful for getting replacements, and for getting consular help in the meantime.<br />
* Let your credit card company know that you travel. Anti-fraud measures might lock your card the first time you use it on foreign soil, but they can flag your account so that doesn’t happen. This is no fun to discover after the fact.<br />
<br />
== Pick a Frequent Flyer Program ==<br />
<br />
Prices are generally going to be competitive, so figure out your most common trip(s) and figure out which airline/alliance is best for those. Use that group for everything. You can easily sign up for FF programs online, and add it to your travel agency profile (Egencia for Mozilla employees).<br />
<br />
Even if you travel rarely, you'll eventually accrue enough mileage for free travel, and having a FF number makes online check-in easier.<br />
<br />
If you travel often enough, though, (25k+/year on most airlines) you start earning preferred status. This is the difference between "scum" and "Yes sir right away sir." You have shorter lines for agents, shorter lines for security, you board first. You get access to elite lounges while you wait, and free upgrades to business class to make the trip more pleasant. These are little niceties, but they add up, and make travel much nicer. You can often share status with someone less privileged, which means your spouse likes traveling with you more, too.<br />
<br />
== Check In Online ==<br />
<br />
Every airline will let you check in online, usually 24 hours before your flight leaves. I know this will feel weird the first time, but it is an absolute necessity. With online check-in and no checked luggage, you can skip all the lines at the airport except security (and possibly customs/immigration).<br />
<br />
Checking in early may put you into a lower "group" for boarding (or at least not the suckiest, all-the-overhead-bins-are-full group). Check in as early as possible, even if you don't know how many bags you will check (correct answer: 0). You can always add (and pay for) checked bags when you get to the airport.<br />
<br />
The one '''exception''' to this guideline is that if you think your flight might be delayed or cancelled due to weather, ''don't'' check in online ahead of time. If you have to re-book, and you are already checked-in, the agent will have to "uncheck" you, which may slow down the re-booking process and cause you to miss out on alternate flight options. Keep in mind that weather problems cause ripple effects even in locations where weather is good. For example, your flight out of sunny Phoenix might be cancelled because the aircraft is grounded by a snowstorm in Chicago. (See this Egencia blog post for [http://info.egencia.com/wintertraveltips2014.html tips for avoiding weather delays].)<br />
<br />
Online check-in also lets you choose your seats, which brings us to...<br />
<br />
== Choose Your Seats ==<br />
<br />
* Take a window seat for very short flights or very long flights. Window seats have more shoulder room, less hassle from other passengers, and a window. The only downside is bladder management, but on short flights you can stick it out and on long ones you can get up when your fellow passengers do.<br />
* ''Every'' plane has some seats that suck. No recline, noisy, cold, lack of floor storage or slightly narrower than most, [http://www.seatguru.com SeatGuru] will tell you what to avoid. It'll also tell you which seats are great (extra legroom, etc) that you should take given half a chance. Usually, exit-row seats have extra legroom (good for tall people), and the last row and the row in front of the exit row do not recline (bad in general). The first row in a section (where you have a bulkhead in front of you instead of another seat) typically does not have under-seat storage, so everything must go in overhead bins, but it typically does have more legroom. (Seatguru will tell you whether or not this is the case on a particular plane.)<br />
* ''The Middle Seat Gambit'' - If you’re travelling with someone else, check in online together and look for an empty 3-person row. Take the aisle and window. Middle seats fill up last, there’s a decent chance the seat stays empty. If so, you have a lot more space to dump things during the flight, and more legroom since you can use that space instead of putting things under the seat in front of you.<br />
* If you’re traveling alone, you can still use the middle seat gambit by checking in online and looking at the seat map for someone acting as a de facto accomplice.<br />
* If there is only one (worst possible) seat left when you go to select seats, ''don't take it''. It will be claimed by someone else, and the gate agent will assign you a different seat. A flight that full might mean that someone gets bumped, but lack of a seat assignment doesn't guarantee it will be you.<br />
<br />
== Manage Layovers ==<br />
<br />
Flying nonstop to your destination is always easiest, but if that’s not a possibility for whatever reason, here are some other things to keep in mind:<br />
<br />
* Major metropolitan centers are often served by multiple airports, and each airline will have a preference. If you can’t get the flight you want with the airline you like, look to see whether you’re just pointing at the wrong airport.<br />
* If you can’t fly nonstop, you probably at least have your choice of connection airports, and the choice matters there. What’s more, a given airline will have certain preferred connection cities, so a couple trips should get you a reasonably complete list. (For example, connecting from Toronto to San Francisco on Star Alliance, it is much preferable to connect in Denver or Vancouver than it is to connect in Chicago O’Hare.) Consider the immigration/customs procedures of the country you're connecting in if it's separate from the origin or destination (e.g., prefer Vancouver over a US airport for connecting between Toronto and Auckland, since the US requires internationally-connecting passengers to go through immigration and customs).<br />
* If you have to have a connection, you might also have the opportunity to fly to a better airport (e.g., if you have to connect to Washington, DC, you are likely to be able to fly to DCA instead of IAD).<br />
* Take the season and likely weather into account when picking connecting airports; avoid snowy airports in winter, thunderstormy airports in summer.<br />
* If you have to layover overnight, prefer airports that have on-site hotels (and for god’s sake prefer Munich over Frankfurt).<br />
* If you’re crossing a border during your flight, it’s often preferable to layover in-country before crossing over. It means your first flight is domestic, so you can arrive later at the airport since there’s no immigration headache there. <br />
* Another reason not to check a bag is that when you have a connection after arriving in some countries (e.g., the USA, but not EU countries), you have to claim your bag, take it through customs (even though they rarely look at it), and then check it again for your connecting flight. More time and hassle.<br />
* Remember to account for boarding time when calculating layovers. If flight A arrives at 12:00 and flight B leaves at 1:00, you do not have an hour, you have about 20 minutes (because you need to get OFF of flight A once it arrives, transit to whichever gate/terminal flight B is in, and then be there for flight B '''boarding''', not flight B '''departure''').<br />
<br />
= Immigration and Customs =<br />
<br />
== General advice ==<br />
* Make sure you know what the requirements are for crossing all immigration and customs barriers before you do so. If you don't know what those requirements are, embassy or consulate websites are often useful, as are the US government's [http://travel.state.gov/content/passports/english/country.html country specific information] (though somewhat tending towards information useful to Americans).<br />
* Make sure you have any documentation needed in your carry-on luggage. When entering a country where you're not a citizen or resident, you should carry proof of onward travel, particularly if the reservation on which you're flying doesn't return you to your home country (e.g., because you're traveling on separate reservations).<br />
<br />
== Country-specific notes ==<br />
<br />
=== USA ===<br />
* visitors under the [http://travel.state.gov/content/visas/english/visit/visa-waiver-program.html visa waiver program] (those who don't need a visa) must apply online for an [http://www.cbp.gov/travel/international-visitors/esta ESTA].<br />
<br />
=== Canada ===<br />
* visitors who do not need a visa, are entering Canada by air, and are not US citizens or Canadian citizens or Canadian permanent residents, must apply online for an [http://www.cic.gc.ca/english/visit/eta.asp eTA].<br />
<br />
=== Schengen Area (Europe) ===<br />
* The [http://en.wikipedia.org/wiki/Schengen_Area Schengen Area] is an immigration-barrier-free zone covering most of the European Union and some additional non-EU countries, but not the UK or Ireland.<br />
* If you need a visa to visit the Schengen Area, it is easier to get such a visa if your point of arrival in the Schengen Area is the same country as your destination. (For example, if you're traveling to Spain, it is easier to arrive in Madrid after connecting in the UK or US than connecting via Amsterdam, since in the latter case getting the visa requires dealing with both the Spanish and Dutch authorities.)<br />
* If your nationality requires a visa to visit the Schengen Area and your trip does not terminate in Schengen, avoid making more than one connection in Schengen; in such a case you must get a Schengen visa, even though that's not your destination. Schengen immigration authorities look at your ''next'' point of travel (not your final one) to decide whether you need a visa; if it is Schengen, they will ask for one.<br />
<br />
=== New Zealand ===<br />
* Make sure to declare any shoes in your checked luggage. The authorities just want to look at them and maybe clean the dirt off for you, but they'll be upset if you don't declare them.<br />
* Don't even think about [http://www.nzherald.co.nz/nz/news/article.cfm?c_id=1&objectid=11404025 bringing fresh fruit] into New Zealand or you will get an instant fine.<br />
<br />
=== Australia ===<br />
* Visitors who can can enter without a visa must apply online for an [https://www.eta.immi.gov.au/ ETA].<br />
<br />
= Packing =<br />
<br />
'''Quick Tips'''<br />
* Have a toiletry bag that you keep stocked, rather than trying to remember to pack toothbrushes &c the day of. It doesn’t cost much to buy the duplicates once, and saves hassle/forgetting.<br />
* Put your favourite head, stomach, and sleep meds in the toiletry bag. You can buy most things on the road, but meds are sometimes an exception.<br />
* Throw a couple of large ziploc bags in there, too. They are immensely useful for storing wet clothing or leaking bottles or, by contrast, for putting things like passports in when you need them to stay dry. They weigh nothing and disappear into a pocket until needed.<br />
* Layers. You can adapt to a wide range of climates, even multi-city travel, by packing layers. Shirt, Sweater, Hoodie, Jacket is plenty warm, packs much more compactly than a parka, and gives you middle ground for an overwarm restaurant or an overcool office.<br />
* While you're packing, make a text list on your phone of everything you pack. Towards the end of your trip (such as waiting for your flight home), put a '+' next to every item you actually used. Next time, don't pack the things you didn't use. Also, if your bag goes missing, you have a list of what was in it.<br />
<br />
== Don’t Check Luggage ==<br />
<br />
:: Repeat after me: Checked luggage is for chumps.<br />
<br />
:: Again. Checked luggage is for chumps.<br />
<br />
:: -- George Clooney, ''Up in the Air''<br />
<br />
Every time you give your bag to the airlines, you're inviting them to lose it, abuse it, leave it in your departure city, forget about it on the tarmac during a rain delay, etc. North American airlines will allow you one carry on suitcase and one “personal bag” which usually means a purse or laptop. This is easily enough for a week of travel, and can be extended indefinitely with laundry service. Invest in a good carry-on and bring it with you.<br />
<br />
Put everything you need during the flight in your laptop bag, in case you have to gate-check your carry-on suitcase (common on short flights with smaller planes).<br />
<br />
== Choose the Right Luggage ==<br />
Checked luggage will inevitably be destroyed over time, regardless of quality. If you stick to carry on, though, good luggage will last forever; be willing to pay once for something that gets it right. Your happiness while traveling is worth it.<br />
<br />
His bias for non-rolling luggage notwithstanding, [http://www.onebag.com/bags.html this is the single best guide out there] for evaluating luggage. The highlights:<br />
<br />
* Lighter is better<br />
* Curvy designs rob you of packing volume, prefer right angles<br />
* Chain zippers are stronger than coil zippers (look for YKK as the brand of zipper)<br />
* Pocket design and positioning matters<br />
* So do tie-downs<br />
<br />
In truth, the best way to maximize quality while minimizing weight is to let go of the dependence on rolling bags. Soft-sided, non-wheeled bags are exceptionally light and versatile. [http://www.tombihn.com Tom Bihn] and [http://www.redoxx.com/ Red Oxx] are your best plays. Tom Bihn’s Aeronaut is is a full-sized carry-on that converts to a backpack for long walks across cobblestones/sprints to catch a connection/etc. The Red Oxx Air Boss was designed by the same guy who wrote the luggage-choosing guide above.<br />
<br />
If you're not ready to let go of wheeled bags, any manufacturer with a lifetime warranty is probably worth considering. These include:<br />
<br />
* [http://www.briggs-riley.com/ Briggs & Riley]<br />
* [http://www.travelpro.com Travelpro] ("the best" carry-on according to [http://thewirecutter.com/reviews/best-carry-on-luggage/ The Wirecutter])<br />
* Certain models of [http://shop.eaglecreek.com/lightweight-carry-on/l/111 Eagle Creek] (not all models have a lifetime warranty)<br />
<br />
Pay attention to the bag’s extensible arm: is it well constructed? What does it do to your interior space? 2 segments of extension or 3? Moving parts make everything more fragile -- if you are choosing moving parts in your luggage, they need to be brilliant.<br />
<br />
== Buy It There (BIT) ==<br />
<br />
Don’t try to anticipate every contingency and pack for it. You will bog yourself down with unnecessary cruft. Pack for what you ''know'' you’ll need, or at most what you reasonably expect to need the majority of the time. You can find contact solution, toothpaste, aspirin, and dental floss at almost any convenience store. For the rest, shove an extra $50 into a pocket somewhere and buy whatever you need there, if it comes up. <br />
<br />
(Good news: It comes up less often than you’d think.)<br />
<br />
BIT exceptions: <br />
There are some things you don't want to source while traveling - if you only use one specific brand of shampoo, conditioner, etc, transfer it to a small, travel-friendly bottle. Depending on where you're traveling BIT can be tough if you don't speak the language and are looking for something very specific (like Cipro in India or a flat iron in China). Goes without saying, but BIT does *not* apply to medications (remember that what requires a prescription varies by country, but you can apply it if you know that something can be bought without a prescription at your destination).<br />
<br />
=== Corollary: Wash It There ===<br />
If you’re gone for longer than a carry-on can reasonably contain (which is longer than you think), don’t fail over to multiple suitcases; just get things laundered partway through. Your hotel will offer laundry service, though it will be overpriced. Most of the time you’ll find a wash and fold place within walking distance or a service that does pick up and next day drop off.<br />
<br />
Also keep in mind that at most Mozilla or other geek events, you will probably acquire at least one or two t-shirts. You can bring one or two fewer shirts; if this guideline fails, wash one of the ones you brought.<br />
<br />
If you bring quick-drying underwear and socks, you can wash them in the sink or bathtub and dry them overnight on the towel rack (except in humid climates). You can skip bringing detergent by using the hotel's shampoo (as long as you don't mind your underwear smelling like "ginger lemongrass" or whatever); shampoo is just mild detergent. Check the plumbing before you fill the sink; some hotels don't install the lever for raising the plug. Before hanging items to dry, roll them in a towel and squeeze out excess moisture.<br />
<br />
== Counterpoint: The case for checking a suitcase ==<br />
A few heavy-traveling Mozillians are in the "checked bag" camp. Add your reasons for using this strategy here:<br />
* Problems with checked luggage are actually quite rare.<br />
* You don't have to schlep a roll-aboard through the airport with you, including squeezing it into tiny toilet stalls.<br />
* You can pack a few extra things that help you be more comfortable on an extended trip.<br />
* At least one airline (American) gives early boarding privileges (after Elite and Priority but before Zone 1) to passengers with no overhead baggage.<br />
* You aren't limited to 100ml bottles of liquid/gel/cream, and can bring home ''properly packed'' wine, booze, perfume, etc. (Wrap the bottle in at least two plastic bags and nestle it in the groove left by the extending handle, surrounded tightly by clothes.)<br />
* Having airline status often helps your bag appear on the belt faster. Also, if the final segment of your trip is an international arrival in the United States, you're unlikely to have to wait long for your bag, since all baggage goes to the same belt, so it gets there quickly.<br />
* TIP: Get a suitcase with four wheels. Baggage handlers can slide it across the floor of the cargo hold instead of tossing it, subjecting the suitcase and its contents to much less abuse. Anything that protrudes, like carry straps or zipper pulls, can get snagged and chewed up in baggage-handling equipment; go for streamlined.<br />
* TIP: Ask for your checked luggage to be marked "Fragile". It will be loaded on top of other bags, and usually be unloaded first.<br />
* TIP: If you check luggage, don't let your eyes off the bag until there's a tag on it, and if you can, check that the tag is correct (with your name and correct destination airport on it). One of the common reasons for lost/delayed luggage is getting the wrong tag on it right at the check-in desk.<br />
* TIP: Things to make sure are '''not''' in your checked bag: everything you need to get through customs and immigration and get to your final destination. Any electronics that might be stolen. Lithium-ion batteries (prohibited).<br />
<br />
Some airlines (particularly non-North American ones) have much lower limits for what you're allowed to carry on, so you'll have to check luggage anyway.<br />
<br />
Some airlines (e.g., Air France, KLM) will even want to weigh your carry-on bag (often although not reliably), and want it to be a weight that's lower than what it is with your laptop in it (e.g., 6kg, 8kg). Remember that your laptop often counts as a separate personal item and you can take it out of the bag before weighing.<br />
<br />
==Packing Techniques and Tools==<br />
Your strategy for how to put your stuff in your suitcase is very much a matter of personal preference, along with the type of travel you're doing (destination vs. touring) and the type of clothes you bring. Here are some ideas that may be helpful.<br />
<br />
* The [http://www.onebag.com/pack.html bundle method] is great for avoiding wrinkles, but it tends to require that you unbundle ''everything'' to get out any single thing.<br />
* It's extremely helpful to have some kind of containers to organize your stuff. Purpose-made packing "cubes" are great, but are absurdly expensive. You can get by with zip-top plastic bags if you don't travel often, or while you're waiting to find ready-made cubes on sale. <br />
* If you buy only one packing accessory, consider getting a [http://www.amazon.com/Eagle-Creek-Travel-Pack-It-Folder/dp/B002YIRC3O/ packing folder], which helps you fold larger items (shirts, pants, skirts) to a uniform footprint, and then encloses them like an envelope.<br />
* Compression bags, which let you squeeze all the air out of your clothes, are good only for clothes that don't easily wrinkle. However, a compression bag can be great as a laundry bag to minimize the volume of dirty clothes on your way home.<br />
<br />
= Airport Hacking =<br />
'''Quick Tips'''<br />
* ABC: Always Be Charging. Wherever you come to rest, be charging. Maybe your flight has power plugs, that's swell, but maybe they stop working, or your seatmate gets to it first, or you need it to charge your phone. If you're at rest for more than 10 minutes, find a plug. If you bring a power strip so others can plug in, too, you can make friends anywhere :-)<br />
* Watch where uniformed crew members go. They know the best eateries in any given airport, and even where to stand on the tram platform in order to get off quickly at the other end.<br />
* The internet knows about delays before your gate agents do. Bookmark [http://flightaware.com/live/ flightaware] right now, and use it from your phone at the airport to keep tabs. Caveat: Flightaware may show your flight as delayed because the inbound plane you're getting on is delayed; if the airline substitutes another aircraft, your flight could be on time or only a little delayed.<br />
* If you do see signs of a significant delay, particularly at night when it's likely you'll be put off until morning, act swiftly before the lines form. Talk to gate agents about rebooking onto other flights and if the line there is long, be on the phone with your airline as well. First to rebook means first to call hotels and taxis and all the rest. Being last to rebook means sleeping in the airport. If you have elite status, call the customer service number for elite members, not the general customer service number.<br />
* When you get off the plane, the restroom closest to your gate will be crowded with other people from your flight. Keep going to the next one further away.<br />
* No one wants to sleep in an airport, but flight delays or cancellations, or just poor planning, may require it. There is actually a whole website devoted to [http://www.sleepinginairports.net/tips.htm sleeping in airports].<br />
<br />
<br />
== Being prepared for security ==<br />
* Bring identification. [http://www.tsa.gov/traveler-information/acceptable-ids Here's a list of acceptable IDs] in the US. If you forget your ID, all is not lost. It's possible, with some extra hassle, to travel within the US even if you don't have your identification. [http://blog.tsa.gov/2013/04/tsa-travel-tips-tuesday-can-you-fly.html Here's what the TSA says to do if you don't have ID.]<br />
* Avoid getting into a screening line behind people who look like they don't travel often (families with kids, retirement-age folks, large groups).<br />
* Wear slip-on shoes (and wear socks if you don't want your feet getting dirty).<br />
* Consider not wearing a belt, or wear one with no metal, so you don't have to take it off.<br />
* Avoid clothes with extra pockets, like cargo pants. They can be flagged by the nudie-scan, and cause you to get a pat-down. Same for "travel" clothes with hidden pockets; these can be handy while touring, but not while flying. Even a hoodie can win you a pat-down for the hood and kangaroo pocket. <br />
* On the other hand, a jacket with lots of pockets is like an extra carry-on; you have to remove it for security anyway, and you can keep your in-flight necessities (gadgets, etc.) close to hand during your flight.<br />
* Know the drill with liquids, gels, and creams: containers at most 100ml/3oz, in a clear zip-top bag, 1 liter/1 quart size. Have this in an external pocket of your carry-on, ready to pull out and put in a bin. (If you travel often, you might want to get a sturdier bag than the grocery store kind. It must still be clear and zip-top.)<br />
* Avoid large metal jewelry.<br />
* Take everything, but especially metal (keys, coins, etc.), out of your pockets.<br />
* Leave your pocket knives and multitools at home.<br />
* If you're wearing an activity monitor, such as a FitBit, take it off for screening.<br />
* You should hang onto your ID and boarding pass as you go through the line, but you can't carry them through screening; put them in your bin.<br />
* Put the bin with your shoes, jacket, and liquids onto the conveyor belt first. You can be getting dressed while the rest of your stuff comes through.<br />
* Take your laptop out of your bag and put it in a separate bin. You can usually leave it in a sleeve, as long as there's nothing else in the sleeve. <br />
* Consider getting a checkpoint-friendly laptop bag, with a laptop-only section that folds out without taking out the computer. The less you handle your laptop, the less likely you are to drop it. (US TSA allows you leave the computer in this type of bag; other countries often do not.)<br />
* Don't go through the screening machine until your stuff is on the conveyor belt.<br />
<br />
== US Trusted Traveler Programs ==<br />
If you frequently cross US borders, you can save time and hassle in the long run by enrolling in one of the programs that provide expedited entry for pre-approved travelers. Enrolling involves an application fee and form, and an in-person interview at an entry point, so there is a start-up cost in time and money. Which program you should enroll in depends on the type of crossing you do most; you can enroll in more than one. <br />
<br />
* When entering the US, if you're not in a "trusted traveler" program, try to get into the immigration queue that is ''next to'' the Global Entry lane. If no one is in the Global Entry lane, the officer there will often take people from the nearby queue, making it move faster. Do likewise for NEXUS when entering Canada.<br />
* Wear Firefox gear when going through immigration, anywhere. It creates goodwill and starts pleasant conversations.<br />
<br />
===Automated Passport Control===<br />
Automated Passport Control kiosks are available to citizens of the US, Canada, and [http://www.cbp.gov/travel/international-visitors/frequently-asked-questions-about-visa-waiver-program-vwp-and-electronic-system-travel Visa Waiver Program] countries, for entry into the US, in an expanding number of North American cities. Unlike Global Entry or Nexus, these kiosks require no pre-registration. You swipe your passport, let the kiosk take a photo, answer some questions, and then get a receipt that you show to a Customs and Border Patrol officer. The kiosk replaces filling out a customs card by hand.<br />
<br />
See the [http://www.cbp.gov/travel/us-citizens/Automated%20Passport%20Control Automated Passport Control] webpage for a list of cities with APC kiosks.<br />
<br />
=== Global Entry ===<br />
[http://globalentry.gov/about.html Global Entry] provides expedited screening for entry ''into'' the US at certain airports. Once in the program, you can go to an automated kiosk instead of an immigration agent (skipping the enormous lines that result from multiple international flights arriving at about the same time), and you can answer the customs questions at the kiosk instead of filling out a paper form. Unless there is an issue with your kiosk interaction (such as it couldn't read your fingerprints), you don't need to talk to a CBP agent. Global Entry is open to U.S. citizens, lawful permanent residents of the U.S., Dutch citizens, South Korean citizens and Mexican nationals.<br />
<br />
=== NEXUS ===<br />
[http://www.globalentry.gov/nexus.html NEXUS] provides expedited screening for crossing the US-Canada border in both directions. It can be used at land and sea entry points as well as at airports. You can use the NEXUS-only lanes at land crossings only if every person in the vehicle (including children) has a NEXUS card. Using NEXUS at an airport requires scanning your irises. If you wear contact lenses, you must remove them for the initial iris scan that is taken after your enrollment interview.<br />
<br />
=== Other US programs ===<br />
* [http://www.globalentry.gov/netherlands.html FLUX] expedites passage between the US and '''the Netherlands''', and is open to US and Dutch citizens.<br />
* Global Entry members can receive expedited entry into '''[http://www.globalentry.gov/newzealand.html New Zealand]'''.<br />
* [http://www.globalentry.gov/sentri.html SENTRI] provides expedited entry into the US from '''Mexico''' at specific land crossings.<br />
* [http://www.globalentry.gov/korea.html Smart Entry Service] provides expedited entry into the Republic of '''Korea'''. It is open to US and Korean citizens.<br />
* [http://www.globalentry.gov/smartgate.html SmartGate] provides streamlined entry into '''Australia''' for US Global Entry members. Visa requirements still apply.<br />
* [http://www.globalentry.gov/tsa.html TSA PreCheck] enables US Global Entry and Canadian NEXUS members to use designated TSA airport screening lanes, without removing liquids, laptops, shoes, jackets, or belts. You must provide your membership number when booking flights with participating airlines. TSA is expanding the PreCheck program to include more people, including US military members and those invited by their airline's frequent flyer program. You must still apply, pay a fee, and go through an interview. See the [http://www.tsa.gov/tsa-precheck TSA PreCheck] website for details.<br />
<br />
== Other countries' traveler programs ==<br />
* The UK's [https://www.gov.uk/registered-traveller Registered Traveller service] enables certain citizens of Australia, Canada, Japan, New Zealand and the USA to get faster entry to the UK, without filling out a landing card. <br />
<br />
<br />
Still to write:<br />
* priority security lanes<br />
* being nice to security<br />
* priority boarding (travel with a colleague who has priority status as their guest if you don't have it yourself)<br />
* lounges<br />
* watch your crew<br />
<br />
= Flying =<br />
<br />
'''Quick Tips'''<br />
* Hydrate, hydrate, hydrate. Air in an airplane at altitude is incredibly dry and dries you out. Drink water whenever you can. Bring an empty water bottle (even better: collapsible) and fill it from a water fountain inside security. (Some airports, like SFO, have water bottle filling spots that make this a little easier.) Don't drink the water that comes out of the water tanks onboard an airplane, including coffee and tea; you don't want to know how disgusting those tanks are. If you get water in the beverage service, ask for fizzy water (club soda) to ensure it came out of a bottle or can. If you need to brush your teeth in-flight, use water from your water bottle, not the tap in the toilet.<br />
* Request an alternate meal (kosher, indian, vegan, whatever) - they tend to be tastier, and often come first. (However, the downside to the meal coming first is that the tray is going to be in your way substantially longer.)<br />
* If you're in an aisle seat, you’ll find that the aisle-side armrest won’t lift. This is annoying, because it is much easier to deplane with that thing out of the way. Reach back to where the armrest joins the back of the chair -- there may be a release latch or button. (This works on some Boeing 777s; most smaller craft do not have this feature. See [http://brokensecrets.com/2011/01/17/raising-the-airplane-aisle-armrest/ this article] for a photo.)<br />
* Always wear shoes before going to the airplane lavatories; never go barefoot or wearing socks only. <br />
<br />
== Headphones ==<br />
Enjoying music or movies during travel is much better with headphones designed for travel use. You need to consider three types: <br />
* active noise-cancelling headphones<br />
* those without noise-cancellation<br />
* in-ear monitors. <br />
Generally speaking, on airplanes, active noise-cancellation will be better on the plane but worse when you're not on the plane (in the hotel room, for instance.) A quality headphone without noise cancellation will almost always sound better when not on an airplane. In-ear monitors allow for excellent sound quality and also allow one to rest your head on a pillow without the headphone pushing against one's ear, but some are uncomfortable with putting anything in one's ear. In-ear monitors are also much more compact. For those who want the sound quality of in-ear monitors and the compactness, but find that fit is a problem, consider Comply foam tip replacements which can be selected to fit your ear size.<br />
<br />
* For active noise cancellation headphones, the Bose Quiet Comfort 15 is the most popular model sold and for good reason. However if you want the headphone to be good when the noise-cancellation is turned off, you may want to consider the [http://www.psbspeakers.com/products/headphones/M4U-2-Headphones Psb m4u 2], which is more expensive but also more versatile.<br />
* For headphones without active noise cancellation, consider rugged models that have reputations burnished by decades of use by audio professionals such as the Sennheiser HD-25 1-ii. Another popular option is the V-Moda M-80 which has similar sound quality, has a good reputation for build quality, and also comes with a nice travel case.<br />
* For in ear monitors, there are too many to list but one line that is very popular is the Shure SE series which have models from $99 on up. These are very rugged models which allow for replaceable cables, replaceable tips and have very good sound quality.<br />
Additional resources for headphones include [http://www.innerfidelity.com/content/innerfidelitys-wall-fame Innerfidelity's Wall of Fame] and Head-fi.org's [http://www.head-fi.org/t/618255/check-out-the-head-fi-summer-2012-buying-guide 2012 Summer Buying Guide].<br />
<br />
== Make friends with TSA and your flight crew ==<br />
<br />
Airplanes are a sea of grumpy, tired, unhappy people. A little friendliness goes a long way -- especially if you're regularly flying the same route with the same flight crew.<br />
<br />
== Seat etiquette ==<br />
The following tips are about showing consideration to your fellow passengers, who unfortunately may not even notice it. But violating these norms is likely to cause annoyance. You don't want to be "that guy", do you?<br />
<br />
* The person in the middle seats gets to use both armrests. The people in the window and aisle seats get a little extra space, so yielding one armrest each is the least they can do. In any case, try to keep your elbows in your own space.<br />
* Consider the person behind you before reclining your seat into their space, especially if they are trying to eat or use a laptop. Avoid reclining abruptly (though it's not always possible to control this). Raise your seat back during meals.<br />
* If you need to leave your seat during the flight, try to avoid hoisting yourself up by yanking on the seat in front of you. This may be difficult to avoid if the seat is reclined (see above).<br />
* If you have an individual touchscreen in the seat back in front of you, jabbing it forcefully doesn't make the touchscreen work any better. If it's really not responding to touch input, try controlling it from the armrest controls.<br />
<br />
* [http://www.independenttraveler.com/travel-tips/travelers-ed/the-etiquette-of-seat-backs-and-elbow-room The Independent Traveler: The etiquette of seat backs and elbow room]<br />
<br />
<br />
<br />
Still to write:<br />
* how to sleep (Needs to be written by someone who is actually able to sleep on planes)<br />
** [http://gizmodo.com/how-to-get-the-best-sleep-of-your-life-on-an-airplane-1598708044 Gizmodo: How to get the best sleep of your life on an airplane]<br />
** [http://www.independenttraveler.com/travel-tips/travelers-ed/sleeping-on-planes Independent Traveler: Sleeping on Planes]<br />
* move on long flights<br />
<br />
= Tips for specific airports =<br />
As a general rule of thumb, in any airport, the terminal or concourse that serves international flights has nicer shops and restaurants than the areas for domestic flights. So, if you're traveling domestically, have time to kill, and can get into the international terminal without going through passport control, you might want to go hang out there.<br />
<br />
== AMS Amsterdam ==<br />
* in the international section (only?), there are nice quiet places to sit on the upper level outside the lounges (even if you don't have lounge access)<br />
* if you want to take the train to/from the airport, hoard coins (€4 to Amsterdam-Centraal, less to Amsterdam-Lelylaan or Amsterdam Zuid), since the ticket machines don't take bills or American credit cards. (The city trams/buses in Amsterdam do take bills, but this is a national train.)<br />
* note that the entirety of the outside-[https://en.wikipedia.org/wiki/Schengen_Area Schengen]-immigration part of the airport does security at the gate, per flight<br />
<br />
== AUS Austin, Texas ==<br />
The food available in the airport is actually pretty good, since most of the food concessions offer menus from local restaurants. Get to the airport early enough to have a last plate of barbecue or breakfast tacos. <br />
<br />
Another reason to get to the airport early is the "Knot Anymore" chair massages available near gates 13 and 7. Austin is awash in good massage therapists, so the ones working in the airport are far better than most airport massage services.<br />
<br />
== CDG Paris / Charles de Gaulle ==<br />
* CDG airport has multiple airport hotels on premises (on the around-the-airport CDGVal shuttle train); typically at least one of the fancy ones has good prices because it isn't hosting a conference that week, but there's also an Ibis. <br />
* CDG airport has four disconnected parts:<br />
** Terminal 1 (the cylinder with pods) (United is here)<br />
** Terminal 3 (the discount airlines)<br />
** Terminal 2A-2B-2C-2D-2E-2F (the bulk of the airport) (Air France is here)<br />
*** note that there are two satellite piers attached by train (outside immigration but not inside security) attached to Terminal 2E (the attached part of terminal 2E is called K, the satellites are called L and M)<br />
** Terminal 2G<br />
* transport<br />
** there's a train (CDGVal) connecting Terminal 1, Terminal 3 / Roissypole (where most but not all of the hotels are), and Terminal 2 (the station is between 2C/2D/2E/2F)<br />
** high speed trains stop only at the terminal 2 station (between 2C/2D/2E/2F)<br />
** RER trains (Paris's suburban rail network) stop at Terminal 2 (same station, again) and at "Terminal 1" (which is actually the Terminal 3 / Roissypole station for CDGVal)<br />
** Terminal 2G is reachable only by shuttle (I think, never done it)<br />
** If you want to take the RER to/from the airport, hoard coins in advance to pay the €9.50, since foreign cards don't work, and the machines don't take bills. <br />
** The RoissyBus is only €10.50 and runs nonstop between CDG and the Paris Opera, only a few blocks from the Mozilla Paris office. Look for signs for "RoissyBus" or "Paris by bus" within each terminal to find the bus stop.<br />
<br />
== JFK New York ==<br />
* The wifi password of the British Airways' lounge is "London" (according to Reddit). You can usually get in range of the wifi hotspot without going inside the lounge.<br />
<br />
== LHR London Heathrow ==<br />
* Terminal 5 (international) <br />
** If you need to take the train to concourse B or C, go to the far end of the platform. You'll bypass the crowds at the near end, and be closest to the escalators when you exit.<br />
** If you need to backtrack from concourses B or C to concourse A, ''don't'' take the train; you'll be routed through security again. There's a pedestrian tunnel that parallels the train, and comes out next to elevators that let out inside security in concourse A. The tunnel doors are marked "Emergency Exit", but do not have alarms, and in fact open automatically, to accommodate mobility-assistance carts. Stay to the left (remember: you're in England) to keep from being run over by them.<br />
* The Piccadilly Line runs directly from Heathrow to Leicester Square (where Mozilla's office is). If you're going to near the office, it's only barely longer total transit time as the Heathrow Express (since it's direct), and a lot cheaper and easier. See [[London#Finding the Space]].<br />
<br />
== NCE Nice, France ==<br />
* if you have a really early flight, there are multiple decent airport hotels nearby. But do '''not''', under any circumstances, stay at the Etap.<br />
* if you want to avoid a really early flight, consider as an alternative doing an overnight layover at CDG, which has multiple airport hotels walking distance from Terminal 1 (but poorly signed). Make sure your layover is long enough, though.<br />
* if you're traveling to west of the airport (e.g., towards W3C's European offices near Antibes) and want to take public transit, it's possible to walk to the Nice - St. Augustin train station ('''not''' the main Nice - Ville train station) in about 15-20 minutes, but there's basically no signage. But definitely look at the train schedules before trying this. Buses from the bus station (gare routière) at the airport may be better.<br />
* there's a free shuttle between Terminals 1 and 2. Don't try walking between terminals.<br />
* There are bus stations at both terminals, but some bus routes stop at both terminal and some stop only at Terminal 1. You need to buy a ticket at the station before boarding.<br />
* the airport does not have water fountains behind security. But restaurants will probably be willing to fill up a water bottle for you, especially if you've bought something there.<br />
<br />
== NRT Tokyo/Narita ==<br />
* If you can do so just as easily, fly to Haneda Airport (HND) instead, which is closer to the city.<br />
* Don't even ''think'' of taking a taxi. It will take hours, and cost multiple hundreds of US dollars.<br />
* Two companies (JR and Keisei) run trains to Tokyo, and both have express and local services at different prices. Choices depend on where in Tokyo you're going. Google Maps might be helpful, or just figure it out when you get there.<br />
* Consider taking a [http://www.limousinebus.co.jp/en/ Limousine Bus] to somewhere close to your destination, and take a taxi from there.<br />
<br />
== ORD Chicago O'Hare ==<br />
* In Terminal 3, at the beginning of concourse G, there is a "Chicago Urban Garden" on the second floor, with aeroponic herbs and vegetables. This is a nice quiet place to wait if you don't have access to an airline lounge. <br />
<br />
== SFO San Francisco ==<br />
* if you're through security and looking for food, realize that some pairs of terminals are connected behind security. In particular, there are four separated behind-security zones at SFO right now: International-G/Terminal3-F/Terminal3-E, Terminal2-D/Terminal1-C, Terminal1-B, and International-A. In particular, if you're in C, you can probably find better food and better places to sit in D, and at some hours there's not much open in G, but you can head over to F.<br />
* The recently renovated terminal areas are the International Terminal (2000), Terminal 2 (gates D) (2011), and Terminal 3 gates E only (2014)<br />
* If you're taking BART to the airport, you can take the airtrain or walk to get around the airport from the airport BART station. You should definitely walk to International (G or A, which share a large central checkin hall but have separate gate areas), maybe walk to Terminal 3 (at least if you're ready to go straight to the security line), and you can walk to the other terminal if you like.<br />
<br />
== SJC San Jose CA ==<br />
<br />
== TPE Taipei Taoyuan ==<br />
* if you're coming from within Asia to Taipei, fly to Songshan Airport (TSA) instead<br />
* if you have Star Alliance gold, there are multiple EVA lounges to choose from. The main one, with all the good food, is on the same side of the open (to the floor below) space as the tropical bar one, with entrance across the hallway from it (not across the open space)<br />
<br />
= Hotels =<br />
<br />
'''Quick Tips'''<br />
* Ask for upgrades. I know, this sounds trite, but it works. If you don’t know how that works, just remember, when checking in, to ask “Is there a better room available?” If they say yes, you’re set. If they say no, that’s fine. If they say “yes, for a price” then you can consider that price and make the call. We’ve gotten $2000/night rooms on a $180/night booking just by asking. This tends to work well when the hotel has a lot of open inventory (particularly effective in LAS, less effective near Moscone during a conference).<br />
* When checking in, adjust your interactions with the clerk based on whether they smile when you approach. Chit-chat with a smiling clerk, but not with an unsmiling clerk. The latter is just as much a form of establishing rapport as chit-chat, because you're not wasting the time of a transaction-oriented person. And establishing rapport can make the marginal difference in whether they decide to give you an upgrade.<br />
* Expensive hotels tend to have sensors in the minibars, but most of the rest still just have housekeeping track what’s missing each visit and bill you. If you do get the munchies, just head out to a convenience store the next day before housekeeping and buy matching replacements at the saner price. <br />
* You can avoid the minibar entirely by grabbing a granola bar or two from a Mozilla kitchen before departing. They are bound to be healthier than anything you find in the minibar late night. <br />
* Every hotel has a bucket of standard toiletry items (toothbrush, razor, &c). You should have a toiletry bag stocked and ready to go (see above) but if you find yourself missing something, just call the front desk.<br />
* Likewise, every hotel has a bucket of left-behind chargers/power cables.<br />
* Set your climate controls when you first get into the room. Forgetting until you come back after dinner ready for sleep and finding the room is hot and stale is no fun.<br />
* Some hotels won’t let the climate controls work unless your room keycard is stuck into a switch by the door. This isn’t a magstripe reader, it’s just a physical switch - use a business card or a folded up piece of paper (or your library card) and have your room the way you want it.<br />
* If the drapes that don't quite meet, and therefore let in unwanted sunlight or street light, use one or two big binder clips to keep the drapes closed.<br />
* You can usually get a later check-out time just by asking. This doesn't work indefinitely, but they can't clean every room at once, so asking for 1pm instead of 11am just means they move your room to the bottom of the list for cleaning that day.<br />
* Repack for departure before you go to sleep, except for the clothes and toiletries you'll need in the morning. That way, if you oversleep for whatever reason, you can throw on your clothes, grab those last items, and go without wasting any more time.<br />
* To avoid leaving things behind:<br />
** Bring your original packing checklist, and use it to repack.<br />
** Pull all the linens off the bed and throw all used towels into the shower, so you're sure nothing's hidden, and check every wall socket for chargers.<br />
** If you unpack into drawers, check every drawer before you leave.<br />
<br />
== Pick a hotel, get into the frequent guest program ==<br />
<br />
Same deal as airlines. At the least, it eventually adds up to free stays, but getting to status means room upgrades, easier check-in, more flexibility on check-in/check-out times, and extra points for each stay. Some hotel loyalty points can also be transferred to airline loyalty programs.<br />
<br />
It can be harder to consistently stay with the same hotel group than to consistently fly the same airline (they're sold out or not convenient, the conference hotel is elsewhere, etc.). However, it's good to join the loyalty program for any hotel you stay at, before you make your reservation. You may get a better rate or a better room. Hotel staff seem to give an extra measure of courtesy and consideration when you're in the loyalty program. (When booking by phone, I've had a "sold out" group rate suddenly become available when I gave my membership number.) If you haven't joined by the time you check in, ask the clerk to sign you up; they'll get credit for signing you up, and will be even more inclined to treat you nicely.<br />
<br />
Linked below are the programs associated with the hotels that are typically used for visiting Mozilla in Mountain View.<br />
<br />
{|<br />
|-<br />
|Holiday Inn Express<br />
|[http://www.priorityclub.com/ Priority Club]<br />
|<br />
|-<br />
|Avante/Wild Palms<br />
|[http://www.joyoflifeclub.com/ Joy of Life Club]<br />
|(Does not give points for stays that are paid through corporate billing.)<br />
|}<br />
<br />
== Choose Your Room ==<br />
<br />
It's a good practice to indicate that you have any preference on your room at all. Put this into your loyalty program profile and your travel agency profile (Egencia, for Mozilla employees), so it's transmitted with your reservation. If you have no preference, they will put you in the room for people who do not indicate a preference. You know, the one in the basement. With the leaky faucet and carpet from 1973. <br />
<br />
If you have a choice between one or two beds, choose two, even though you'll only use one for sleeping. The other one makes a great surface for spreading out your stuff. Often, hotel beds are on casters, so you can shove the extra bed against the wall, to prevent stuff falling between the bed and the wall.<br />
<br />
Generally, you'll do well to ask for a high floor and a room away from the elevator. Many hotels do renovations by floor starting from the top and working their way down. So high floors have a better chance of being recently renovated. They are also further away from street noise or the bar in the atrium. A room away from the elevator means less foot traffic and not waking up at 5am to repeated "ding!" of the elevator door opening. For motels, you want upstairs (less foot traffic) and outside (away from the courtyard with the pool).<br />
<br />
If the room is awful, don't be afraid to walk back downstairs and see if they have anything a bit more updated. If the whole hotel is awful, check your luggage at the desk and walk in a square block radius around the hotel to see if there's something less frightening. <br />
<br />
Never pick a hotel based on a picture of the lobby. Lobbies are always the first thing to get renovated.<br />
<br />
== Tipping Hotel Staff ==<br />
If you believe in tipping (which varies across cultures):<br />
* If you take a hotel shuttle from the airport, be sure to tip the shuttle driver. Don't just hand it to them and walk away; look them in the eye and express genuine appreciation for their service while you give them the tip. This is your first contact with the hotel staff, and if you make a good impression, word will spread to the other staff, and you'll get great service throughout your stay. This driver may also be the person who gets you to your outbound flight, through heavy traffic, just in the nick of time.<br />
* Similarly, leave a tip for housekeeping after the first night. This paves the way for good service when you make special requests, such as extra towels or toiletries, or to come back later because you're still in the room. Leave the money on top of a note that says at least "Thanks!" so the housekeeper knows it's for them.<br />
<br />
= Money =<br />
<br />
* Exchange: Do not change money at the airport. The rates are higher there than anywhere else. If you have a local bureau de change, use that, or order currency online for pickup at the airport. If you can find a company that does that (Travelex in the UK, at least) the rates will be much better than those posted on the wall that they charge you when you are a captive customer.<br />
* Debit: Using an ATM card can be an easy and inexpensive way to secure some local currency. Make sure your card will work abroad before you travel. Common ATM networks that are broadly available include Pulse and Plus. Consider getting a debit card with no foreign transaction fees (Charles Schwab offers one).<br />
* Stay organized: It's helpful to keep your currency separate from your home currency, particularly if you're going to cycle through multiple currencies during your trip (usd > euro > pounds). Don't underestimate the power of a ziploc baggie if you're American and unaccustomed to coinage-heavy currencies.<br />
<br />
== Credit cards ==<br />
The US uses a different system (magnetic strips) for credit card security from the rest of the world (which uses the chip-and-pin system). This can cause headaches for both Americans traveling abroad, and others traveling to the US, as the systems are incompatible.<br />
<br />
* A very few US banks offer chip-and-pin cards, including Citibank and [https://www.andrewsfcu.org/credit_cards_and_loans/credit_cards/globetrek_rewards.html Andrews Federal Credit Union]. The latter also has no annual fee and no international transaction fees. See this extensive but not exhaustive [http://thepointsguy.com/2013/05/us-credit-cards-with-smart-chips/ list of US-based chip-and-pin cards]. <br />
* You can get a pre-paid, reloadable chip-and-pin card called [http://www.cashpassport.com/1/travelex/ "Cash Passport"] from Travelex. You can buy it and reload it online or at Travelex locations in the US. You can load it in multiple currencies: GBP, EUR, CAD, AUD and JPY. The security seems a bit crappy (you can't change the PIN, and their only security question is mother's maiden name), but since it's pre-paid, you can limit your financial exposure, and reload online as needed.<br />
<br />
Another issue for travelers is transaction fees when making purchases in currencies other than your home currency; these can range from 1% up to as much as 7%. US-based credit cards that don't charge international transaction fees include CapitalOne and Andrews FCU.<br />
<br />
More and more US retailers have card readers that accept chip-based cards, so the situation is improving for visitors to the US. However, they probably don't understand the PIN system, so you will still need to sign (either on the reader, or on paper).<br />
<br />
= On Foreign Soil =<br />
<br />
* Data/Voice rates<br />
** You can use Skype to call US 1-800 numbers toll free from anywhere in the world.<br />
** Before you leave your home country, add $20-40 of SkypeOut credits to your account. While Skype to Skype calls are free, SkypeOut credits will let you call any number internationally for about $.02 per minute.<br />
** International text messages are typically NOT covered under your mobile plan. For US cell plans, it's usually about $.50 per SMS. If you have a good international rate, think long and hard about when you use SMS and why. A conversation about when you landed and where to meet and what time to get there on SMS may be more than a 2 minute call that covers the same details.<br />
** [http://readwrite.com/2014/06/17/5-secrets-avoiding-hefty-international-data-roaming-charges-fees 5 secrets to avoiding hefty international data roaming fees] <br />
* Finding wifi<br />
** In airports, airlines' priority lounges often have no wifi password, and you can access their hotspots from outside the lounge. (See note above for JFK airport.)<br />
** Starbucks, McDonalds, and Burger King are sadly ubiquitous, and often have free wifi.<br />
** You can sometimes find the password for a business's wifi in the comments for that business on FourSquare.<br />
* Language barriers<br />
** Grab some business cards or stationery with your hotel's address on them before you head out. You can hand one to a cabbie whose language you do not speak, to get yourself back to home base. <br />
<br />
Still to write/update:<br />
* Language barriers<br />
** Add Line2 details...<br />
<br />
==Coping with jet lag==<br />
* Do not go to sleep. Do not nap. Stay up as long as you possibly can. Eat meals at local times and get into bed when it's dark outside. It will hurt on day one but by day three, you'll be glad you did. <br />
* If you absolutely must sleep, do a 20 minute powernap and then get up, walk around, and do not fall back to sleep. (Powernapping pro tip: drink a cup of coffee, and ''then'' take a nap; the coffee will wake you up in a short while.) <br />
* In a pinch, Benedryl (dipenhydramine) can help you reset your internal clock and it's substantially gentler on your system than the prescription sleep aids. (It's also good for nausea if you get motion sickness, and of course, allergic reactions.)<br />
* If you find yourself awake when you should be sleeping (by local time), avoid bright screens (computers, phones, e-readers), because they activate wakefulness in your brain. Try reading a paper book or magazine (radical, I know). If you must use a screen, set it to white text on a black background, to reduce the overall brightness; or get an app (such as [https://justgetflux.com/ f.lux] for Mac/iOS or [https://play.google.com/store/apps/details?id=com.urbandroid.lux Twilight] for Android) that reduces the amount of blue light emitted by your device at night.<br />
* If possible, follow the [http://www.wikihow.com/Prevent-Jet-Lag-with-a-Modified-Diet Anti-Jet Lag Diet]; this is easier to do at home than while traveling, but IME even an approximation helps. <br />
** As an abbreviated version: eat as little as possible on your day of travel, avoiding caffeine and alcohol; eat a high-protein breakfast at breakfast time in your new time zone.<br />
** Bring protein bars with you to ensure that you can get protein at the right time.<br />
<br />
= Transportation =<br />
<br />
'''Quick Tips'''<br />
* Talk to cabbies. Not only do they know their city, they are less likely to have kickbacks in place than the hotel concierge, more likely to give you good answers.<br />
* Learn the taxi rules. Las Vegas doesn’t let you hail cabs on the street (creates traffic problems). New York cabs have credit card swipes in the back seat, whereas DC cabs just started actually using their meters at all. San Francisco cabs won’t let you exit except curbside.<br />
<br />
Still to write:<br />
* public transit<br />
* hotel shuttles<br />
<br />
== Rental Cars ==<br />
<br />
=== Enterprise Rent-a-Car ===<br />
<br />
Mozilla's preferred vendor<br />
<br />
=== Hertz ===<br />
<br />
If for some reason you end up with Hertz (late evening arrivals mean Enterprise might be closed) you'll want to sign up for [[HertzBusinessAccountProgram|Hertz #1 Gold]] and use that. At most airports, you walk in, your name is on a board with a parking spot number, and the keys and contract are already in the car waiting for you. Really nice after a 5+ hour flight!<br />
<br />
= Eating =<br />
<br />
Eat like a local.<br />
<br />
Never ask the front desk at your hotel for a dinner recommendation. If possible, ask anyone else to weigh in. The bellhop, your taxi driver, the barista at Starbucks, Yelp, Chowhound, etc. The best recommendations come from people who are actually living and working in the area. The concierge at the hotel will always orient toward broad, tourist-pacifying tastes. The food will be edible, but forgettable. They'll never tell you about the super tasty hole-in-the-wall joint three blocks away.<br />
<br />
= Staying healthy =<br />
* Wash hands frequently! <br />
* Carry and use hand-sanitizer wipes. (A bottle of hand-sanitizer gel takes up valuable room in your liquids bag.) Sanitize your hands in-flight before you eat or drink, and after washing your hands in the lavatory (on-board water, again). Also use them to wipe off [http://www.travelmath.com/feature/airline-hygiene-exposed/ tray tables, seatbelt buckles, and air vents], where germs lurk on airplanes.<br />
* Set the fan above your seat on the plane to low or medium, and position it to blow into your lap, just in front of your face. This will help knock airborne pathogens out of the air, so you'll be less likely to breathe them in. ([http://www.npr.org/blogs/goatsandsoda/2014/07/14/319194689/pathogens-on-a-plane-how-to-stay-healthy-in-flight?ft=1 (NPR) Pathogens on a plane: how to stay healthy in flight])<br />
* Keep your exercise routine as much as possible. Exercise burns calories, relieves stress, and helps reset your body clock, if you're in a different time zone.<br />
** Pick a hotel that has a fitness center. If you must use a hotel that doesn't have one (or you need specific equipment, like a stationary bike) call and ask; they may have an arrangement with a nearby gym.<br />
** If you're out of luck on the fitness center, bring an exercise DVD, and/or small lightweight equipment like a jump rope or tension bands. Or do a [http://well.blogs.nytimes.com/2013/05/09/the-scientific-7-minute-workout/ body-weight-only exercise routine].<br />
** Bring quick-drying workout clothes. Rinse them in the shower, and dry them over the shower rod, so they're ready for tomorrow.<br />
** Bring athletic shoes that double as casual street shoes, so you don't need to take up luggage space with extra shoes.<br />
** See the Quartz [http://qz.com/287800/the-complete-guide-to-staying-in-shape-on-the-road/ Complete guide to staying in shape on the road].<br />
<br />
= Redux =<br />
<br />
'''Most people travel infrequently, and aren’t very skilled at it...'''<br />
* and there are a lot of people, so despite the infrequency of their travel, the Don’t Know path is very crowded<br />
* Businesses on the Don’t Know path have no loyalty to you (since infrequent travellers have no meaningful loyalty to them) so their main goal is to extract money from you immediately, even at the cost of the relationship<br />
* People on the Don’t Know path have to deal with the same Don’t Know problems every single day, which is exhausting and saps their empathy<br />
<br />
'''BUT - If you know what you’re doing...'''<br />
* You can shortcut around the Don’t Know path everywhere. Airports, Hotels, Restaurants<br />
* The businesses you deal with will view you as a regular, and want to keep you happy<br />
* The people you deal with will view you as a breath of fresh air, and feel understood, and be grateful and human in the ways that travel never is for others.<br />
<br />
= More advice =<br />
* [http://www.jonobacon.org/2016/08/10/the-bacon-travel-survival-guide/ Travel Survival Guide] by Jono Bacon<br />
These podcasts have some excellent advice on business travel:<br />
* [http://www.manager-tools.com/2009/07/airline-travel-basics-1-part-1 Airline Travel Basics, part 1]<br />
* [http://www.manager-tools.com/2009/08/airline-travel-basics-1-part-2 Airline Travel Basics, part 2]<br />
* [http://www.manager-tools.com/2008/08/business-travel-packing Business Travel Packing]<br />
* [http://www.manager-tools.com/2009/07/travel-airline-seats Travel - Airline Seats]<br />
<br />
The what and how of packing only a carry-on: [http://www.onebag.com/ Onebag.com]</div>Dbaronhttps://wiki.mozilla.org/index.php?title=Modules/Core&diff=1174847Modules/Core2017-06-30T19:36:41Z<p>Dbaron: adjust peers of string module</p>
<hr />
<div><noinclude><br />
'''Only module owners may edit this page.''' <br />
<br />
They may:<br />
<br />
* update any information about their module except the name of the owner<br />
* add or remove sub-modules<br />
* change the owner of a sub-module <br />
* add emeritus owners or peers<br />
<br />
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].<br />
</noinclude><br />
{{Module<br />
|name=Accessibility<br />
|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.<br />
|owner=[mailto:surkov.alexander@gmail.com Alexander Surkov]<br />
|peers=[mailto:dbolter@mozilla.com David Bolter], [mailto:eitan@monotonous.org Eitan Isaacson],[mailto:tbsaunde+mozbugs@tbsaunde.org Trevor Saunders], [mailto:mzehe@mozilla.com Marco Zehe], [mailto:yzenevich@mozilla.com Yura Zenevich]<br />
|ownersemeritus=[mailto:aaron@moonset.net. Aaron Leventhal]<br />
|peersemeritus=[mailto:ginn.chen@oracle.com Ginn Chen], Evan Yan<br />
|group=dev-accessibility<br />
|source_dirs=accessible/<br />
|url=http://www.mozilla.org/access/<br />
|components=Core::Disability Access APIs<br />
}}<br />
<br />
{{Module<br />
|name=Browser WebAPI<br />
|description=Web API for rendering apps, browser windows and widgets.<br />
|owner=[mailto:kchen@mozilla.com Kan-Ru Chen]<br />
|peers=[mailto:Olli.Pettay@helsinki.fi Olli Pettay], [mailto:fabrice@mozilla.com Fabrice Desré]<br />
|group=dev-webapi<br />
|source_dirs=dom/browser-element/<br />
|url=<br />
|components=Core::DOM<br />
}}<br />
<br />
{{Module<br />
|name=Build and Release Tools<br />
|description=Tools related to build and release automation and configuration of release builds.<br />
|owner=[mailto:nthomas@mozilla.com Nick Thomas]<br />
|peers=[mailto:bhearsum@mozilla.com Ben Hearsum], [mailto:coop@mozilla.com Chris Cooper]<br />
|group=release-engineering<br />
|source_dirs=browser/config/mozconfigs/, mobile/android/config/mozconfigs/, xulrunner/config/mozconfigs/, b2g/config/, tools/update-packaging/<br />
|url=https://wiki.mozilla.org/ReleaseEngineering<br />
|components=Release Engineering::*<br />
}}<br />
<br />
{{Module<br />
|name=Build Config<br />
|description=The build system for Gecko and several mozilla.org hosted Gecko-based applications.<br />
|owner=[mailto:gps@mozilla.com Gregory Szorc] (:gps)<br />
|peers=[mailto:mh@glandium.org Mike Hommey] (:glandium), [mailto:mshal@mozilla.com Mike Shal] (:mshal), [mailto:ted@mielczarek.org Ted Mielczarek] (:ted), [mailto:cmanchester@mozilla.com Chris Manchester](:chmanchester), [mailto:nfroyd@mozilla.com Nathan Froyd] (:froydnj), [mailto:rgiles@mozilla.com Ralph Giles] (:rillian)<br />
|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]), <br />
|group=dev-builds<br />
|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/<br />
|url=http://www.mozilla.org/build/<br />
|components=Core::Build Config<br />
}}<br />
<br />
{{Module<br />
|name=Code Analysis and Debugging Tools<br />
|description=Tools for debugging Mozilla code or for analyzing speed, memory use, and other characteristics of it.<br />
|owner=[mailto:dbaron@dbaron.org David Baron]<br />
|peers=<br />
|group=dev-performance<br />
|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/, <br />
|url=<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=Content HTTP Headers<br />
|description=HTTP headers related to content, e.g. User-Agent, Content-Type, Accept. (Transport-related headers are the responsibility of the Necko module owner.)<br />
|owner=[mailto:gerv@mozilla.org Gervase Markham]<br />
|peers=[mailto:lmandel@mozilla.com Lawrence Mandel]<br />
|group=dev-platform<br />
|source_dirs= <br />
|url=https://developer.mozilla.org/en/Gecko_user_agent_string_reference<br />
|components=Core::Networking: HTTP<br />
}}<br />
<br />
{{Module<br />
|name=Content Security<br />
|description=Native content-based security features, including: Content Security Policy (CSP), Mixed Content Blocker (MCB), Subresource Integrity (SRI) and CORS.<br />
|owner=[mailto:ckerschbaumer@mozilla.com Christoph Kerschbaumer]<br />
|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] <br />
|group=dev-security<br />
|source_dirs=dom/security<br />
|components=Core::DOM: Security<br />
}}<br />
<br />
{{Module<br />
|name=Cookies and Permissions<br />
|description=<br />
|owner=Monica Chew<br />
|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)]<br />
|group=dev-tech-network<br />
|source_dirs=extensions/cookie/, netwerk/cookie/<br />
|url=<br />
|components=Core::Networking: Cookies<br />
}}<br />
{{Module<br />
|name=Cycle Collector<br />
|description=Code to break and collect objects within reference cycles<br />
|owner=[https://mozillians.org/en-US/u/mccr8/ Andrew McCreight]<br />
|peers=Peter Van der Beken, Olli Pettay, David Baron<br />
|source_dirs=xpcom/base/nsCycleCollector.* and some support headers<br />
|components=Core::XPCOM<br />
|group=dev-platform<br />
}}<br />
{{Module<br />
|name=C++/Rust usage, tools, and style<br />
|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<br />
|owner=[mailto:ehsan@mozilla.com Ehsan Akhgari]<br />
|peers=[mailto:bballo@mozilla.com Botond Ballo], [mailto:nfroyd@mozilla.com Nathan Froyd], [mailto:glandium@mozilla.com Mike Hommey], [mailto:jwalden@mozilla.com Jeff Walden]<br />
|source_dirs=non-third-party C++ and Rust code in the tree<br />
|components=Various components<br />
|group=dev-platform<br />
}}<br />
{{Module<br />
|name=docshell<br />
|description=<br />
|owner=[mailto:bzbarsky@mit.edu Boris Zbarsky]<br />
|peers=[mailto:cbiesinger@gmail.com Christian Biesinger], [mailto:Olli.Pettay@helsinki.fi Olli Pettay], [mailto:justin.lebar@gmail.com Justin Lebar]<br />
|peersemeritus=[mailto:jstenback@gmail.com Johnny Stenback]<br />
|group=dev-tech-layout<br />
|source_dirs=docshell/, uriloader/<br />
|url=<br />
|components=Core::Document Navigation<br />
}}<br />
<br />
{{Module<br />
|name=Document Object Model<br />
|description=<br />
|owner=[mailto:peterv@propagandism.org Peter Van der Beken]<br />
|peers=[mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:jonas@sicking.cc Jonas Sicking], [mailto:Olli.Pettay@helsinki.fi Olli Pettay], [mailto:bent.mozilla@gmail.com Ben Turner], [mailto:mounir@lamouri.fr Mounir Lamouri (still active, but slower to respond than previously)], [mailto:me@kylehuey.com Kyle Huey], [mailto:hsivonen@iki.fi Henri Sivonen], [mailto:mrbkap@gmail.com Blake Kaplan], [mailto:bobbyholley@gmail.com Bobby Holley], [mailto:baku@mozilla.com Andrea Marchesini],<br />
[mailto:ehsan@mozilla.com Ehsan Akhgari], [mailto:bkelly@mozilla.com Ben Kelly], [mailto:billm@mozilla.com Bill McCloskey], [mailto:kyle@nonpolynomial.com Kyle Machulis]<br />
|ownersemeritus=[mailto:jstenback@gmail.com Johnny Stenback]<br />
|peersemeritus=[mailto:justin.lebar@gmail.com Justin Lebar]<br />
|group=dev-tech-dom<br />
|source_dirs=dom/*, except directories covered by other modules<br />
|url=http://developer.mozilla.org/en/docs/DOM<br />
|components=Core::DOM, Core::DOM: CSS Object Model, Core::DOM: Core & HTML<br />
}}<br />
<br />
{{Module<br />
|name=DOM File<br />
|description=DOM Blob, File and FileSystem APIs <br />
|owner=[mailto:amarchesini@Mozilla.com Andrea Marchesini]<br />
|peers=[mailto:olli@pettay.fi Olli Pettay]<br />
|group=dev-platform<br />
|source_dirs=dom/file, dom/filesystem<br />
|url=http://developer.mozilla.org/en/docs/DOM<br />
|components=Core::DOM: File<br />
}}<br />
<br />
{{Module<br />
|name=Event Handling<br />
|description=DOM Events and Event Handling <br />
|owner=[mailto:olli@pettay.fi Olli Pettay], [mailto:masayuki@d-toybox.com Masayuki Nakano]<br />
|group=dev-platform<br />
|source_dirs=dom/events and event handling related code elsewhere <br />
|url=http://developer.mozilla.org/en/docs/DOM<br />
|components=Core::DOM: Events, Core::Event Handling<br />
}}<br />
<br />
{{Module<br />
|name=Web Workers<br />
|description=<br />
|owner=[mailto:baku@mozilla.com Andrea Marchesini]<br />
|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]<br />
|ownersemeritus=[mailto:bent.mozilla@gmail.com Ben Turner]<br />
|group=dev-platform<br />
|source_dirs=dom/workers/<br />
|url=https://developer.mozilla.org/En/Using_web_workers<br />
|components=Core::DOM: Workers<br />
}}<br />
<br />
{{Module<br />
|name=IndexedDB<br />
|description=<br />
|owner=[mailto:jvarga@mozilla.com Jan Varga]<br />
|peers=[mailto:btseng@mozilla.com Bevis Tseng]<br />
|ownersemeritus=[mailto:bent.mozilla@gmail.com Ben Turner]<br />
|peersemeritus=[mailto:jonas@sicking.cc Jonas Sicking], [mailto:me@kylehuey.com Kyle Huey]<br />
|group=dev-platform<br />
|source_dirs=dom/indexedDB/<br />
|url=https://developer.mozilla.org/en/IndexedDB<br />
|components=Core::DOM: IndexedDB<br />
}}<br />
<br />
{{Module<br />
|name=Editor<br />
|description=<br />
|owner=[mailto:masayuki@d-toybox.com Masayuki Nakano]<br />
|peers=[mailto:ayg@aryeh.name Aryeh Gregor]<br />
|ownersemeritus=[mailto:ehsan@mozilla.com Ehsan Akhgari]<br />
|group=dev-platform<br />
|source_dirs=editor/<br />
|url=http://www.mozilla.org/editor/<br />
|components=Core::Editor<br />
}}<br />
<br />
{{Module<br />
|name=Embedding<br />
|description=Gecko embedding APIs and frameworks<br />
|owner=[mailto:myk@mykzilla.org Myk Melez]<br />
|ownersemeritus=[mailto:benjamin@smedbergs.us Benjamin Smedberg], [mailto:doug.turner@gmail.com Doug Turner]<br />
|peers=[mailto:bdahl@mozilla.com Brendan Dahl], [mailto:tbsaunde@tbsaunde.org Trevor Saunders]<br />
|peersemeritus=[mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:jstenback@gmail.com Johnny Stenback]<br />
|group=dev-platform<br />
|source_dirs=embedding/<br />
|url=<br />
|components=Core::Embedding: APIs<br />
}}<br />
<br />
{{Module<br />
|name=Find As You Type<br />
|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.<br />
|owner=<br />
|peers=<br />
|group=dev-accessibility<br />
|source_dirs=extensions/typeaheadfind/<br />
|url=http://www.mozilla.org/access/type-ahead/<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=Gecko Profiler<br />
|description=Gecko's built-in profiler<br />
|owner=[mailto:mstange@themasta.com Markus Stange]<br />
|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].<br />
|group=dev-platform<br />
|source_dirs=tools/profiler/<br />
|url=https://developer.mozilla.org/en-US/docs/Mozilla/Performance/Profiling_with_the_Built-in_Profiler<br />
|components=Core::Gecko Profiler<br />
}}<br />
<br />
{{Module<br />
|name=Geolocation<br />
|description=Implementation of the Geolocation W3C Spec, location provider apis, and wifi scanning code.<br />
|owner=[mailto:josh@joshmatthews.net Josh Matthews], [mailto:kchen@mozilla.com Kan-Ru Chen]<br />
|ownersemeritus=[mailto:doug.turner@gmail.com Doug Turner], Garvan Keeley<br />
|peers=<br />
|group=dev-tech-dom<br />
|source_dirs=dom/geolocation, dom/system/, netwerk/wifi<br />
|url=https://developer.mozilla.org/En/Using_geolocation<br />
|components=Core::Geolocation<br />
}}<br />
<br />
{{Module<br />
|name=Global Key Bindings<br />
|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.<br />
|owner=Aaron Leventhal<br />
|peers=[mailto:neil@parkwaycc.co.uk Neil Rashbrook]<br />
|group=dev-accessibility<br />
|source_dirs=dom/xbl/builtin/<br />
|url=http://www.mozilla.org/projects/ui/accessibility/mozkeyintro.html<br />
|components=Core::Keyboard: Navigation<br />
}}<br />
<br />
{{Module<br />
|name=Graphics<br />
|description=Mozilla graphics API<br />
|owner=[mailto:jrmuizel@mozilla.com Jeff Muizelaar](Thebes, QCMS, YCbCr, Cairo/Pixman, Regions, OS X, Other)<br />
|ownersemeritus=[mailto:robert@ocallahan.org Robert O'Callahan]<br />
|peers=[mailto:jdrew@mozilla.com Joe Drew], [mailto:vladimir@pobox.com Vladimir Vukicevic], [mailto:bas.schouten@live.nl Bas Schouten](Layers, Windows), [mailto:bjacob@mozilla.com Benoit Jacob](gfx/gl), [mailto:bgirard@mozilla.com Benoit Girard](Compositor, Performance), [mailto:ajuma.bugzilla@alijuma.com Ali Juma], [mailto:jgilbert@mozilla.com Jeff Gilbert](WebGL, ANGLE), [mailto:george@mozilla.com George Wright](Canvas2D, Skia), [mailto:mwoodrow@mozilla.com Matt Woodrow](Layers API), [mailto:jdaggett@mozilla.com John Daggett](text/fonts), [mailto:jfkthame@googlemail.com Jonathan Kew](text/fonts), [mailto:nsilva@mozilla.com Nicolas Silva](MozSurface), [mailto:ncameron@mozilla.com Nick Cameron], [mailto:sikeda@mozilla.com Sotaro Ikeda](B2G), [mailto:snorp@mozilla.com James Willcox](Android), [mailto:clord@mozilla.com Christopher Lord], [mailto:mstange@themasta.com Markus Stange](OS X), [mailto:lsalzman@mozilla.com Lee Salzman], [mailto:mchang@mozilla.com Mason Chang], [mailto:dvander@mozilla.com David Anderson]<br />
|group=dev-platform<br />
|source_dirs=gfx/, dom/canvas/<br />
|url=https://wiki.mozilla.org/Platform/GFX https://wiki.mozilla.org/Gecko:Layers https://wiki.mozilla.org/Gecko:2DGraphicsSketch<br />
|components=Core::Graphics, Core::Graphics: Layers, Core::Graphics: Text, Core::GFX: Color Management, Core::Canvas: 2D, Core::Canvas: WebGL<br />
}}<br />
<br />
{{Module<br />
|name=APZ (Graphics submodule)<br />
|description=Asynchronous panning and zooming<br />
|owner=[mailto:kgupta@mozilla.com Kartikaya Gupta]<br />
|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]<br />
|group=dev-platform<br />
|source=gfx/layers/apz<br />
|url=https://wiki.mozilla.org/Platform/GFX/APZ<br />
|components=Core::Panning and Zooming<br />
}}<br />
<br />
{{Module<br />
|name=Moz2D (Graphics submodule)<br />
|description=Platform independent 2D graphics API<br />
|owner=[mailto:bschouten@mozilla.com Bas Schouten]<br />
|peers=[mailto:jmuizelaar@mozilla.com Jeff Muizelaar], [mailto:gwright@mozilla.com George Wright], [mailto:jwatt@mozilla.com Jonathan Watt]<br />
|group=dev-platform<br />
|source=gfx/2d<br />
|url=https://wiki.mozilla.org/Platform/GFX/Moz2D<br />
|components=Core::Graphics<br />
}}<br />
<br />
{{Module<br />
|name=Legacy HTML Parser<br />
|description=<br />
|owner=[mailto:mrbkap@gmail.com Blake Kaplan]<br />
|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]<br />
|peersemeritus=[mailto:jstenback@gmail.com Johnny Stenback]<br />
|source_dirs=parser/htmlparser<br />
|url=http://www.mozilla.org/newlayout/doc/parser.html<br />
|components=Core::HTML: Parser<br />
}}<br />
<br />
{{Module<br />
|name=HAL<br />
|description=Hardware Abstraction Layer<br />
|owner=[https://mozillians.org/u/dhylands/ Dave Hylands]<br />
|peers=[mailto:gsvelto@mozilla.com Gabriele Svelto]<br />
|group=dev-platform<br />
|source_dirs=hal/<br />
|components=Core::Hardware Abstraction Layer (HAL)<br />
}}<br />
<br />
{{Module<br />
|name=HTML Parser<br />
|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++.<br />
|owner=[mailto:hsivonen@iki.fi Henri Sivonen]<br />
|peers=[mailto:wchen@mozilla.com William Chen]<br />
|group=dev-platform<br />
|source_dirs=parser/html<br />
|url=http://about.validator.nu/<br />
|components=Core::HTML: Parser<br />
}}<br />
<br />
{{Module<br />
|name=I18N Library<br />
|description=<br />
|owner=[mailto:jshin1987@gmail.com Jungshik Shin], [mailto:smontagu@smontagu.org Simon Montagu]<br />
|peers=[mailto:VYV03354@nifty.ne.jp Masatoshi Kimura]<br />
|group=dev-i18n<br />
|source_dirs=intl/<br />
|url=http://mozilla.org/projects/intl/index.html<br />
|components=Core::Internationalization<br />
}}<br />
<br />
{{Module<br />
|name=ImageLib<br />
|description=<br />
|owner=[mailto:tnikkel@gmail.com Timothy Nikkel]<br />
|peers=[mailto:aosmond@mozilla.com Andrew Osmond], [mailto:jmuizelaar@mozilla.com Jeff Muizelaar], [mailto:seth.bugzilla@blackhail.net Seth Fowler]<br />
|peersemeritus=[mailto:netzen@gmail.com Brian Bondy], [mailto:justin.lebar@gmail.com Justin Lebar]<br />
|group=dev-platform<br />
|source_dirs=media/libjpeg/, media/libpng/, image/, modules/zlib/<br />
|url=<br />
|components=Core::ImageLib<br />
}}<br />
<br />
{{Module<br />
|name=IPC<br />
|description=Message-passing between threads and processes<br />
|owner=[mailto:wmccloskey@mozilla.com Bill McCloskey]<br />
|peers=[mailto:danderson@mozilla.com David Anderson], [mailto:jld@mozilla.com Jed Davis], [mailto:kchen@mozilla.com Kan-Ru Chen]<br />
|group=dev-platform<br />
|source_dirs=ipc/glue/, ipc/ipdl/, ipc/chromium/<br />
|url=<br />
|components=Core::IPC}}<br />
<br />
{{Module<br />
|name=JavaScript<br />
|description=JavaScript engine (SpiderMonkey)<br />
|owner=[mailto:jorendorff@mozilla.com Jason Orendorff]<br />
|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<br />
|group=dev-tech-js-engine<br />
|source_dirs=js/src<br />
|url=http://www.mozilla.org/js/spidermonkey,<br />
http://developer.mozilla.org/en/docs/About_JavaScript<br />
|components=Core::JavaScript Engine<br />
}}<br />
<br />
{{Module<br />
|name=JavaScript JIT<br />
|description=JavaScript engine's JIT compilers (IonMonkey, Baseline)<br />
|owner=[mailto:jdemooij@mozilla.com Jan de Mooij]<br />
|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]<br />
|group=dev-tech-js-engine-internals<br />
|source_dirs=js/src/jit<br />
|url=http://www.mozilla.org/js/spidermonkey<br />
|components=Core::JavaScript Engine: JIT<br />
}}<br />
<br />
{{Module<br />
|name=JavaScript Debugger Backend<br />
|description=JavaScript debugging hooks<br />
|owner=[mailto:timeless@mozdev.org Josh 'timeless' Soref]<br />
|peers=[mailto:brendan@mozilla.org Brendan Eich], [mailto:rginda@hacksrus.com Rob Ginda]<br />
|group=dev-apps-js-debugger<br />
|source_dirs=js/jsd/<br />
|url=http://www.mozilla.org/js/jsd<br />
|components=Other Applications::Venkman JS Debugger<br />
}}<br />
<br />
{{Module<br />
|name=jsat<br />
|description=Javascript screen reader that is used in Android and B2G<br />
|owner=[mailto:eitan@monotonous.org Eitan Isaacson]<br />
|peers=[mailto:yzenevich@mozilla.com Yura Zenevich]<br />
|group=dev-accessibility<br />
|source_dirs=accessible/jsat/<br />
|url=http://www.mozilla.org/access/<br />
|components=Core::Disability Access APIs<br />
}}<br />
<br />
{{Module<br />
|name=js-ctypes<br />
|description=A foreign function interface which allows privileged JS code to interact with binary code without using XPCOM/XPConnect.<br />
|owner=[mailto:jorendorff@mozilla.com Jason Orendorff]<br />
|peers=[mailto:benjamin@smedbergs.us Benjamin Smedberg], [mailto:bobbyholley@gmail.com Bobby Holley]<br />
|group=dev-tech-js-engine<br />
|source_dirs=js/src/ctypes/<br />
|url=https://wiki.mozilla.org/JSctypes<br />
|components=Core::js-ctypes<br />
}}<br />
<br />
{{Module<br />
|name=js-tests<br />
|description=JavaScript test suite<br />
|owner=[mailto:bclary@bclary.com Bob Clary]<br />
|peers=<br />
|group=dev-tech-js-engine<br />
|source_dirs=js/tests/<br />
|url=http://www.mozilla.org/js/tests/library.html<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=Layout Engine<br />
|description=rendering tree construction, layout (reflow), etc.<br />
|owner=[mailto:dbaron@dbaron.org David Baron]<br />
|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]<br />
|group=dev-tech-layout<br />
|source_dirs=layout/%, layout/base/, layout/build/, layout/doc/, layout/forms/, layout/generic/, layout/html/, layout/printing/, layout/tables/, layout/tools/<br />
|url=http://mozilla.org/newlayout/doc/ ,<br />
http://lxr.mozilla.org/mozilla/source/layout/doc/<br />
|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<br />
}}<br />
<br />
{{Module<br />
|name=libjar<br />
|description=The JAR handling code (protocol handler, stream implementation, and zipreader/zipwriter).<br />
|owner=[mailto:mwu@mozilla.com Michael Wu]<br />
|peers=[mailto:aklotz@mozilla.com Aaron Klotz]<br />
|group=dev-platform<br />
|source_dirs=modules/libjar<br />
|url=<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=MathML<br />
|description=MathML is a low-level specification for describing mathematics which provides a foundation for the inclusion of mathematical expressions in Web pages.<br />
|owner=[mailto:karlt+@karlt.net Karl Tomlinson]<br />
|peers=[mailto:robert@ocallahan.org Robert O'Callahan]<br />
|group=dev-tech-mathml<br />
|source_dirs=layout/mathml/<br />
|url=http://www.mozilla.org/projects/mathml/<br />
|components=Core::MathML<br />
}}<br />
<br />
{{Module<br />
|name=Media Playback<br />
|description=HTML Media APIs, including Media Source Extensions and non-MSE video/audio element playback, and Encrypted Media Extensions. (WebRTC and WebAudio not included).<br />
|owner=[mailto:cpearce@mozilla.com Chris Pearce]<br />
|ownersemeritus=[mailto:robert@ocallahan.org Robert O'Callahan]<br />
|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]<br />
|group=dev-media<br />
|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/<br />
|url=<br />
|components=Core::Audio/Video<br />
}}<br />
<br />
{{Module<br />
|name=Media Transport<br />
|description=Pluggable transport for real-time media<br />
|owner=[mailto:ekr@rtfm.com Eric Rescorla]<br />
|peers=[mailto:bcampen@mozilla.com Byron Campen], [mailto:abr@mozilla.com Adam Roach], [mailto:nohlmeier@mozilla.com Nils Ohlmeier]<br />
|group=dev-media<br />
|source_dirs=media/mtransport<br />
|url=<br />
|components=Core::WebRTC::Networking<br />
}}<br />
<br />
{{Module<br />
|name=Memory Allocator<br />
|description=Most things related to memory allocation in Gecko, including jemalloc, replace-malloc, DMD (dark matter detector), logalloc, etc.<br />
|owner=[mailto:mh+mozilla@glandium.org Mike Hommey]<br />
|peers=[mailto:n.nethercote@gmail.com Nicholas Nethercote], [mailto:erahm@mozilla.com Eric Rahm]<br />
|group=dev-platform<br />
|source_dirs=memory/<br />
|components=Core::DMD, Core::jemalloc<br />
}}<br />
<br />
{{Module<br />
|name=mfbt<br />
|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).<br />
|owner=[mailto:jwalden@mit.edu Jeff Walden]<br />
|peers=[mailto:froydnj@mozilla.com Nathan Froyd], [mailto:Ms2ger@gmail.com Ms2ger], [mailto:mh+mozilla@glandium.org Mike Hommey]<br />
|group=dev-platform<br />
|source_dirs=mfbt/<br />
|url=<br />
|components=Core::MFBT<br />
}}<br />
<br />
{{Module<br />
|name=mozApps API & UI<br />
|description=Implementation of the navigator.mozApps API<br />
|owner=[mailto:fabrice@mozilla.com Fabrice Desré], [mailto:ehsan@mozilla.com Ehsan Akhgari]<br />
|peers=[mailto:myk@mozilla.org Myk Melez], [mailto:mar.castelluccio@studenti.unina.it Marco Castelluccio], [mailto:ferjmoreno@gmail.com Fernando Jiménez]<br />
|group=dev-webapi<br />
|source_dirs=dom/apps/, dom/interfaces/apps, product specific files implementing UI hooks.<br />
|url=<br />
|components=Core::DOM: Apps<br />
}}<br />
<br />
{{Module<br />
|name=Mozglue<br />
|description=Glue library containing various low-level functionality, including a dynamic linker for Android, a DLL block list for Windows, etc.<br />
|owner=[mailto:mh+mozilla@glandium.org Mike Hommey]<br />
|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)<br />
|group=dev-platform<br />
|source_dirs=mozglue/<br />
|components=Core::mozglue<br />
}}<br />
<br />
{{Module<br />
|name=mozilla-toplevel<br />
|description=The top level directory for the mozilla tree.<br />
|owner=[mailto:brendan@mozilla.org Brendan Eich]<br />
|peers=<br />
|group=<br />
|source_dirs=tools/README<br />
|url=<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=Necko<br />
|description=The Mozilla Networking Library<br />
|owner=[mailto:mcmanus@ducksong.com Patrick McManus]<br />
|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 ]<br />
|peersemeritus= [mailto:cbiesinger@gmail.com Christian Biesinger], [mailto:sworkman@mozilla.com Steve Workman], [mailto:bzbarsky@mit.edu Boris Zbarsky]<br />
|group=dev-tech-network<br />
|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/<br />
|url=http://www.mozilla.org/projects/netlib/, https://developer.mozilla.org/en/Necko<br />
|components=Core::Networking, Core::Networking: Cache, Core::Networking: Cookies, Core::Networking: FTP, Core::Networking: File, Core::Networking: HTTP, Core::Networking: JAR, Core::Networking: Websockets<br />
}}<br />
<br />
{{Module<br />
|name=NSPR<br />
|description=Netscape Portable Runtime<br />
|owner=[mailto:kaie@kuix.de Kai Engert]<br />
|peers=[mailto:wtc@google.com Wan-Teh Chang], [mailto:mh@glandium.org Mike Hommey]<br />
|group=dev-tech-nspr<br />
|source_dirs=nsprpub/<br />
|url=http://www.mozilla.org/projects/nspr/<br />
http://www.mozilla.org/projects/nspr/reference/html/<br />
http://www.mozilla.org/projects/nspr/release-notes/<br />
|components=NSPR<br />
}}<br />
<br />
{{Module<br />
|name=PDF<br />
|description=Rendering code to display documents encoded in the ISO 32000-1 `PDF' format.<br />
|owner=Chris Jones, Andreas Gal<br />
|peers=[mailto:aadib@mozilla.com Artur Adib], [mailto:bdahl@mozilla.com Brendan Dahl], [mailto:vnicolas@mozilla.com Vivien Nicolas]<br />
|group=dev-platform<br />
|source_dirs=media/pdf/<br />
|url=https://github.com/mozilla/pdf.js<br />
|components=Core::PDF<br />
}}<br />
<br />
{{Module<br />
|name=Plugins<br />
|description= NPAPI Plugin support.<br />
|owner=[mailto:jmathies@mozilla.com Jim Mathies]<br />
|peers=[mailto:benjamin@smedbergs.us Benjamin Smedberg], [mailto:joshmoz@gmail.com Josh Aas]<br />
|peersemeritus=[mailto:john@pointysoftware.net John Schoenick], [mailto:robert@ocallahan.org Robert O'Callahan], [mailto:jstenback@gmail.com Johnny Stenback]<br />
|group=<br />
|source_dirs=dom/plugins/, modules/plugin/<br />
|url=https://wiki.mozilla.org/Plugins<br />
|components=Core::Plug-ins<br />
}}<br />
<br />
{{Module<br />
|name=Preferences<br />
|description=Preference library<br />
|owner=<br />
|peers=[mailto:benjamin@smedbergs.us Benjamin Smedberg]<br />
|group=dev-platform<br />
|source_dirs=modules/libpref/<br />
|url=<br />
|components=Core::Preferences: Backend<br />
}}<br />
<br />
{{Module<br />
|name=Private Browsing<br />
|description=Implementation of the Private Browsing mode, and the integration of other modules with Private Browsing APIs.<br />
|owner=[mailto:ehsan@mozilla.com Ehsan Akhgari]<br />
|peers=[mailto:josh@joshmatthews.net Josh Matthews]<br />
|group=dev-platform<br />
|source_dirs=Implementation and consumers of Private Browsing APIs in nsILoadContext, nsIPrivateBrowsingChannel, PrivateBrowsingUtils.jsm and the related glue code. <br />
|url=https://wiki.mozilla.org/Private_Browsing<br />
|components=Firefox::Private Browsing<br />
}}<br />
<br />
{{Module<br />
|name=Privilege Manager<br />
|description="caps"<br />
|owner=[mailto:bobbyholley@gmail.com Bobby Holley]<br />
|peers=[mailto:bzbarsky@mit.edu Boris Zbarsky]<br />
|peersemeritus=[mailto:brendan@mozilla.org Brendan Eich], [mailto:jstenback@gmail.com Johnny Stenback], [mailto:dveditz@mozilla.com Dan Veditz]<br />
|group=dev-tech-dom<br />
|source_dirs=caps/<br />
|url=http://www.mozilla.org/projects/security/components/index.html<br />
|components=Core::Security: CAPS<br />
}}<br />
<br />
{{Module<br />
|name=Push Notifications<br />
|description=Push is a way for application developers to send messages to their web applications.<br />
|owners=<br />
|ownersemeritus=[mailto:doug.turner@gmail.com Doug Turner]<br />
|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]<br />
|group=<br />
|source_dirs=dom/push, dom/simplepush<br />
|url=<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=PyXPCOM<br />
|description=The Python to XPCOM bridge.<br />
|owner=Todd Whiteman<br />
|peers=[mailto:mhammond@skippinet.com.au Mark Hammond]<br />
|group=<br />
|source_dirs=extension/python<br />
|url=https://developer.mozilla.org/en/PyXPCOM<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=RDF<br />
|description=<br />
|owner=[mailto:axel@pike.org Axel Hecht]<br />
|peers=[mailto:benjamin@smedbergs.us Benjamin Smedberg]<br />
|group=dev-tech-rdf<br />
|source_dirs=rdf/<br />
|url=http://www.mozilla.org/rdf/doc/<br />
|components=Core::RDF<br />
}}<br />
<br />
{{Module<br />
|name=security<br />
|description=Crypto/PKI code, including NSS (Network Security Services) and JSS (NSS for Java)<br />
|owner=[mailto:rrelyea@redhat.com Bob Relyea], [mailto:ttaubert@mozilla.com Tim Taubert]<br />
|peers=[mailto:emaldona@redhat.com Elio Maldonado], [mailto:kaie@kuix.de Kai Engert], [mailto:ryan.sleevi@gmail.com Ryan Sleevi], [mailto:ekr@rtfm.com Eric Rescorla], [mailto:franziskuskiefer@gmail.com Franziskus Kiefer], [mailto:martin.thomson@gmail.com Martin Thomson], [mailto:wtc@google.com Wan-Teh Chang]<br />
|group=dev-tech-crypto<br />
|source_dirs=dbm/, security/coreconf/, security/dbm/, security/jss/, security/nss/, security/tinderbox/, security/tinderlight/<br />
|url=http://mozilla.org/projects/security/pki/<br />
|components=NSS, JSS, Core::Security, Core::Security: S/MIME<br />
}}<br />
<br />
{{Module<br />
|name=Security - Mozilla PSM Glue<br />
|description=Personal Security Manager<br />
|owner=[mailto:dkeeler@mozilla.com David Keeler]<br />
|peers=[mailto:honzab.moz@firemni.cz Honza Bambas], [mailto:cykesiopka.bmo@gmail.com Cykesiopka]<br />
|group=dev-tech-crypto<br />
|source_dirs=security/manager/<br />
|url=<br />
|components=Core::Security: PSM, Core::Security: UI<br />
}}<br />
<br />
{{Module<br />
|name=Static analysis & rewriting for C++<br />
|description=Tools for checking C++ code looking for problems at compile time, plus tools for automated rewriting of C++ code.<br />
|owner=[mailto:ehsan@mozilla.com Ehsan Akhgari]<br />
|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]<br />
|group=dev-platform<br />
|source_dirs=build/clang-plugin, tools/rewriting among other out of tree tools<br />
|url=<br />
|components=Core::Rewriting & Analysis<br />
}}<br />
{{Module<br />
|name=storage<br />
|description=Storage APIs with a SQLite backend<br />
|owner=[mailto:mak77@bonardo.net Marco Bonardo]<br />
|peers=[mailto:bugmail@asutherland.org Andrew Sutherland], [mailto:jvarga@mozilla.com Jan Varga]<br />
|group=dev-platform<br />
|source_dirs=db/sqlite3/, storage/<br />
|url=http://developer.mozilla.org/en/docs/Storage<br />
|components=Toolkit::Storage, Core::SQL<br />
}}<br />
<br />
{{Module<br />
|name=String<br />
|description=<br />
|owner=[mailto:dbaron@dbaron.org David Baron]<br />
|peers=[https://mozillians.org/en-US/u/bsmedberg/ Benjamin Smedberg], [https://mozillians.org/en-US/u/froydnj/ Nathan Froyd], [mailto:erahm@mozilla.com Eric Rahm]<br />
|group=dev-tech-xpcom<br />
|source_dirs=string/, xpcom/string/<br />
|url=https://developer.mozilla.org/En/Mozilla_internal_string_guide<br />
|components=Core::String<br />
}}<br />
<br />
{{Module<br />
|name=Style System<br />
|description=CSS style sheet handling; style data computation<br />
|owner=[mailto:dbaron@dbaron.org David Baron]<br />
|peers=[mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:cam@mcc.id.au Cameron McCormack]<br />
|group=dev-tech-layout<br />
|source_dirs=layout/style/<br />
|url=https://wiki.mozilla.org/Gecko:Overview#Style_System<br />
|components=Core::CSS Parsing and Computation<br />
}}<br />
<br />
{{Module<br />
|name=SVG<br />
|description=Scalable Vector Graphics<br />
|owner=[mailto:jwatt@jwatt.org Jonathan Watt]<br />
|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]<br />
|group=dev-tech-svg<br />
|source_dirs=dom/svg/, layout/svg/, dom/smil/<br />
|url=https://developer.mozilla.org/en-US/docs/Web/SVG<br />
|components=Core::SVG<br />
}}<br />
<br />
{{Module<br />
|name=Tamarin<br />
|description=VM for ActionScript and JavaScript<br />
|owner=Edwin Smith, [mailto:jodyer@adobe.com Jeff Dyer]<br />
|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]<br />
|group=dev-tech-js-engine<br />
|source_dirs=js/tamarin<br />
|url=http://www.mozilla.org/projects/tamarin/<br />
http://wiki.mozilla.org/tamarin/<br />
http://hg.mozilla.org/tamarin-central/<br />
http://hg.mozilla.org/tamarin-tracing/<br />
|components=Tamarin<br />
}}<br />
<br />
{{Module<br />
|name=Test Harness<br />
|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.<br />
|owner=[mailto:ted@mielczarek.org Ted Mielczarek]<br />
|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), <br />
<br />
|group=dev-quality<br />
|source_dirs=/testing<br />
|url=http://wiki.mozilla.org/SoftwareTesting<br />
|components=Testing::General, Testing::Mochitest, Testing::Mochitest Chrome, Testing::Marionette, Testing::Mozmill, Testing::Reftest, Testing::XPCShell Harness, Testing::httpd.js<br />
}}<br />
<br />
{{Module<br />
|name=Testing Infrastructure<br />
|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<br />
|owner=[mailto:jmaher@mozilla.com Joel Maher]<br />
|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é]<br />
|group=dev-quality<br />
|source_dirs=testing/, tools/httptester/, tools/page-loader/, tools/test-harness/, tools/tests/, tools/testserver/, tools/testy/<br />
|url=http://wiki.mozilla.org/SoftwareTesting<br />
|components=Testing::Infrastructure<br />
}}<br />
<br />
{{Module<br />
|name=JS Marionette<br />
|description=NodeJS test harness, marionette client, and other utilities for running marionette tests (submodule of Test Infrastructure)<br />
|owner=[mailto:jlal@mozilla.com James Lal] <lightsofapollo>, [mailto:gaye@mozilla.com Gareth Aye] <gaye><br />
|peers=[mailto:aus@mozilla.com Ghislain "Aus" Lacroix] <auswerk><br />
|source_dirs=gaia/tests/jsmarionette<br />
|components=Testing::JSMarionette<br />
|group=dev-gaia<br />
}}<br />
<br />
{{Module<br />
|name=XPCShell Test Harness<br />
|description=The XPCShell Harness<br />
|owner=[mailto:ted@mielczarek.org Ted Mielczarek]<br />
|peers=[mailto:jmaher@mozilla.com Joel Maher]<br />
|source_dirs=testing/xpcshell<br />
|components=Testing::XPCShell Harness<br />
}}<br />
<br />
{{Module<br />
|name=Update Service<br />
|description=server code for Mozilla Update services (aus, addons, pfs)<br />
|owner=Mike Morgan<br />
|peers=[mailto:jscott@mozilla.com Justin Scott], [mailto:shaver@mozilla.org Mike Shaver], [mailto:wclouser@mozilla.com Will Clouser]<br />
|group=dev-amo<br />
|source_dirs=webtools/addons/, webtools/aus/, webtools/update/<br />
|url=http://wiki.mozilla.org/wiki/AMO<br />
|components=AUS::Administration, AUS::Systems<br />
}}<br />
<br />
{{Module<br />
|name=View System<br />
|description=The View Manager is responsible for handling "heavyweight" rendering (some clipping, compositing) and event handling tasks.<br />
|owner=[mailto:mstange@themasta.com Markus Stange]<br />
|ownersemeritus=[mailto:robert@ocallahan.org Robert O'Callahan]<br />
|peers=[mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:dbaron@dbaron.org David Baron]<br />
|group=dev-tech-layout<br />
|source_dirs=view/<br />
|url=<br />
|components=Core::Layout: View Rendering<br />
}}<br />
<br />
{{Module<br />
|name=Web Audio<br />
|description=Support for the W3C Web Audio API specification.<br />
|owner=[mailto:padenot@mozilla.com Paul Adenot]<br />
|ownersemeritus=[mailto:ehsan@mozilla.com Ehsan Akhgari]<br />
|peers=[mailto:robert@ocallahan.org Robert O'Callahan], [mailto:karlt+@karlt.net Karl Tomlinson]<br />
|group=dev-platform<br />
|source_dirs=dom/media/webaudio<br />
|url=https://wiki.mozilla.org/Web_Audio_API<br />
|components=Core::Web Audio<br />
}}<br />
<br />
{{Module<br />
|name=Web Painting<br />
|description=painting, display lists, and layer construction<br />
|owner=[mailto:matt.woodrow@gmail.com Matt Woodrow]<br />
|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]<br />
|group=dev-tech-layout<br />
|source_dirs= layout/painting, the display list and layer related methods on nsIFrame and its subclasses<br />
|url=http://mozilla.org/newlayout/doc/ ,<br />
http://lxr.mozilla.org/mozilla/source/layout/doc/<br />
|components=Core::Layout: Web Painting<br />
}}<br />
<br />
{{Module<br />
|name=WebRTC<br />
|description=WebRTC is responsible for realtime audio and video communication, as well as related issues like low-level camera and microphone access<br />
|owner=[mailto:rjesup@mozilla.com Randell Jesup]<br />
|peers=[mailto:ekr@mozilla.com Eric Rescorla], [mailto:bcampen@mozilla.com Byron Campen] [mailto:abr@mozilla.com Adam Roach]<br />
|peersemeritus=[mailto:ehugg@cisco.com Ethan Hugg]<br />
|group=dev-media<br />
|source_dirs=N/A (see submodules "WebRTC Media" and "WebRTC Signaling")<br />
|url=https://wiki.mozilla.org/Media/webrtc<br />
|components=Core::WebRTC<br />
}}<br />
<br />
{{Module<br />
|name=Widget<br />
|description=<br />
|owner=[mailto:vladimir@pobox.com Vladimir Vukicevic]<br />
|ownersemeritus=[mailto:robert@ocallahan.org Robert O'Callahan]<br />
|peersemeritus=[mailto:pavlov@pavlov.net Stuart Parmenter], <br />
|group=dev-platform<br />
|source_dirs=widget/, widget/xpwidgets/<br />
|url=<br />
|components=Core::Drag and Drop, Core::Widget, Core::Printing: Setup<br />
}}<br />
<br />
{{Module<br />
|name=Widget - Android<br />
|description=The Android Port<br />
|owner=[mailto:blassey.bugs@lassey.us Brad Lassey]<br />
|peers=[mailto:jwillcox@mozilla.com James Willcox]<br />
|group=dev-platforms-mobile<br />
|source_dirs=widget/android/, embedding/android<br />
|url=<br />
|components=Core::Widget: Android<br />
}}<br />
<br />
{{Module<br />
|name=Widget - GTK<br />
|description=supported X widgetry and gfx<br />
|owner=[mailto:karlt+@karlt.net Karl Tomlinson]<br />
|ownersemeritus=[mailto:robert@ocallahan.org Robert O'Callahan]<br />
|group=dev-platform<br />
|source_dirs=widget/gtk/, widget/gtk2/, widget/gtksuperwin/, widget/gtkxtbin/<br />
|url=http://www.mozilla.org/unix/, http://www.gtk.org, http://www.mozilla.org/ports/gtk/<br />
|components=Core::Widget: Gtk<br />
}}<br />
<br />
{{Module<br />
|name=Widget - OS X<br />
|description= Gecko's OS X compatibility layer.<br />
|owner=[mailto:mstange@themasta.com Markus Stange]<br />
|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]<br />
|group=dev-platform<br />
|source_dirs=widget/cocoa/<br />
|url=<br />
|components=Core::Widget: Cocoa<br />
}}<br />
<br />
{{Module<br />
|name=Widget - Windows<br />
|description=Windows widgets and desktop integration<br />
|owner=[mailto:jmathies@mozilla.com Jim Mathies]<br />
|peers=[mailto:neil@parkwaycc.co.uk Neil Rashbrook], [mailto:vladimir@pobox.com Vladimir Vukicevic], [mailto:jmathies@mozilla.com Jim Mathies]<br />
|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]<br />
|group=dev-platform<br />
|source_dirs=widget/windows/<br />
|url=<br />
|components=Core::Widget: Win32<br />
}}<br />
<br />
{{Module<br />
|name=XBL<br />
|description=eXtensible Binding Language<br />
|owner=[mailto:bzbarsky@mit.edu Boris Zbarsky]<br />
|peers=[mailto:mrbkap@gmail.com Blake Kaplan], [mailto:bobbyholley@gmail.com Bobby Holley], [mailto:jonas@sicking.cc Jonas Sicking]<br />
|ownersemeritus=[mailto:jonas@sicking.cc Jonas Sicking]<br />
|group=dev-tech-xbl<br />
|source_dirs=dom/xbl/<br />
|url=http://www.mozilla.org/projects/xbl/<br />
|components=Core::XBL<br />
}}<br />
<br />
{{Module<br />
|name=XML<br />
|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.<br />
|owner=[mailto:peterv@propagandism.org Peter Van der Beken]<br />
|peers=[mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:erahm@mozilla.com Eric Rahm]<br />
|peersemeritus=[mailto:jonas@sicking.cc Jonas Sicking], [mailto:jstenback@gmail.com Johnny Stenback]<br />
|group=dev-tech-xml<br />
|source_dirs=dom/xml/, extensions/xmlextras/, parser/expat/<br />
|url=http://www.mozilla.org/newlayout/xml/<br />
|components=Core::XML<br />
}}<br />
<br />
{{Module<br />
|name=XPApps<br />
|description=Cross-Platform Applications, mostly Navigator front end and application shell.<br />
|owner=[mailto:neil@parkwaycc.co.uk Neil Rashbrook]<br />
|peers=[mailto:dean_tessman@hotmail.com Dean Tessman], [mailto:timeless@mozdev.org Josh 'timeless' Soref]<br />
|group=dev-apps-seamonkey<br />
|source_dirs=xpfe/<br />
|url=http://www.mozilla.org/xpapps/<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=XPCOM<br />
|description=The cross-platform object model and core data structures.<br />
|owner=[https://mozillians.org/en-US/u/froydnj/ Nathan Froyd]<br />
|peers=[https://mozillians.org/en-US/u/bsmedberg/ Benjamin Smedberg], [mailto:erahm@mozilla.com Eric Rahm]<br />
|peersemeritus=[https://mozillians.org/en-US/u/dougt/ Doug Turner]<br />
|group=dev-platform<br />
|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/<br />
|url=http://developer.mozilla.org/en/XPCOM<br />
|components=Core::XPCOM<br />
}}<br />
<br />
{{Module<br />
|name=XPConnect<br />
|description=Deep Magic<br />
|owner=[mailto:bobbyholley@gmail.com Bobby Holley]<br />
|peers=[mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:peterv@propagandism.org Peter Van der Beken], [mailto:mrbkap@gmail.com Blake Kaplan], [mailto:gkrizsanits@mozilla.com Gabor Krizsanits], [mailto:amccreight@mozilla.com Andrew McCreight]<br />
|peersemeritus=[mailto:gal@uci.edu Andreas Gal], [mailto:jstenback@gmail.com Johnny Stenback]<br />
|group=<br />
|source_dirs=js/xpconnect/<br />
|url=<br />
|components=Core::XPConnect<br />
}}<br />
<br />
{{Module<br />
|name=XPIDL<br />
|description=Cross-platform IDL compiler; produces .h C++ header files and .xpt runtime type description files from .idl interface description files.<br />
|owner=[mailto:me@kylehuey.com Kyle Huey]<br />
|peersemeritus=[mailto:shaver@mozilla.org Mike Shaver], [mailto:timeless@mozdev.org Josh 'timeless' Soref]<br />
|group=dev-tech-xpcom<br />
|source_dirs=xpcom/typelib/<br />
|url=http://www.mozilla.org/scriptable/xpidl<br />
http://www.mozilla.org/scriptable<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=XPInstall<br />
|description=<br />
|owner=[mailto:dveditz@mozilla.com Dan Veditz]<br />
|peers=[mailto:benjamin@smedbergs.us Benjamin Smedberg]<br />
|group=dev-tech-xpinstall<br />
|source_dirs=xpinstall/<br />
|url=<br />
|components=Core::Installer: XPInstall Engine<br />
}}<br />
<br />
{{Module<br />
|name=xptcall<br />
|description=XPTCall - platform-specific assembly for calling and implementing arbitrary XPCOM interfaces.<br />
|owner=<br />
|ownersemeritus=[mailto:timeless@mozdev.org Josh 'timeless' Soref]<br />
|peers=[mailto:benjamin@smedbergs.us Benjamin Smedberg], [mailto:shaver@mozilla.org Mike Shaver]<br />
|group=dev-xpcom<br />
|source_dirs=xpcom/reflect/xptcall/<br />
|url=http://www.mozilla.org/scriptable/xptcall-faq.html<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=XPToolkit<br />
|description=Cross-platform user interface toolkit<br />
|owner=<br />
|peers=[mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:Jan.Varga@gmail.com Jan Varga]<br />
|group=dev-tech-xul<br />
|source_dirs=dom/xul/, layout/xul/<br />
|url=http://www.mozilla.org/xpfe/<br />
|components=Core::XP Toolkit/Widgets: Menus, Core::XP Toolkit/Widgets: XUL<br />
}}<br />
<br />
{{Module<br />
|name=XSLT Processor<br />
|description=XSLT transformations processor<br />
|owner=[mailto:peterv@propagandism.org Peter Van der Beken]<br />
|peers=[mailto:axel@pike.org Axel Hecht], [mailto:erahm@mozilla.com Eric Rahm]<br />
|peersemeritus=[mailto:jonas@sicking.cc Jonas Sicking]<br />
|group=dev-tech-xslt<br />
|source_dirs=dom/xslt/<br />
|url=http://www.mozilla.org/projects/xslt/, http://www.w3.org/TR/xslt.html<br />
|components=Core::XSLT<br />
}}<br />
<br />
{{Module<br />
|name=Sandboxing<br />
|description=Cross platform sandboxing<br />
|owner=[mailto:gcp@mozilla.com Gian-Carlo Pascutto]<br />
|peers=[mailto:bowen@mozilla.com Bob Owen], [mailto:aklotz@mozilla.com Aaron Klotz], [https://mozillians.org/en-US/u/TimAbraldes Tim Abraldes], [mailto:gDestuynder@mozilla.com Guillaume Destuynder], [mailto:jld@mozilla.com Jed Davis]<br />
|group=dev-platform <br />
|source_dirs=security/sandbox<br />
|url=https://wiki.mozilla.org/Security/Sandbox <br />
|components=Core::Security: Process Sandboxing<br />
}}<br />
<br />
{{Module<br />
|name=Sandboxing - Windows <br />
|description=Sandboxing for the Windows platform <br />
|owner=[mailto:bowen@mozilla.com Bob Owen]<br />
|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]<br />
|group=dev-platform<br />
|source_dirs=security/sandbox/win <br />
|url=https://wiki.mozilla.org/Security/Sandbox <br />
|components=Core::Security: Process Sandboxing<br />
}}<br />
<br />
{{Module<br />
|name=Sandboxing - OSX <br />
|description=Sandboxing for the OSX platform <br />
|owner=[mailto:haftandilian@mozilla.com Haik Aftandilian]<br />
|peers=<br />
|group=dev-platform <br />
|source_dirs=security/sandbox/mac <br />
|url=https://wiki.mozilla.org/Security/Sandbox <br />
|components=Core::Security: Process Sandboxing<br />
}}<br />
<br />
{{Module<br />
|name=Sandboxing - Linux & B2G<br />
|description=Sandboxing for the Linux & B2G platforms<br />
|owner=[mailto:jhector@mozilla.com Julian Hector]<br />
|peers=[mailto:jld@mozilla.com Jed Davis] [mailto:gcp@mozilla.com Gian-Carlo Pascutto]<br />
|group=dev-platform<br />
|source_dirs=security/sandbox/linux<br />
|url=https://wiki.mozilla.org/Security/Sandbox <br />
|components=Core::Security: Process Sandboxing<br />
}}<br />
<br />
===Submodules===<br />
{{Module<br />
|name=Build Config - Fennec<br />
|description=Submodule of the build config covering Fennec's build system in mobile/android.<br />
|owner=[mailto:nalexander@mozilla.com Nicholas Alexander]<br />
|peers=Same as Build Config<br />
|group=dev-builds<br />
|components=Core::Build Config<br />
}}<br />
<br />
{{Module<br />
|name=WebRTC Media<br />
|description=Submodule of WebRTC responsible for access to media input devices (microphones, cameras, screen capture), as well as realtime audiovisual codecs and packetization.<br />
|owner=[mailto:rjesup@mozilla.com Randell Jesup]<br />
|peers=[mailto:pkerr@mozilla.com Paul Kerr], [mailto:jib@mozilla.com Jan-Ivar Bruaroey]<br />
|peersemeritus=[mailto:ehugg@cisco.com Ethan Hugg]<br />
|group=dev-media<br />
|source_dirs=/media/webrtc, /dom/media/webrtc<br />
|url=https://wiki.mozilla.org/Media/webrtc<br />
|components=Core::WebRTC (Audio/Video)<br />
}}<br />
<br />
{{Module<br />
|name=WebRTC Signaling<br />
|description=Submodule of WebRTC responsible for implementation of PeerConnection API, WebRTC identity, and SDP/JSEP handling<br />
|owner=[mailto:bcampen@mozilla.com Byron Campen]<br />
|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]<br />
|peersemeritus=[mailto:ehugg@cisco.com Ethan Hugg]<br />
|group=dev-media<br />
|source_dirs=/media/webrtc/signaling/<br />
|url=https://wiki.mozilla.org/Media/webrtc<br />
|components=Core::WebRTC (Signaling)<br />
}}<br />
<br />
<br />
<noinclude><br />
<br />
===Unassigned Bugzilla Components===<br />
<br />
The following Bugzilla components in the Core project have not been assigned to a module (this list is not exhaustive):<br />
<br />
<pre><br />
Core::File Handling<br />
Core::Find Backend<br />
Core::Gecko Profiler<br />
Core::General<br />
Core::HTML: Form Submission<br />
Core::History: Global<br />
Core::Image Blocking<br />
Core::JavaScript Debugging APIs<br />
Core::Localization<br />
Core::Nanojit<br />
Core::Networking: Domain Lists<br />
Core::Print Preview<br />
Core::Printing: Output<br />
Core::Printing: Setup<br />
Core::Profile: BackEnd<br />
Core::Profile: Migration<br />
Core::Profile: Roaming<br />
Core::QuickLaunch (AKA turbo mode)<br />
Core::Rewriting and Analysis<br />
Core::Selection<br />
Core::Serializers<br />
Core::Spelling checker<br />
Core::Tracking<br />
Core::Web Services<br />
Core::WebDAV<br />
Core::Widget: OS/2<br />
Core::Widget: Photon<br />
Core::X-remote<br />
Core::XForms<br />
Core::XUL<br />
</pre><br />
</noinclude></div>Dbaronhttps://wiki.mozilla.org/index.php?title=All_Hands/SanFrancisco2017&diff=1174365All Hands/SanFrancisco20172017-06-21T21:30:26Z<p>Dbaron: link to SFMTA info about Pride Parade closures/reroutes</p>
<hr />
<div>'''What is it?''' -- Multiple team meetings, happening in the same city, at the same time + some opportunity to get together as one big group as well as with other teams as it makes sense. Then, on the last day, we have a fun social event for all, Mozilla-style! <br />
<br />
'''''The information on this wiki primarily applies to Full time and contractor staff. If you are a volunteer contributor or intern, please inquire to your coordinator. '''''<br />
<br />
=='''Dates, Location and Weather'''==<br />
Monday, June 26 - Friday, June 30, 2017 (travel days are Monday the 26th & Saturday the 1st*) in San Francisco, CA.<br />
<br />
We are staying at [http://www3.hilton.com/en/hotels/california/hilton-san-francisco-union-square-SFOFHHH/index.html Hilton San Francisco Union Square] & [http://www.parc55hotel.com/ Parc 55] San Francisco. [https://osm.org/go/TZHvW7Hnn?m=&node=1941537172 map]<br />
<br />
''*For those countries where rest time is required on weekends (vs. work travel), Mozilla will cover a return on the next available work day, if you choose. This needs to pre-approved and pre-arranged.''<br />
<br />
Weather:<br />
* National Weather Service: [http://forecast.weather.gov/MapClick.php?smap=1&lat=37.785&lon=-122.410&unit=1&mp=1 forecast in ⁰C], [http://forecast.weather.gov/MapClick.php?smap=1&lat=37.785&lon=-122.410&mp=1 forecast in ⁰F]<br />
* Temperatures ''in downtown San Francisco'' in late June are likely to have nighttime lows around 10-13 ⁰C / 50-56 ⁰F and daytime highs around 16-24 ⁰C / 61-75 ⁰F. But the weather is very occasionally warmer with highs around 27⁰C / 81⁰F.<br />
* Weather in San Francisco in the summer is variable; it can become substantially cooler and foggier in the late afternoon; be prepared for temperatures to fall to 13⁰C / 56⁰F and the winds to pick up in the afternoon. Be prepared by carrying a warmer layer with you.<br />
* Weather in other parts of the Bay Area can be much warmer than in San Francisco, even if you're only traveling 15km away. Look at the weather forecasts for where you're going. It's entirely possible for it to be 19⁰C / 66⁰F in San Francisco and simultaneously be 32⁰C / 90⁰F in Orinda. But if you're right on the ocean, the air temperature is likely to match the water temperature, which is probably around 12⁰C / 54⁰F.<br />
<br />
=='''Registration'''==<br />
This is an invite-only event.<br />
<br />
Advance registration is required. Attendees will need to wear their event badge at all times, including to evening events. We will have increased security at our events who will be ensuring everyone in our space should be there. <br />
<br />
=====New Hires=====<br />
We have a process to identify new hires each Monday and will invite them to book travel. No action necessary from managers other than to let them know about the event. Please work closely with your recruiting manager as they are aware of all deadlines.<br />
<br />
==== Contributors participation ====<br />
The process for nominating volunteers is outlined here: [[All Hands/SanFrancisco/Volunteers Nominations|Volunteers nomination]].<br />
<br />
=='''[https://docs.google.com/spreadsheets/d/1Yp4oGPlpqdXJcsnLjuYP5UwaNGWR8_f5I_YkVH0ljcw/edit#gid=0 Week at a Glance]'''==<br />
=====Monday=====<br />
Monday is primarily your travel day. You'll be able to pick up your registration stuff between 12:00 pm and 9:00 pm, as well as attend the Welcome Reception at the Hilton from 6:00 pm - 9:00 pm. <br />
<br />
=====Tuesday, Wednesday & Thursday=====<br />
These days are team-focused days. Check with your team about what you'll be doing these days. We'll host centrally located breakfast, lunch and afternoon break for everyone.<br />
<br />
=====Friday=====<br />
Friday will include team time + our closing party at the California Academy of Sciences from 7:00 pm - 12:00 am. We'll have transportation to/from the venue and hotel.<br />
<br />
=====Saturday=====<br />
Departure day only. No scheduled activities.<br />
<br />
===San Francisco All Hands Event Calendar===<br />
Our event can be found on Sched here: https://sanfranciscoallhandsjune2017.sched.com. Events will be live by May 31. <br />
<br />
=====Create an account=====<br />
We don’t recommend using the same email & password as anything like bank accounts, etc. We care about your security!<br />
<br />
If you already have a Sched account from Hawaii, London, or Orlando, it still works, just log in with that.<br />
<br />
=====Add items to your calendar=====<br />
Just hit the circle on any agenda item to add it to your calendar (you do need to have an account & be logged in to do this)<br />
<br />
You can also share a link to meetings to invite others. Go into the meeting and copy the short link. You can email that out to anyone and they can quickly add it to their calendar. <br />
<br />
=====Subscribe to GCal Calendar Link=====<br />
Click on the mobile phone on the right hand side of the screen. All the calendar options are available here. <br />
You have the option to choose ALL meetings or YOUR meetings. Unless you have 400 items on your calendar, just select your calendar. It will add anything on your calendar to your GCal (also an option for Outlook and iCal). It syncs once per day.<br />
<br />
The "only syncs once per day" only applies to Google Calendar. With almost all other clients (like Apple Calendar, Outlook, or the calendar app on your phone) you can set the refresh interval, and Sched's instructions recommend 1 hour.<br />
<br />
Warning: This is a link that utilizes your username for the .ics file.<br />
<br />
=====From Mobile=====<br />
Visit [https://sanfranciscoallhandsjune2017.sched.com/mobile sanfranciscoallhandsjune2017.sched.com/mobile] from any mobile device - bookmark or add to your homescreen for quick access. There is a bonus icon you get by doing this. It caches the last time you opened the page offline and refreshes anytime you are connected.<br />
<br />
=====Cool things=====<br />
'''Filters'''<br />
<br />
We have better (much needed) filtering functionality. You can filter by:<br />
Departments (ex: Firefox)<br />
AND<br />
Functional Teams (ex: Dev Tools or EngOps)<br />
<br />
*Search by Room, Speaker/Leader<br />
<br />
'''Further Filtering'''<br />
*Audience - who should be there (ex: Team only or Invite)<br />
*Homerooms (you can quickly see what is happening in homerooms, by team) - why do you care? If you have a cross team meeting in their room, its a quick way to search<br />
*Views - Lots of view options. It defaults to the simple view, but there are quite a few options.<br />
<br />
=='''Food & Drink'''==<br />
Breakfast, lunch & snacks will be provided and paid for centrally for attendees. Breakfast is provided Tuesday - Saturday and lunch is provided Tuesday - Friday. [https://docs.google.com/document/d/1maNgQUHYO0ecVUd4AFOzwq571EsWLdKfDVBeZA01pPI/edit?usp=sharing Menus here]<br />
<br />
Allergies/preferences: We will ensure that all food/environmental allergies are taken into consideration and will always have gluten-free and vegan options. If you have severe allergies that we need to know about; you can indicate in registration.<br />
<br />
===Monday Night===<br />
We will provide dinner at the Welcome Reception from 6:00 pm - 9:00 pm in the Continental Ballroom at the Welcome Reception. Since most of Monday is a travel day, you'll be on your own for meals except dinner. <br />
<br />
===Tuesday, Wednesday & Thursday Nights===<br />
<br />
Tuesday, Wednesday and Thursday evenings will be of your own to structure as you wish. Given how much you all seemed to like a more flexible dining experience, these three evenings will be of your own to structure as you wish.<br />
<br />
Here is how this will work:<br />
<br />
For each of these three evenings, once your meetings have concluded, you and your team, friends, new acquaintances, are free to explore San Francisco and to find somewhere great to eat that suits you. Each of you can expense a total of $180 over the three days (or $60/night).<br />
<br />
This amount includes:<br />
* Meal cost, including tax & gratuity<br />
* Any beverages<br />
* Transportation to/from the restaurant<br />
* Conversion fees (for credit cards) or cash withdrawal fees<br />
<br />
Anything over the $180 for the three evenings will be your own expense. The fine print:<br />
* If your team is hosting an evening event 1 of the 3 nights and the payment is coordinated (meaning, you don’t have to open your wallet and pay), you can expense up to $120 for the other 2 nights ($60 for each of the 2 nights you did have to open your wallet and pay).<br />
* You will be asked (later) to submit a San Francisco only expense report. You can submit ONE report for San Francisco only and must be submitted no later than August 31, 2017.<br />
* If your manager approves expenses above the $60 per night, that expense will go directly to your travel budget in your cost center.<br />
<br />
Volunteer Contributors will have a separate process that will be communicated directly.<br />
<br />
===Friday Night===<br />
We will provide dinner at the Closing Party from 7:00 pm - 12:00 am at California Academy of Sciences.<br />
<br />
====Evening Agenda====<br />
6:30 pm - Shuttles begin leaving Hilton (Taylor Street entrance). Last shuttle leaves hotel at 7:30 pm. <br />
<br />
7:00 pm - Arrival at California Academy. Lots to explore in the venue, and of course food & drink. <br />
<br />
9:00 pm - DJ & Dance Party in Piazza<br />
<br />
12:00 am - End of event (Shuttles will start departing at 9:00 pm and last shuttle will leave AT 12:00 am)<br />
<br />
====What you need====<br />
Your SF All Hands name badge and Identification (you may be carded for alcohol).<br />
<br />
=='''Photos'''==<br />
==== Flickr ====<br />
Join our SF flickr group and add your own photos: http://www.flickr.com/groups/mozsfallhands2017/<br />
Follow our photostream here:https://flic.kr/g/vJ772<br />
<br />
==== Red Lanyards ====<br />
If you see someone with a red lanyard, please don't take photos of them. They have opted out of being in photography.<br />
<br />
=='''Safety & Security'''==<br />
=====Device Security=====<br />
If you are traveling to the San Francisco All Hands with a device that has Mozilla data (laptop, personal cell phone/tablet with @mozilla gmail, etc) on it and your device has been retained for further inspection by border agents, or if your device has been inspected outside your immediate presence - and you believe your credentials have been compromised - you must notify the Enterprise Information Security team as soon as possible at infosec@mozilla.com or by calling Mozilla End User Services at +1 650-963-8811. (This number will be staffed 24x7)<br />
<br />
We will work with you to reset your credentials and help you get your device back to a known good state either by getting you a new one (if it’s been taken), or by resetting it back to a verifiable Mozilla-approved installation.<br />
<br />
=====Hotel Security=====<br />
We will have Securitas (our office security team) onsite to ensure our spaces are safe and secure. This means you'll want to have your badge on at all times in the hotels, as will your partners, vendors and family members anytime they are in the spaces. <br />
<br />
=====Safety Tips=====<br />
SF Travel team also has some [https://sftravel.ent.box.com/s/p2ve63e1ctn74e0ai2x48mmgr9fdlvul tips about safety] in the city, including safety numbers and local hospitals.<br />
<br />
=='''Hotel'''==<br />
Hotel rooms are reserved for all employees & volunteers to stay all week, including employees based in San Francisco (just as if we were somewhere you don't live). We are hopeful Mozilla-locals will stay with the rest of us in the hotel - it's really part of what makes these events great. If you have a situation that makes that hard, please let me know. <br />
<br />
'''Confirmation emails''' will come directly from Hilton Hotels & Resorts: <hiltonhotels&resorts@res.hilton.com>.If you do not receive a hotel confirmation email by May 26th, please email mozilla@shworldwide.com (after checking your spam collector).<br />
<br />
A few things to note:<br />
*Everyone will be required to present a form of payment on check-in for incidentals at $50 per day. This is a US-resort standard and we aren't able to waive it (we tried). Please reach out to mozilla@shworldwide.com if this creates a hardship for you.<br />
*If you have any changes or questions about your reservation, email mozilla@shworldwide.com. The hotel cannot make changes to All Hands reservations (other than to add your guests - see #4) so we’d like very much if you didn’t try (it complicates things).<br />
*If you have guests joining you for all or part of the week, you will be responsible for adding them to your reservation (and covering any additional fees). To do this, you will need your confirmation number(s) and to know how old your kids are. <br />
If you are staying at the Hilton, please email sfofh-sf-info@hilton.com.<br />
If you are staying at the Parc 55, please email sfosf-reservations@hilton.com.<br />
<br />
====Payment on Check-in====<br />
Everyone will be required to present a form of payment on check-in for incidentals at $50 per day. This is a US hotel standard and we aren't able to waive it (we tried).<br />
<br />
We recommend providing a credit card. You can provide a debit card, but they do put a hold of funds on your card and has been problematic for some international travelers in the past. If you are not able to provide a credit or debit card, email mozilla@shworldwide.com and we'll work with the hotel on accommodating. <br />
<br />
====Pre/post====<br />
Links were emailed (email subject: [San Francisco All Hands] Registration Open) to book hotel 3 days pre and 3 days post at our negotiated rate. The pre/post reservations will require the use of an LDAP email* so we can link them to your All Hands reservation. Rooms booked by any method except this link will not be linked to your main reservation. If you did not receive the links, please email bmark@mozilla.com to request them. <br />
<br />
Rates start $249+tax/fees & for double occupancy, goes up by $20 each for a 3rd and 4th person.<br />
<br />
If you book nights pre and/or post-event, you will have two (or three) confirmation numbers: one for your All Hands stay (in the email that’s on it’s way), and one for your personal time (which you should already have). We’ll link both reservations so you won’t need to change rooms.<br />
<br />
====Parking====<br />
Self-Parking is $49 per day (discounted). Mozilla will not reimburse for parking, plan to commute the way you normally would in the city. If you have questions about parking, email bmark@mozilla.com.<br />
<br />
=='''Travel'''==<br />
Booking travel is now open. Please book itineraries by Friday, April 14, 2017. <br />
<br />
====Arriving Early/Departing Late Guidelines====<br />
<br />
Our standard travel guidelines apply (pre-populated in Egencia) when booking with a few additional budget constraints. Anything booked outside of them will require approval. Most people will arrive on Monday, June 26 and leave on Saturday, July 1. Here are some exceptions: <br />
* If you live in a country where work travel is prohibited on weekends, you may travel on Friday, June 23 and Monday, July 3, if you’d prefer (not required). For hotel, you will book and pay on your own, and expense the manager approved amount (which is coded to your cost center).<br />
* If you plan to spend some extra personal time in San Francisco (choosing to arrive before Monday, June 26 or depart after Saturday, July 1), you'll need to create an itinerary in Egencia for standard dates/locations within the San Francisco Portal and compare to the custom dates you'd like. Please share the difference via email to bmark@mozilla.com or through the approval comment box when you submit the flight. You can sway up to +$100 over and Mozilla will cover it. Otherwise you'll need to come with an alternate itinerary that fits within the pricing (like a round trip in and out of SFO w/ longer dates, and you personally book & cover the rest). We do not have the ability for employees to reimburse Mozilla for any overage.<br />
* If you are attending the Monday Core Influencer's event (by invite).<br />
* If you would like to arrive early to recover from jetlag, you will need manager approval for any additional costs associated with the extension. There is no unilateral "All Hands" approval based upon timezone to arrive early. For hotel, you will book and pay on your own, and expense the manager approved amount (which is coded to your cost center).<br />
<br />
====Booking Family Travel====<br />
Once travel has opened to staff, you may book family, whether they will accompany you on your flight or join us later; and you have two options: Direct or through Egencia. <br />
<br />
If you choose to book family through Egencia, please first book your own flight and then call Egencia with your airline confirmation number (staff do have to go through Egencia). Otherwise, you can book family direct (either through the airline or through another third party) and call the ticketing airline(s) with both confirmation numbers and ask them to link your reservations, so they know you are traveling together. They should also be able to assign seats together. You will avoid the limited hours Egencia offers and avoid paying their ticketing fee. <br />
<br />
If you prefer to book your family through Egencia, you can pay (including the Egencia booking fees) and coordinate with your own travel (recommend to book and then call/email Egencia with your itinerary number to match for family). Note that booking through Egencia does not put you on the same reservation, nor guarantee the reservations will be linked (you would still need to call the airline to link them). <br />
* '''Call:''' +1 (877) 264-1622 or +1 (417) 521-0273; Monday - Friday 9 am - 6 pm EST. If you call outside these hours, you will get an after hours agent, who may not be as helpful. <br />
* '''Email:''' egegrp@expedia.com. The email is monitored Monday - Friday 9 am - 6 pm EST. If you email, you will eventually need to call with a credit card (for fares & fees for family) and personal details of travelers, but the email can get the flights set-up. The agents will need to following information in the initial email to search for flights: Departure City (hometown) & Arrival City (should be SFO), Travel dates & Number of people traveling together + legal names<br />
<br />
====Large Device bans on flights====<br />
Recently, the United States and United Kingdom announced a ban on devices larger than a phone on certain flights and certain airlines. <br />
<br />
Inbound to the US, this affects 9 airlines + 10 Direct flights into the US<br />
Airline:<br />
*EgyptAir; Emirates<br />
*Etihad Airways<br />
*Kuwait Airways<br />
*Qatar Airways<br />
*Royal Air Maroc<br />
*Royal Jordanian<br />
*Saudia (Saudi Arabian Airlines)<br />
*Turkish Airlines) <br />
<br />
Direct flights from specific airports:<br />
Istanbul, Turkey; Dubai and Abu Dhabi in the United Arab Emirates; Doha, Qatar; Amman, Jordan; Cairo, Egypt; Casablanca, Morocco; Jeddah and Riyadh in Saudi Arabia; Kuwait City, Kuwait.<br />
<br />
Inbound to the UK affects all inbound flights from 6 countries: Turkey, Lebanon, Jordan, Saudi Arabia & Tunisia. <br />
<br />
What does this mean for you if you are traveling through one of these airports or on one of these airlines? Potentially: <br />
*a decision between # of layovers and having your devices with you<br />
*Not bringing devices<br />
*Checking devices & ensuring everything is secured and backed up<br />
<br />
Please make sure to check layovers to ensure you are either aware of the bans, or to avoid flights. Keep in mind that your flight doesn't have to originate in one of these cities to be banned. You could have a layover and still have challenges. <br />
<br />
====Travel Insurance====<br />
Mozilla provides emergency medical accident and illness cover for all global MoCo & MoFo employees/interns and their dependents. You can view more information on [https://mana.mozilla.org/wiki/display/PR/Travel+Insurance+-+Business Mana]. This coverage begins at the time the you leave home to start your business trip. It also has a provision for a 14 day extension for leisure travel outside of the business travel. If you have additional questions, please email benefits@mozilla.com. <br />
<br />
Mozilla does not cover travel insurance for elancers, upworkers, contractors, vendors, or volunteers/community members.<br />
<br />
=====''Air Travel Fine Print''=====<br />
Change fees will be covered by Mozilla for business reasons only. If you need a change and have manager approval, email bmark@mozilla.com prior to requesting the change with Egencia. Once you have approval, call Egencia to make the change at +1 (702) 939-2530 or +1-877-264-1622 (note this will not be possible without prior approval so be sure to get that by way of an email from your manager to Brianna Mark). If you are changing for personal reasons, the change in airfare, change fee and Egencia fee is your responsibility.<br />
<br />
Mozilla will not reimburse for Business/First class upgrades or tickets. <br />
<br />
Any submitted expenses needs to have an itinerary attached to ensure it is employee expenses only and within policy.<br />
<br />
=='''Ground Transportation'''==<br />
=====Airport Shuttle=====<br />
All Mozillians and guests who have flights arriving anytime on Monday, June 26th in San Francisco International Airport (SFO) and out on Saturday, July 1, will be transferred to the hotel. If you arrive into another airport (OAK or SJC) or on a different date, ground transportation is on your own.<br />
<br />
'''Arrivals to San Francisco International Airport (SFO)'''<br />
<br />
The airport has four terminals: Terminal 1, 2 & 3, and the International Terminal. For domestic flights In Terminals 1, 2 & 3 and the International Terminal (there are domestic flights), everyone will be greeted at the bottom of the escalator in the baggage claim for your terminal (even if you have no checked bags). Please identify yourself to the greeter and they will direct you to the shuttles for your terminal. <br />
<br />
For International Flights into the International terminal, you will collect your luggage and pass through customs. Once through customs, you will walk directly out to the main lobby, where you’ll find a greeter and they will direct your to your shuttle.<br />
<br />
Should any guest have difficulty connecting with the transportation staff, please call Chelsea Marshburn, 415-419-6225 immediately. Transfer time from the airport to the hotel is approximately 40-60 minutes.<br />
<br />
'''Departures from San Francisco International Airport (SFO)'''<br />
<br />
Everyone departing on Saturday, July 1st, will receive transportation to SFO. You will be met by transportation staff in the Hilton hotel lobby and assisted onto the shuttles. Those staying at Parc 55 will need to walk to the Hilton. Shuttles will depart from the Taylor Street Entrance.<br />
<br />
If you have questions about arrivals or departures, please email mozilla@shworldwide.com.<br />
<br />
====Alternate Transportation Options====<br />
For those arriving or departing on dates other than June 26 and July 1. <br />
*[http://www.bart.gov/stations/powl BART] goes from SFO to the Powell Street Station for $8.95. Tickets can be purchased at the airport or in advance. <br />
*[http://www.samtrans.com/schedulesandmaps/timetables/292.html SamTrans bus Route 292] goes from SFO to Mission St. & 5th St. only for [http://www.samtrans.com/fares/farechart.html $2.25 (inbound) or $4 (outbound)].<br />
*[https://www.supershuttle.com/locations/sanfranciscosfo/ Super Shuttle]. Shared shuttle service. Book in advance. <br />
<br />
Other options can be found on the [https://www.flysfo.com/to-from/ground-transportation SFO website].<br />
<br />
Note: [http://www.sfpride.org/schedule/ San Francisco Pride Weekend Schedule June 24-25]. These events draw almost 2 million people to the city. It will impact your ability to access the hotels (especially on Sunday, see [https://www.sfmta.com/calendar/alerts/san-francisco-pride-service-alert SFMTA info about Pride Parade]).<br />
<br />
====Mountain View Office Shuttle====<br />
We will provide a shuttle from the Mountain View office on Monday, June 26th (1:00 pm and 3:00 pm). We will return to Mountain View on Saturday, July 1 (10:00 am and 12:30 pm).<br />
<br />
You can get dropped off or park at the office. Normal property and office security will keep an eye on your cars.<br />
<br />
=='''Accessibility'''==<br />
<br />
'''The Hilton Union Square'''<br />
<br />
All three guestroom towers have accessible elevators, and accessible rooms (on request). The majority of meeting space is accessible using Tower 3 elevators. The Grand Ballroom (used for the Firefox All Hands) is accessible by using tower 2 elevators. The Yosemite Room is connected by a short escalator to the rest of the Ballroom level. There is also an ADA left available near the escalator. <br />
<br />
The main entrance to the hotel has ramps. [http://www3.hilton.com/en/hotels/california/hilton-san-francisco-union-square-SFOFHHH/popup/hotelDetails.html Hilton Union Square Available Features]<br />
<br />
'''Parc 55'''<br />
<br />
All guestrooms and meeting space are accessible by elevators, and accessible rooms are available on request. The main entrance has easy access to the main elevators. The side/back entrances (closest to Hilton) require the use of steps. [http://www3.hilton.com/en/hotels/california/parc-55-san-francisco-a-hilton-hotel-SFOSFHH/about/amenities.html Parc 55 Available Features]<br />
<br />
====Evenings====<br />
The Monday Night reception is in the Continental Ballroom, accessible by the elevator in Tower 3, Ballroom Level. The Friday Night Party is at California Academy of Sciences, which has access to all levels by elevator. <br />
<br />
=='''Immigration'''==<br />
'''Any''' questions on immigration should be sent to immigration@mozilla.com.<br />
<br />
If you are from a country that requires a B-1/B-2 business visitor visa to enter the US, please plan for it early as government processing times constantly change.<br />
<br />
Please visit the following website to learn more about the visa application process and timing for your country: http://travel.state.gov/content/visas/english/visit/visitor.html#overview. Current estimated processing times at the US Embassies and Consulates abroad can be found at: https://travel.state.gov/content/visas/en/general/wait-times.html/<br />
<br />
Some travelers may be eligible to travel to the United States without first applying for a B-1/B-2 visa, if they are eligible for the Visa Waiver Program (VWP or "ESTA"). You are eligible to apply for admission under the Visa Waiver Program (VWP) if you:<br />
<br />
*Intend to enter the United States for 90 days or less for business, pleasure or transit<br />
*Have a valid passport lawfully issued to you by a Visa Waiver Program country: http://www.esta.us/visa_waiver_countries.html<br />
*Have authorization to travel via the Electronic System for Travel Authorization: https://esta.cbp.dhs.gov/<br />
*Arrive via a Visa Waiver Program signatory carrier (all commercial airlines meet this requirement)<br />
*Have a return or onward ticket<br />
*Travel may not terminate in contiguous territory or adjacent islands unless the traveler is a resident of one of those areas<br />
<br />
=====Employee Travel FAQ=====<br />
This [https://mana.mozilla.org/wiki/display/PR/Travel+FAQ FAQ] addresses questions about how to handle security concerns and electronic devices at the border and how to engage with US Customs & Border Protection (CBP). While it specifically focuses on concerns related to travel to the United States, much of this guidance is applicable to travel elsewhere. Mana access required.<br />
<br />
=====Pocket Letter=====<br />
A pocket letter is recommended to keep on hand for those who are entering the United States. It should accompany you whether or not you are required to have a visa to enter. You may request a copy of that letter when you register online. Please contact immigration@mozilla.com if you require a specific letter for your visa application or if you have any questions regarding your citizenship, visa capabilities or travel related questions.<br />
<br />
=====ESTA Point of Contact=====<br />
In the ESTA application you need to give a "U.S. Point of Contact Information". <br />
<br />
Please list Heather Durham as your US Point of Contact.<br />
Address: 331 East Evelyn Avenue, Mountain View, CA 94041 Phone: 408.505.3028<br />
<br />
=='''San Francisco All Hands Expense Policy'''==<br />
1. All "All Hands" Expenses must be submitted on 1 (and only 1) Expense report (e.g. San Francisco All Hands Expense Report)<br />
<br />
2. It must contain only those expenses relative to the All Hands Event (5-10 days of pre-post activity only)<br />
<br />
3. If your submitted expense report for All Hands is submitted outside these guidelines, it will be rejected and you will be asked to re-submit with only All Hands Expenses<br />
<br />
4. The deadline to submit the San Francisco All Hands Expense Report is '''August 31, 2017'''.<br />
<br />
5. Expenses related to team events, room service, mini-bar charges, and food/drink costs above the vouched amounts, will not be approved. <br />
<br />
'''The intention of our all hands are to centrally organize a structure that includes:'''<br />
*Meals (two/day + snacks)<br />
*Transportation<br />
*Accommodations<br />
*Some number of social events<br />
<br />
Due to the nature of the San Francisco, employees will be expensing specific meals. The amount that can be expensed will be communicated and expenses submitted can not exceed the approved amounts. Any social events that are not part of our central plan will generally be self-organized and funded by participants. <br />
<br />
=====Cell phone reimbursement policy=====<br />
Cell phone reimbursement must be approved by your manager prior to submitting the expense. Teams will decide for their staff what is appropriate to expense. <br />
<br />
=====Internet reimbursement policy=====<br />
Internet will be provided in all guestrooms and meeting space in all hotels. If you opt to upgrade/add service, those costs are not reimbursable, unless previously approved by your manager and are for business reasons. <br />
<br />
If you have questions about any of this, please reach out to bmark@mozilla.com<br />
<br />
=='''Families/Guests in San Francisco'''==<br />
<br />
Of course our focus, for the majority of the week, will be on Mozilla. Everyone is expected to be present and engaged each day, during work hours (as your schedule dictates). Please do what you can to make sure your loved ones understand the kind of commitment you’ve made. Family should not join you during your work sessions (other than the more tiny beings). Please note that what are able to do for families varies by each location. <br />
<br />
====Quick summary logistics====<br />
<br />
'''Air Travel''': Family travel can be booked/coordinated through Egencia by calling direct; or on your own. Employees do need to book via Egencia regardless of how families are booked.<br />
<br />
'''Hotel''': They are welcome to stay with you, however, any additional room expenses will be yours to cover. All room rates are based upon single occupancy and costs to add guests vary by hotel. Breakfast is not inlcuded in any of the guest room rates. Hotels will be assigned based upon team and a part of registration. Once hotels are assigned, we will provide a link or contact add guests.<br />
<br />
Meals: Breakfast and lunch are on their own. They are invited to join our evening festivities, we just ask that you let us know they'll be there in registration.<br />
<br />
=='''Extracurricular Activities'''==<br />
Costs for these activities are self-funded and can not be expensed. Feel free to add activities and invite others.<br />
<br />
* Less crowded than the main Pride events: SF Dyke March on Sat. June 24, http://www.thedykemarch.org/ and Trans March on Fri. June 23 http://www.transmarch.org/trans-march-2017/ Both starting from Dolores Park in the Mission. <br />
* [http://www.sfpride.org/schedule/ San Francisco Pride Weekend Schedule June 24-25]. These events draw almost 2 million people to the city. It will impact your ability to access the hotels (especially on Sunday, see [https://www.sfmta.com/calendar/alerts/san-francisco-pride-service-alert SFMTA info about Pride Parade]). <br />
* [http://www.sftravel.com/summer-love-2017 San Francisco Summer of Love Activities]<br />
* '''[https://public.etherpad-mozilla.org/p/sf-day-hike Hiking!]'''<br />
* [https://public.etherpad-mozilla.org/p/sf-fun] List of some fun activities!</div>Dbaronhttps://wiki.mozilla.org/index.php?title=Standards&diff=1172705Standards2017-06-06T01:08:59Z<p>Dbaron: /* IESG */</p>
<hr />
<div>Welcome to Mozilla's standards participation page.<br />
<br />
Many at Mozilla participate in the development of open web standards, in a variety of different standards bodies. This is a directory of standards organizations (and sub-orgs like working groups) listing who at Mozilla is working with each. For a technology summary see the [[standards/technologies|technologies]] page.<br />
<br />
To encourage better web standards coordination and cross-pollination, the sections below are organized alphabetically by standards body, then alphabetically by working group (if any), then the list of Mozilla folks participating in that working group, optionally listing which particular specifications (or sections thereof) that they edit/author/contribute to.<br />
<br />
If you actively directly communicate/participate with a standards body (working group email list, IRC, wiki, and/or f2f meetings), please add yourself (and the specific standards body / working group if any).<br />
<br />
If you work in multiple working groups or with multiple standards organizations, list yourself in each, linking to your wiki User page.<br />
<br />
Thanks!<br />
<br />
— [[User:Tantek|Tantek]]<br />
<br />
= Web Standards Coordination =<br />
== general participation ==<br />
If you'd like to participate in some of these groups, or at least watch, learn, get up to speed, you can almost always do so by lurking on the public IRC channels and mailing lists that the groups use. Many (most?) standards mailing lists can often be overwhelming in quantity, depth so start with IRC as that's often lighter-weight and easier to watch for quick bits of info/knowledge.<br />
<br />
* Follow the instructions on the [[IRC|IRC wiki page]] to:<br />
** Set yourself up with a nickname and connection to <code>irc.mozilla.org</code>. <br />
* Add a connection to <code>irc.freenode.net</code> (also with '''[x] SSL''') where many standards discussions take place.<br />
* Add another connection to <code>irc.w3.org</code> but specifically port 6665 (unprotected, no nickname registration).<br />
* See each standards section below for which IRC channel(s) tend(s) to be used by folks working in each group.<br />
<br />
== Orgless specs ==<br />
* [[APNG_Specification]]<br />
** fork: [https://gist.github.com/SoniEx2/c679e771d506210378a5 MPNGPNG - Mutli-PNG PNG spec]<br />
<br />
== Ecma International ==<br />
* <span class="h-card">[[User:Brendan|Brendan Eich]]</span><br />
* dherman<br />
* <span class="h-card"><span class="p-name">Allen Wirfs-Brock</span> (<span class="p-role role">Project Editor</span>)</span><br />
<br />
Specifications: ECMAScript 5, 5.1, 6, Harmony, etc.<br />
<br />
== IETF ==<br />
http://ietf.org/<br />
<br />
* ISOC Advisory Council Members:<br />
** Adam Roach (:abr)<br />
** Tim Terriberry (:derf)<br />
<br />
=== IAB ===<br />
[https://www.iab.org/about/iab-members/ Internet Architecture Board] (IAB)<br />
* <span class="h-card">Joe Hildebrand</span><br />
* <span class="h-card">Martin Thomson</span><br />
<br />
=== IESG ===<br />
[https://www.ietf.org/iesg/members.html IESG]<br />
* <span class="h-card">Adam Roach</span> (Applications and Real-Time Area)<br />
* <span class="h-card">Eric Rescorla</span> (Security Area)<br />
<br />
=== Calsify (iCalendar) ===<br />
* Most calendar related standards, list at: http://www.ietf.org/mail-archive/web/calsify/current/maillist.html<br />
<br />
* Philipp Kewisch<br />
<br />
Specifications [http://tools.ietf.org/html/rfc5545 rfc5545] [http://tools.ietf.org/html/rfc5546 rfc5546] [http://www.ietf.org/id/draft-kewisch-et-al-icalendar-in-json-01.txt icalendar-in-json] and related.<br />
<br />
=== dnsop ===<br />
* lshapiro (Larissa Shapiro)<br />
<br />
=== dhcp ===<br />
* lshapiro (Larissa Shapiro)<br />
<br />
=== HyBi (WebSockets) ===<br />
* <span class="h-card">Pat McManus</span><br />
* <span class="h-card">Chris Blizzard</span> (emeritus as of 2012-03-16)<br />
<br />
=== NETVC ===<br />
https://datatracker.ietf.org/wg/netvc/<br />
<br />
Mailing list at https://www.ietf.org/mailman/listinfo/video-codec<br />
<br />
* Adam Roach (:abr) - WG Chair<br />
* Timothy B. Terriberry (:derf)<br />
* Jean-Marc Valin (:jmspeex)<br />
* Nathan Egge<br />
<br />
=== Opus ===<br />
* <span class="h-card"><span class="p-name">Jean-Marc Valin</span> (:<span class="p-nickname">jmspeex</span>)</span><br />
* <span class="h-card"><span class="p-name">Tim Terriberry</span> (:<span class="p-nickname">derf</span>)</span><br />
* <span class="h-card"><span class="p-name">Ralph Giles</span> (:<span class="p-nickname nickname">rillian</span>)</span><br />
<br />
=== RTCWEB / MMUSIC ===<br />
* <span class="h-card">Randell Jesup</span><br />
* <span class="h-card">Tim Terriberry</span><br />
* <span class="h-card">Ralph Giles</span><br />
* <span class="h-card">Adam Roach (:abr)</span><br />
* <span class="h-card">Eric Rescorla (<span class="p-nickname">EKR</span>)</span><br />
* <span class="h-card">Maire Reavy </span><br />
<br />
=== STIR ===<br />
* Eric Rescorla<br />
<br />
=== TLS (SSL) ===<br />
* <span class="h-card">[[User:Briansmith|Brian Smith]]</span><br />
* Eric Rescorla<br />
<br />
=== VCARDDAV ===<br />
vcarddav group/list at: [http://www.ietf.org/mail-archive/web/vcarddav/current/maillist.html http://www.ietf.org/mail-archive/web/vcarddav/current/maillist.html]<br />
* <span class="vcard">[[User:Tantek|Tantek Çelik]]</span><br />
* Philipp Kewisch<br />
Specifications: [[vCard4]] [http://www.ietf.org/id/draft-kewisch-vcard-in-json-00.txt vcard-in-json]<br />
<br />
== Khronos ==<br />
[http://www.khronos.org/webgl/ WebGL]<br />
* Jeff Gilbert (:jgilbert)<br />
<br />
== microformats ==<br />
http://microformats.org/ and [http://microformats.org/wiki microformats wiki]<br />
* irc://irc.freenode.net/microformats<br />
* email lists: http://microformats.org/discuss<br />
Community participants:<br />
* <span class="h-card"><span class="p-name">[[User:Tantek|Tantek Çelik]]</span> (<span class="p-role">founder</span>, <span class="p-role">admin</span>)</span><br />
* <span class="h-card">Michael Kaply</span><br />
* ...<br />
<br />
Specifications: <br />
* [[hCard]] - implemented in Firefox DOM<br />
* [[hCalendar]] - implemented in Firefox DOM<br />
* ... and many others.<br />
<br />
== OWF ==<br />
http://openwebfoundation.org/<br />
* <span class="h-card"><span class="p-name">[[User:Tantek|Tantek Çelik]]</span> (<span class="role">elected board member</span>)</span><br />
<br />
Specifications: <br />
* [http://openwebfoundation.org/legal/agreement/ Open Web Foundation Agreement] (OWFa)<br />
<br />
== W3C ==<br />
The [http://w3.org/ W3C] (World Wide Web Consortium) has Working Groups (WGs), Incubator Groups (IGs), Interest Groups (IGs), and Community Groups (WGs). See below for details and please add any/all of such groups here in alphabetical order by group name.<br />
* [[Standards/Participating in a W3C Working Group|Participating in a W3C Working Group]]<br />
* [[Standards/W3C Charter Development and Review|W3C Charter Development and Review]]<br />
* [https://www.w3.org/2000/09/dbwg/participants?org=35507&order=group Member-confidential (unfortunately) list of groups Mozilla participates in]<br />
<br />
=== Advisory Board ===<br />
Elected member to the [http://www.w3.org/wiki/AB W3C Advisory Board].<br />
* <span class="h-card">[[User:Tantek|Tantek Çelik]]</span><br />
<br />
=== Advisory Committee representative ===<br />
* <span class="fn h-card">[[User:Dbaron|David Baron]]</span><br />
See [https://www.w3.org/Member/ACList Advisory Committee Representative Directory] for who else is an AC Rep from which companies.<br />
<br />
=== Audio Incubator Group ===<br />
http://www.w3.org/2005/Incubator/audio/<br />
* <span class="h-card">Alistair MacDonald</span><br />
<br />
=== Audio Working Group ===<br />
* http://www.w3.org/2011/audio/<br />
[https://www.w3.org/2000/09/dbwg/details?group=46884&public=1&order=org#_MozillaFoundation Participants]:<br />
* <span class="h-card">Matthew Gregan</span><br />
* <span class="h-card">Paul Adenot</span><br />
* <span class="h-card">Ehsan Akhgari</span><br />
<br />
=== Browser Testing and Tools Working Group ===<br />
* [https://www.w3.org/testing/browser/ Group homepage]<br />
* [https://www.w3.org/2011/08/browser-testing-charter.html Charter]<br />
* [mailto:public-browser-tools-testing@w3.org Mailing list]<br />
* [https://lists.w3.org/Archives/Public/public-browser-tools-testing/ Mailing list archive]<br />
<br />
Participants:<br />
* <span class="h-card">[[User:Ato|Andreas Tolfsen]]</span><br />
* <span class="h-card">[[User:Dburns|David Burns]]</span> (co-editor and chair)<br />
* <span class="h-card">[[User:Jgraham|James Graham]]</span><br />
<br />
Specifications:<br />
* APIs for remote controlling web browsers<br />
** [http://w3c.github.io/webdriver/webdriver-spec.html WebDriver]<br />
* APIs for use in debugging of web applications<br />
<br />
=== Core Mobile Web Platform Community Group ===<br />
http://www.w3.org/community/coremob/<br />
* <span class="h-card">[[User:Brendan|Brendan Eich]]</span><br />
* <span class="h-card">[[User:Sicking|Jonas Sicking]]</span><br />
* <span class="h-card">Ragavan Srinivasan</span><br />
* <span class="h-card">[[User:Jetvillegas|Jet Villegas]]</span><br />
<br />
=== CSS Working Group ===<br />
CSS (Cascading Style Sheets) Working Group (WG)<br />
* home page: http://w3.org/Style/CSS/<br />
* irc://irc.w3.org:6665/css<br />
* email: http://lists.w3.org/Archives/Public/www-style/<br />
Working group members related to Mozilla (also on w3c-css-wg)<br />
* <span class="h-card">[[User:Dbaron|David Baron]]</span><br />
* <span class="h-card">[[User:Tantek|Tantek Çelik]]</span><br />
* <span class="h-card">John Daggett</span><br />
* <span class="h-card">[[User:Fantasai|fantasai]]</span><br />
* <span class="h-card">[[User:jensimmons|Jen Simmons]]</span><br />
* <span class="h-card">Aryeh Gregor</span><br />
* <span class="h-card">Masayuki Nakano</span><br />
* <span class="h-card">[[User:Jetvillegas|Jet Villegas]]</span><br />
<br />
Additional www-style list participants related to Mozilla (anyone is welcome to join)<br />
* <span class="h-card">Robert O'Callahan</span><br />
* <span class="h-card">[[User:Hsivonen|Henri Sivonen]]</span><br />
* <span class="h-card">[[User:Bzbarsky|Boris Zbarsky]]</span><br />
* <span class="h-card">[[User:Dholbert|Daniel Holbert]]</span><br />
* ...<br />
<br />
Specifications: [[CSS21]], [[CSS3]]<br />
<br />
See also: [[CSS]] on this wiki.<br />
<br />
=== Federated Social Web Community Group ===<br />
* http://www.w3.org/community/fedsocweb/<br />
Participants:<br />
* <span class="h-card">[[User:Tantek|Tantek Çelik]]</span><br />
<br />
was previously: Federated Social Web Incubator Group<br />
<br />
=== Games Community Group ===<br />
http://www.w3.org/community/games/<br />
* <span class="h-card">Rob Hawkes</span><br />
* <span class="h-card">Alan Kligman</span><br />
* <span class="h-card">Dan Mosedale</span><br />
* <span class="h-card">Bobby Richter</span><br />
<br />
=== Geolocation Working Group ===<br />
Geolocation Working Group (GEO) http://www.w3.org/2008/geolocation/<br />
* <span class="h-card">Doug Turner</span><br />
<br />
=== HTML Working Group ===<br />
Needs updating / archiving. (This group has been effectively closed and most of its deliverables subsumed by the Web Platform Working Group. All that remains is a spin-off EME group, where Henri is our only participant currently.)<br />
<br />
HTML (HyperText Markup Language) Working Group (WG), sometimes listed as "HTML5 WG"<br />
http://www.w3.org/html/wg/<br />
* <span class="h-card">[[User:Tantek|Tantek Çelik]]</span><br />
* <span class="h-card">[[User:Mounir.lamouri|Mounir Lamouri]]</span><br />
* <span class="h-card">[[User:Sicking|Jonas Sicking]]</span><br />
* <span class="h-card">[[User:Hsivonen|Henri Sivonen]]</span><br />
* <span class="h-card">[[User:Jetvillegas|Jet Villegas]]</span><br />
* ...<br />
<br />
Specifications: [[HTML5]]<br />
<br />
=== HTML Speech Incubator Group ===<br />
* <span class="h-card">David Bolter</span><br />
* <span class="h-card">Olli Pettay</span><br />
<br />
=== Indie UI Events ===<br />
http://www.w3.org/2011/11/indie-ui-charter<br />
* <span class="h-card">David Bolter</span> (monitoring)<br />
<br />
=== Internationalization Working Group ===<br />
http://w3.org/International/<br />
* <span class="h-card">[[User:Fantasai|fantasai]]</span><br />
<br />
=== Media Fragments Working Group ===<br />
* <span class="h-card">Chris Double</span><br />
<br />
=== Near Field Communications Working Group ===<br />
W3C [http://www.w3.org/2012/nfc/ Near Field Communications (NFC) Working Group]<br />
* No one from Mozilla is currently participating.<br />
<br />
Want to participate? Please contact <span class="h-card">[[User:Dbaron|David Baron]]</span> and <span class="h-card">[[User:Tantek|Tantek]]</span>.<br />
<br />
=== Pointer Events Working Group ===<br />
* http://www.w3.org/2012/pointerevents/<br />
Participants:<br />
* <span class="h-card">Olli Pettay</span><br />
* <span class="h-card">Matt Brubeck</span><br />
<br />
=== Protocols and Formats Working Group ===<br />
(Web Accessibility) Protocols and Formats Working Group (PF WG)<br />
* <span class="h-card">David Bolter</span><br />
<br />
=== PubSubHubbub Community Group ===<br />
* http://www.w3.org/community/pubsub/<br />
Participants:<br />
* <span class="h-card">[[User:Tantek|Tantek Çelik]]</span><br />
<br />
=== Second Screen Working Group ===<br />
* http://www.w3.org/2014/secondscreen/ <br />
[https://www.w3.org/2000/09/dbwg/details?group=74168&public=1&order=org#_MozillaFoundation Participants]:<br />
* <span class="h-card">Bradford Lassey</span><br />
* <span class="h-card">Shih-Chiang Chien</span><br />
<br />
=== Social Web Working Group ===<br />
SocialWG - http://www.w3.org/Social/WG<br />
* <span class="h-card">[[User:Tantek|Tantek]]</span> - co-chair<br />
<br />
=== SVG Working Group ===<br />
SVG (Scalable Vector Graphics) Working Group<br />
http://w3.org/SVG/<br />
* <span class="h-card">Cameron McCormack</span> (co-chair)<br />
* <span class="h-card">Brian Birtles</span><br />
* <span class="h-card">Jonathan Watt</span><br />
<br />
Specifications: SVG 1.1, SVG 2.0<br />
<br />
=== System Applications Working Group ===<br />
[http://www.w3.org/2012/sysapps/ SysApps] (System Applications) Working Group [https://www.w3.org/2000/09/dbwg/details?group=58119&public=1&order=org#_MozillaFoundation participants]:<br />
* <span class="h-card">[[User:Brendan|Brendan Eich]]</span><br />
* <span class="h-card">[[User:Sicking|Jonas Sicking]]</span><br />
<br />
=== Tracking Protection Working Group ===<br />
http://www.w3.org/2011/tracking-protection/<br />
* <span class="h-card">Heather West</span><br />
<br />
=== Technical Architecture Group ===<br />
W3C [http://www.w3.org/2001/tag/ TAG]<br />
* <span class="h-card">[[User:Dbaron|David Baron]]</span><br />
<br />
=== Web Applications Working Group ===<br />
WebApps WG<br />
* <span class="h-card">Cameron McCormack</span><br />
* <span class="h-card">[[User:Anant|Anant Narayanan]]</span><br />
* <span class="h-card">Olli Pettay</span><br />
* <span class="h-card">Arun Ranganathan</span><br />
* <span class="h-card">[[User:Sicking|Jonas Sicking]]</span><br />
* <span class="h-card">[[User:Tantek|Tantek Çelik]]</span> (observer)<br />
* <span class="h-card">[[User:Mounir.lamouri|Mounir Lamouri]]</span><br />
<br />
Specifications: IndexedDB, Web IDL, XMLHttpRequest, DOM 3 Events, DOM 4, etc. See the group's [http://www.w3.org/2008/webapps/wiki/PubStatus PubStatus] wiki for a list of all specs.<br />
<br />
See also on this wiki:<br />
* [[DOM]]<br />
* [[WebAPI]]<br />
<br />
<br />
=== Web Applications Security Working Group ===<br />
* Eric Rescorla<br />
* Daniel Veditz<br />
* Francois Marier<br />
* Tanvi Vyas<br />
* Frederik Braun<br />
<br />
Specifications: CSP, HSTS Priming, SRI, CORS (jointly with WebApps WG)<br />
<br />
=== WebAssembly Community Group ===<br />
https://www.w3.org/community/webassembly/<br />
* Luke Wagner<br />
* Dan Gohman<br />
* Alon Zakai<br />
* Benjamin Bouvier<br />
<br />
=== Web Cryptography Working Group ===<br />
[http://www.w3.org/2012/webcrypto/ Web Cryptography Working Group]<br />
* <span class="h-card">[[User:Ddahl|David Dahl]]</span><br />
* <span class="h-card">Arun Ranganathan</span><br />
* <span class="h-card"><span class="p-name">Eric Rescorla</span> (<span class="p-nickname">EKR</span>)</span><br />
<br />
=== Web Education Community Group ===<br />
http://www.w3.org/community/webed/<br />
<br />
* <span class="h-card">Schalk Neethling</span><br />
* <span class="h-card">Jérémie Patonnier</span><br />
* <span class="h-card">Janet Swisher</span><br />
<br />
=== Web Events Working Group / Touch Events Community Group ===<br />
* <span class="h-card">Matt Brubeck</span><br />
* <span class="h-card">Olli Pettay</span><br />
<br />
Specifications: Touch Events<br />
<br />
=== WebFonts Working Group ===<br />
* <span class="h-card">Jonathan Kew</span> (editor)<br />
* <span class="h-card">John Daggett</span><br />
<br />
=== Web Hypertext Application Technology Community Group ===<br />
* <span class="h-card">[[User:Dbaron|David Baron]]</span><br />
* <span class="h-card">[[User:Tantek|Tantek Çelik]]</span><br />
* <span class="h-card">Aryeh Gregor</span><br />
* <span class="h-card">Cameron McCormack</span><br />
See also the [http://www.w3.org/community/whatwg/participants complete list of participants].<br />
<br />
Specifications: HTML living standard as developed by the WHATWG.<br />
<br />
=== Web Media Text Tracks Community Group ===<br />
http://www.w3.org/community/texttracks/<br />
* <span class="h-card"><span class="p-name">Ralph Giles</span> (:<span class="p-nickname">rillian</span>)</span><br />
<br />
Specifications: something [http://www.whatwg.org/specs/web-apps/current-work/webvtt.html WebVTT]-ish, we hope.<br />
<br />
=== Web Payments Task Force ===<br />
[http://www.w3.org/wiki/Payments_Task_Force http://www.w3.org/wiki/Payments_Task_Force]<br />
<br />
* <span class="h-card">Kumar McMillan</span><br />
* [http://www.w3.org/wiki/2013_Web_Payment_Task_Force_Participants Full list]<br />
<br />
=== Web Performance Working Group ===<br />
* <span class="h-card">Cameron McCormack</span><br />
* <span class="h-card">Kyle Simpson</span><br />
<br />
Specifications: Timing control for script-based animations (requestAnimationFrame)<br />
<br />
=== Web Platform Working Group ===<br />
* <span class="h-card">Hallvord Steen</span><br />
* <span class="h-card">[[User:Sicking|Jonas Sicking]]</span><br />
* <span class="h-card">Karl Dubost</span><br />
* <span class="h-card">Marcos Caceres</span><br />
* <span class="h-card">Martin Thomson</span><br />
* <span class="h-card">Olli Pettay</span><br />
* <span class="h-card">[[User:Tantek|Tantek Çelik]]</span><br />
Primary work area: https://github.com/w3c/WebPlatformWG<br />
<br />
=== WebRTC Working Group ===<br />
[[WebRTC]] (Web Real Time Communications) Working Group<br />
* <span class="h-card">Ralph Giles</span><br />
* <span class="h-card">Maire Reavy</span><br />
* <span class="h-card"><span class="p-name">Eric Rescorla</span> (<span class="p-nickname">EKR</span>)</span><br />
* <span class="h-card">Tim Terriberry</span><br />
* <span class="h-card">Adam Roach (:abr)</span><br />
* <span class="h-card">Randell Jesup (:jesup)</span><br />
<br />
Specifications: Media capture & [http://www.w3.org/2011/04/webrtc-charter.html streaming APIs]<br />
<br />
* <span class="h-card">Chia-hung Tai(:ctai)</span><br />
* <span class="h-card">Tzu-hao Kuo(:kaku)</span><br />
<br />
Specifications: Media Capture Stream with Worker Extensions [https://w3c.github.io/mediacapture-worker/ mediacapture-worker APIs]<br />
<br />
== WHATWG ==<br />
Web Hypertext Application Technologies Working Group - http://whatwg.org<br />
* <span class="h-card">[[User:Dbaron|David Baron]]</span><br />
* <span class="h-card">[[User:Tantek|Tantek Çelik]]</span><br />
* <span class="h-card">[[User:Brendan|Brendan Eich]]</span><br />
* <span class="h-card">Mounir Lamouri</span><br />
* <span class="h-card">[[User:Sicking|Jonas Sicking]]</span><br />
* <span class="h-card">[[User:Hsivonen|Henri Sivonen]]</span><br />
* <span class="h-card">[[User:Annevk|Anne van Kesteren]]</span><br />
* ...<br />
<br />
Web Editing specification - http://dvcs.w3.org/hg/editing/raw-file/tip/editing.html<br />
* <span class="h-card">[[User:Ehsan|Ehsan Akhgari]]</span><br />
<br />
= other =<br />
<br />
== Alliance for Open Media ==<br />
The [http://aomedia.org/ Alliance for Open Media] develops next-generation media formats, codecs, and technologies. See also [[#NETVC]].<br />
* <span class="h-card">Timothy B. Terriberry (:derf)</span><br />
<br />
== CA/Browser Forum ==<br />
The [http://cabforum.org/ CA/Browser Forum] produces standards in the area of best practice and validation for certificate authorities.<br />
* <span class="h-card">[[User:Gerv|Gervase Markham]]</span><br />
* <span class="h-card">Kathleen Wilson</span><br />
<br />
== CalConnect ==<br />
Mozilla is a member of [http://www.calconnect.org/ CalConnect], The Calendaring and Scheduling Consortium, which is not actually affiliated w/ IETF or W3C but in practice drives development and interoperability testing of IETF specs:<br />
* RFC 5545 iCalendar (obsoletes RFC 2445).<br />
* RFC 4791 CalDAV Access protocol<br />
See their [http://www.calconnect.org/CD1104_Calendaring_Standards.shtml Index to Calendaring and Scheduling Standards] for other specific standards that CalConnect is involved with.<br />
<br />
== OASIS ==<br />
* Mozilla point of contact: Gervase Markham<br />
* PKCS#11 working group: Brian Smith<br />
<br />
== XMPP ==<br />
Mozilla is not formally associated with the XSF but has representation indirectly. http://xmpp.org/<br />
* no direct involvement by any current Mozillian<br />
<br />
== C++ ==<br />
<br />
C++ is standardized by [http://www.open-std.org/jtc1/sc22/wg21/ ISO/IEC JTC1/SC22/WG21] (informally, the "C++ Standards Committee"). All proposals are publically available [http://www.open-std.org/jtc1/sc22/wg21/docs/papers/ here].<br />
<br />
[https://mozillians.org/en-US/u/bballo/ Botond Ballo] is a member of Canada's delegation to the Committee, and has been attending meetings regularly since September 2013. If you have any feedback about any existing proposal, or would like to explore the idea of putting forth a new proposal, please post to dev-platform and cc Botond.<br />
<br />
= emeritus =<br />
== people ==<br />
Former Mozillians who worked on standards or still work on them:<br />
* <span class="h-card">[[User:Gal|Andreas Gal]]</span> (til [http://www.cnet.com/news/firefox-os-in-flux-as-mozilla-loses-technology-chief-to-startup/ ~2015-06-05])<br />
** Ecma International<br />
** Web Payments Task Force<br />
<br />
* <span class="h-card">Chris Blizzard</span> (til 2012-03-16)<br />
** [[#IETF]]<br />
** [[#rtcweb]]<br />
** [[#WebRTC_Working_Group]]<br />
<br />
* <span class="h-card"><span class="p-name">[[User:bear|Mike Taylor]]</span> (<span class="p-nickname">bear</span>) - <span class="p-role">elected board member</span></span><br />
** [[#XMPP]]<br />
<br />
* <span class="h-card">Alex Fowler</span><br />
** [[#Tracking_Protection_Working_Group]]<br />
* <span class="h-card">Thomas Lowenthal</span><br />
** [[#Tracking_Protection_Working_Group]]<br />
* <span class="h-card">Sid Stamm</span><br />
** [[#Tracking_Protection_Working_Group]]<br />
** [[#CA.2FBrowser_Forum]]<br />
<br />
* <span class="h-card">David Ascher</span><br />
** Federated Social Web Incubator Group<br />
** Federated Social Web Community Group<br />
<br />
== organizations and groups ==<br />
=== Federated Social Web Incubator Group ===<br />
2010-12-15 ... 2012-01-12 (transitioned to Federated Social Web Community Group)<br />
<br />
W3C Federated Social Web Incubator Group (FSW XG)<br />
http://www.w3.org/2005/Incubator/federatedsocialweb/ and [http://www.w3.org/2005/Incubator/federatedsocialweb/wiki/Main_Page FSW wiki]<br />
* <span class="h-card">[[User:Mixedpuppy|Shane Caraveo]]</span><br />
* <span class="h-card">[[User:Tantek|Tantek Çelik]]</span><br />
<br />
= subpages of {{FULLPAGENAME}}=<br />
{{Special:PrefixIndex/{{FULLPAGENAME}}/}}<br />
<br />
= related =<br />
See also:<br />
* [[Events]] - which include web standards-related events.<br />
* [[SEO/Standards]] - how to use standards to improve/optimize search results<br />
* [[Standards/license]] - what license Mozilla prefers for standards specifications</div>Dbaronhttps://wiki.mozilla.org/index.php?title=All_Hands/SanFrancisco2017&diff=1168205All Hands/SanFrancisco20172017-04-13T01:44:02Z<p>Dbaron: /* Dates, Location and Weather */ clarify sentence</p>
<hr />
<div>'''What is it?''' -- Multiple team meetings, happening in the same city, at the same time + some opportunity to get together as one big group as well as with other teams as it makes sense. Then, on the last day, we have a fun social event for all, Mozilla-style! <br />
<br />
'''''The information on this wiki primarily applies to Full time and contractor staff. If you are a volunteer contributor or intern, please inquire to your coordinator. '''''<br />
<br />
=='''Dates, Location and Weather'''==<br />
Monday, June 26 - Friday, June 30, 2017 (travel days are Monday the 26th & Saturday the 1st*) in San Francisco, CA.<br />
<br />
We are staying at [http://www3.hilton.com/en/hotels/california/hilton-san-francisco-union-square-SFOFHHH/index.html Hilton San Francisco Union Square] & [http://www.parc55hotel.com/ Parc 55] San Francisco. [https://osm.org/go/TZHvW7Hnn?m=&node=1941537172 map]<br />
<br />
''*For those countries where rest time is required on weekends (vs. work travel), Mozilla will cover a return on the next available work day, if you choose. This needs to pre-approved and pre-arranged.''<br />
<br />
Weather:<br />
* National Weather Service: [http://forecast.weather.gov/MapClick.php?smap=1&lat=37.785&lon=-122.410&unit=1&mp=1 forecast in ⁰C], [http://forecast.weather.gov/MapClick.php?smap=1&lat=37.785&lon=-122.410&mp=1 forecast in ⁰F]<br />
* Temperatures ''in downtown San Francisco'' in late June are likely to have nighttime lows around 10-13 ⁰C / 50-56 ⁰F and daytime highs around 16-24 ⁰C / 61-75 ⁰F. But the weather is very occasionally warmer with highs around 27⁰C / 81⁰F.<br />
* Weather in San Francisco in the summer is variable; it can become substantially cooler and foggier in the late afternoon; be prepared for temperatures to fall to 13⁰C / 56⁰F and the winds to pick up in the afternoon. Be prepared by carrying a warmer layer with you.<br />
* Weather in other parts of the Bay Area can be much warmer than in San Francisco, even if you're only traveling 15km away. Look at the weather forecasts for where you're going. It's entirely possible for it to be 19⁰C / 66⁰F in San Francisco and simultaneously be 32⁰C / 90⁰F in Orinda. But if you're right on the ocean, the air temperature is likely to match the water temperature, which is probably around 12⁰C / 54⁰F.<br />
<br />
=='''Registration'''==<br />
This is an invite-only event.<br />
<br />
=====New Hires=====<br />
We have a process to identify new hires each Monday and will invite them to book travel. No action necessary from managers other than to let them know about the event. Please work closely with your recruiting manager as they are aware of all deadlines.<br />
<br />
=='''Food & Drink'''==<br />
Breakfast, lunch & snacks will be provided and paid for centrally for attendees. Details about dinners will be shared soon. <br />
<br />
=='''Hotel'''==<br />
Hotel rooms are reserved for all employees & volunteers to stay all week, including employees based in San Francisco (just as if we were somewhere you don't live). We encourage everyone to stay in the hotel and be a part of the full week's activities.<br />
<br />
=====Pre/post=====<br />
A link ''will be'' available to book hotel 3 days pre and 3 days post at our negotiated rate. The pre/post reservations will require the use of an LDAP email* so we can link them to your All Hands reservation. Rooms booked by any method except this link will not be linked to your main reservation. <br />
<br />
=='''Travel'''==<br />
Booking travel is now open. Please book itineraries by Friday, April 14, 2017. <br />
<br />
====Arriving Early/Departing Late Guidelines====<br />
<br />
Our standard travel guidelines apply (pre-populated in Egencia) when booking with a few additional budget constraints. Anything booked outside of them will require approval. Most people will arrive on Monday, June 26 and leave on Saturday, July 1. Here are some exceptions: <br />
* If you live in a country where work travel is prohibited on weekends, you may travel on Friday, June 23 and Monday, July 3, if you’d prefer (not required). For hotel, you will book and pay on your own, and expense the manager approved amount (which is coded to your cost center).<br />
* If you plan to spend some extra personal time in San Francisco (choosing to arrive before Monday, June 26 or depart after Saturday, July 1), you'll need to create an itinerary in Egencia for standard dates/locations within the San Francisco Portal and compare to the custom dates you'd like. Please share the difference via email to bmark@mozilla.com or through the approval comment box when you submit the flight. You can sway up to +$100 over and Mozilla will cover it. Otherwise you'll need to come with an alternate itinerary that fits within the pricing (like a round trip in and out of SFO w/ longer dates, and you personally book & cover the rest). We do not have the ability for employees to reimburse Mozilla for any overage.<br />
* If you are attending the Monday Core Influencer's event (by invite).<br />
* If you would like to arrive early to recover from jetlag, you will need manager approval for any additional costs associated with the extension. There is no unilateral "All Hands" approval based upon timezone to arrive early. For hotel, you will book and pay on your own, and expense the manager approved amount (which is coded to your cost center).<br />
<br />
====Booking Family Travel====<br />
Once travel has opened to staff, you may book family, whether they will accompany you on your flight or join us later; and you have two options: Direct or through Egencia. <br />
<br />
If you choose to book family through Egencia, please first book your own flight and then call Egencia with your airline confirmation number (staff do have to go through Egencia). Otherwise, you can book family direct (either through the airline or through another third party) and call the ticketing airline(s) with both confirmation numbers and ask them to link your reservations, so they know you are traveling together. They should also be able to assign seats together. You will avoid the limited hours Egencia offers and avoid paying their ticketing fee. <br />
<br />
If you prefer to book your family through Egencia, you can pay (including the Egencia booking fees) and coordinate with your own travel (recommend to book and then call/email Egencia with your itinerary number to match for family). Note that booking through Egencia does not put you on the same reservation, nor guarantee the reservations will be linked (you would still need to call the airline to link them). <br />
* '''Call:''' +1 (877) 264-1622 or +1 (417) 521-0273; Monday - Friday 9 am - 6 pm EST. If you call outside these hours, you will get an after hours agent, who may not be as helpful. <br />
* '''Email:''' egegrp@expedia.com. The email is monitored Monday - Friday 9 am - 6 pm EST. If you email, you will eventually need to call with a credit card (for fares & fees for family) and personal details of travelers, but the email can get the flights set-up. The agents will need to following information in the initial email to search for flights: Departure City (hometown) & Arrival City (should be SFO), Travel dates & Number of people traveling together + legal names<br />
<br />
====Large Device bans on flights====<br />
Recently, the United States and United Kingdom announced a ban on devices larger than a phone on certain flights and certain airlines. <br />
<br />
Inbound to the US, this affects 9 airlines + 10 Direct flights into the US<br />
Airline:<br />
*EgyptAir; Emirates<br />
*Etihad Airways<br />
*Kuwait Airways<br />
*Qatar Airways<br />
*Royal Air Maroc<br />
*Royal Jordanian<br />
*Saudia (Saudi Arabian Airlines)<br />
*Turkish Airlines) <br />
<br />
Direct flights from specific airports:<br />
Istanbul, Turkey; Dubai and Abu Dhabi in the United Arab Emirates; Doha, Qatar; Amman, Jordan; Cairo, Egypt; Casablanca, Morocco; Jeddah and Riyadh in Saudi Arabia; Kuwait City, Kuwait.<br />
<br />
Inbound to the UK affects all inbound flights from 6 countries: Turkey, Lebanon, Jordan, Saudi Arabia & Tunisia. <br />
<br />
What does this mean for you if you are traveling through one of these airports or on one of these airlines? Potentially: <br />
*a decision between # of layovers and having your devices with you<br />
*Not bringing devices<br />
*Checking devices & ensuring everything is secured and backed up<br />
<br />
Please make sure to check layovers to ensure you are either aware of the bans, or to avoid flights. Keep in mind that your flight doesn't have to originate in one of these cities to be banned. You could have a layover and still have challenges. <br />
<br />
====Travel Insurance====<br />
Mozilla provides emergency medical accident and illness cover for all global employees/interns and their dependents. You can view more information on [https://mana.mozilla.org/wiki/display/PR/Travel+Insurance+-+Business Mana]. This coverage begins at the time the you leave home to start your business trip. It also has a provision for a 14 day extension for leisure travel outside of the business travel. If you have additional questions, please email benefits@mozilla.com. <br />
<br />
Mozilla does not cover travel insurance for volunteers.<br />
<br />
=====''Air Travel Fine Print''=====<br />
Change fees will be covered by Mozilla for business reasons only. If you need a change and have manager approval, email bmark@mozilla.com prior to requesting the change with Egencia. Once you have approval, call Egencia to make the change at +1 (702) 939-2530 or +1-877-264-1622 (note this will not be possible without prior approval so be sure to get that by way of an email from your manager to Brianna Mark). If you are changing for personal reasons, the change in airfare, change fee and Egencia fee is your responsibility.<br />
<br />
Mozilla will not reimburse for Business/First class upgrades or tickets. <br />
<br />
Any submitted expenses needs to have an itinerary attached to ensure it is employee expenses only and within policy.<br />
<br />
=='''Ground Transportation'''==<br />
=====Airport Shuttle=====<br />
All Mozillians and guests who have flights arriving anytime on Monday, June 26th in San Francisco International Airport (SFO) and out on Saturday, July 1, will be transferred to the hotel. If you arrive into another airport (OAK or SJC) or on a different date, ground transportation is on your own.<br />
<br />
====Mountain View Office Shuttle====<br />
We will provide a shuttle from the Mountain View office on Monday, June 26th (time and qty TBA). We will return to Mountain View on Saturday, July 1. <br />
<br />
You can get dropped off or park at the office. Normal property and office security will keep an eye on your cars.<br />
<br />
=='''Immigration'''==<br />
'''Any''' questions on immigration should be sent to immigration@mozilla.com.<br />
<br />
If you are from a country that requires a B-1/B-2 business visitor visa to enter the US, please plan for it early as government processing times constantly change.<br />
<br />
Please visit the following website to learn more about the visa application process and timing for your country: http://travel.state.gov/content/visas/english/visit/visitor.html#overview. Current estimated processing times at the US Embassies and Consulates abroad can be found at: https://travel.state.gov/content/visas/en/general/wait-times.html/<br />
<br />
Some travelers may be eligible to travel to the United States without first applying for a B-1/B-2 visa, if they are eligible for the Visa Waiver Program (VWP or "ESTA"). You are eligible to apply for admission under the Visa Waiver Program (VWP) if you:<br />
<br />
*Intend to enter the United States for 90 days or less for business, pleasure or transit<br />
*Have a valid passport lawfully issued to you by a Visa Waiver Program country: http://www.esta.us/visa_waiver_countries.html<br />
*Have authorization to travel via the Electronic System for Travel Authorization: https://esta.cbp.dhs.gov/<br />
*Arrive via a Visa Waiver Program signatory carrier (all commercial airlines meet this requirement)<br />
*Have a return or onward ticket<br />
*Travel may not terminate in contiguous territory or adjacent islands unless the traveler is a resident of one of those areas<br />
<br />
=====Employee Travel FAQ=====<br />
This [https://mana.mozilla.org/wiki/display/PR/Travel+FAQ FAQ] addresses questions about how to handle security concerns and electronic devices at the border and how to engage with US Customs & Border Protection (CBP). While it specifically focuses on concerns related to travel to the United States, much of this guidance is applicable to travel elsewhere. Mana access required.<br />
<br />
=====Pocket Letter=====<br />
A pocket letter is recommended to keep on hand for those who are entering the United States. It should accompany you whether or not you are required to have a visa to enter. You may request a copy of that letter when you register online. Please contact immigration@mozilla.com if you require a specific letter for your visa application or if you have any questions regarding your citizenship, visa capabilities or travel related questions.<br />
<br />
=====ESTA Point of Contact=====<br />
In the ESTA application you need to give a "U.S. Point of Contact Information". <br />
<br />
Please list Heather Durham as your US Point of Contact.<br />
Address: 331 East Evelyn Avenue, Mountain View, CA 94041 Phone: 408.505.3028</div>Dbaronhttps://wiki.mozilla.org/index.php?title=All_Hands/SanFrancisco2017&diff=1168109All Hands/SanFrancisco20172017-04-12T07:53:10Z<p>Dbaron: /* Dates, Location and Weather */ fix again</p>
<hr />
<div>'''What is it?''' -- Multiple team meetings, happening in the same city, at the same time + some opportunity to get together as one big group as well as with other teams as it makes sense. Then, on the last day, we have a fun social event for all, Mozilla-style! <br />
<br />
'''''The information on this wiki primarily applies to Full time and contractor staff. If you are a volunteer contributor or intern, please inquire to your coordinator. '''''<br />
<br />
=='''Dates, Location and Weather'''==<br />
Monday, June 26 - Friday, June 30, 2017 (travel days are Monday the 26th & Saturday the 1st*) in San Francisco, CA.<br />
<br />
We are staying at [http://www3.hilton.com/en/hotels/california/hilton-san-francisco-union-square-SFOFHHH/index.html Hilton San Francisco Union Square] & [http://www.parc55hotel.com/ Parc 55] San Francisco. [https://osm.org/go/TZHvW7Hnn?m=&node=1941537172 map]<br />
<br />
''*For those countries where rest time is required on weekends (vs. work travel), Mozilla will cover a return on the next available work day, if you choose. This needs to pre-approved and pre-arranged.''<br />
<br />
Weather:<br />
* National Weather Service: [http://forecast.weather.gov/MapClick.php?smap=1&lat=37.785&lon=-122.410&unit=1&mp=1 forecast in ⁰C], [http://forecast.weather.gov/MapClick.php?smap=1&lat=37.785&lon=-122.410&mp=1 forecast in ⁰F]<br />
* Temperatures ''in downtown San Francisco'' in late June are likely to have nighttime lows around 10-13 ⁰C / 50-56 ⁰F and daytime highs around 16-24 ⁰C / 61-75 ⁰F. But the weather is very occasionally warmer with highs around 27⁰C / 81⁰F.<br />
* Weather in San Francisco in the summer is variable; it can become substantially cooler and foggier in the late afternoon; be prepared for temperatures to fall to 13⁰C / 56⁰F and the winds to pick up in the afternoon. Be prepared by carrying a warmer layer with you.<br />
* Weather in other parts of the Bay Area can be much warmer than in San Francisco, even if you're only traveling 15km away. Look at the weather forecasts. It's entirely possible for it to be 19⁰C / 66⁰F in San Francisco and simultaneously be 32⁰C / 90⁰F in Orinda. But if you're right on the ocean, the air temperature is likely to match the water temperature, which is probably around 12⁰C / 54⁰F.<br />
<br />
=='''Registration'''==<br />
This is an invite-only event.<br />
<br />
=====New Hires=====<br />
We have a process to identify new hires each Monday and will invite them to book travel. No action necessary from managers other than to let them know about the event. Please work closely with your recruiting manager as they are aware of all deadlines.<br />
<br />
=='''Food & Drink'''==<br />
Breakfast, lunch & snacks will be provided and paid for centrally for attendees. Details about dinners will be shared soon. <br />
<br />
=='''Hotel'''==<br />
Hotel rooms are reserved for all employees & volunteers to stay all week, including employees based in San Francisco (just as if we were somewhere you don't live). We encourage everyone to stay in the hotel and be a part of the full week's activities.<br />
<br />
=====Pre/post=====<br />
A link ''will be'' available to book hotel 3 days pre and 3 days post at our negotiated rate. The pre/post reservations will require the use of an LDAP email* so we can link them to your All Hands reservation. Rooms booked by any method except this link will not be linked to your main reservation. <br />
<br />
=='''Travel'''==<br />
Booking travel is now open. Please book itineraries by Friday, April 14, 2017. <br />
<br />
====Arriving Early/Departing Late Guidelines====<br />
<br />
Our standard travel guidelines apply (pre-populated in Egencia) when booking with a few additional budget constraints. Anything booked outside of them will require approval. Most people will arrive on Monday, June 26 and leave on Saturday, July 1. Here are some exceptions: <br />
* If you live in a country where work travel is prohibited on weekends, you may travel on Friday, June 23 and Monday, July 3, if you’d prefer (not required). For hotel, you will book and pay on your own, and expense the manager approved amount (which is coded to your cost center).<br />
* If you plan to spend some extra personal time in San Francisco (choosing to arrive before Monday, June 26 or depart after Saturday, July 1), you'll need to create an itinerary in Egencia for standard dates/locations within the San Francisco Portal and compare to the custom dates you'd like. Please share the difference via email to bmark@mozilla.com or through the approval comment box when you submit the flight. You can sway up to +$100 over and Mozilla will cover it. Otherwise you'll need to come with an alternate itinerary that fits within the pricing (like a round trip in and out of SFO w/ longer dates, and you personally book & cover the rest). We do not have the ability for employees to reimburse Mozilla for any overage.<br />
* If you are attending the Monday Core Influencer's event (by invite).<br />
* If you would like to arrive early to recover from jetlag, you will need manager approval for any additional costs associated with the extension. There is no unilateral "All Hands" approval based upon timezone to arrive early. For hotel, you will book and pay on your own, and expense the manager approved amount (which is coded to your cost center).<br />
<br />
====Booking Family Travel====<br />
Once travel has opened to staff, you may book family, whether they will accompany you on your flight or join us later; and you have two options: Direct or through Egencia. <br />
<br />
If you choose to book family through Egencia, please first book your own flight and then call Egencia with your airline confirmation number (staff do have to go through Egencia). Otherwise, you can book family direct (either through the airline or through another third party) and call the ticketing airline(s) with both confirmation numbers and ask them to link your reservations, so they know you are traveling together. They should also be able to assign seats together. You will avoid the limited hours Egencia offers and avoid paying their ticketing fee. <br />
<br />
If you prefer to book your family through Egencia, you can pay (including the Egencia booking fees) and coordinate with your own travel (recommend to book and then call/email Egencia with your itinerary number to match for family). Note that booking through Egencia does not put you on the same reservation, nor guarantee the reservations will be linked (you would still need to call the airline to link them). <br />
* '''Call:''' +1 (877) 264-1622 or +1 (417) 521-0273; Monday - Friday 9 am - 6 pm EST. If you call outside these hours, you will get an after hours agent, who may not be as helpful. <br />
* '''Email:''' egegrp@expedia.com. The email is monitored Monday - Friday 9 am - 6 pm EST. If you email, you will eventually need to call with a credit card (for fares & fees for family) and personal details of travelers, but the email can get the flights set-up. The agents will need to following information in the initial email to search for flights: Departure City (hometown) & Arrival City (should be SFO), Travel dates & Number of people traveling together + legal names<br />
<br />
====Large Device bans on flights====<br />
Recently, the United States and United Kingdom announced a ban on devices larger than a phone on certain flights and certain airlines. <br />
<br />
Inbound to the US, this affects 9 airlines + 10 Direct flights into the US<br />
Airline:<br />
*EgyptAir; Emirates<br />
*Etihad Airways<br />
*Kuwait Airways<br />
*Qatar Airways<br />
*Royal Air Maroc<br />
*Royal Jordanian<br />
*Saudia (Saudi Arabian Airlines)<br />
*Turkish Airlines) <br />
<br />
Direct flights from specific airports:<br />
Istanbul, Turkey; Dubai and Abu Dhabi in the United Arab Emirates; Doha, Qatar; Amman, Jordan; Cairo, Egypt; Casablanca, Morocco; Jeddah and Riyadh in Saudi Arabia; Kuwait City, Kuwait.<br />
<br />
Inbound to the UK affects all inbound flights from 6 countries: Turkey, Lebanon, Jordan, Saudi Arabia & Tunisia. <br />
<br />
What does this mean for you if you are traveling through one of these airports or on one of these airlines? Potentially: <br />
*a decision between # of layovers and having your devices with you<br />
*Not bringing devices<br />
*Checking devices & ensuring everything is secured and backed up<br />
<br />
Please make sure to check layovers to ensure you are either aware of the bans, or to avoid flights. Keep in mind that your flight doesn't have to originate in one of these cities to be banned. You could have a layover and still have challenges. <br />
<br />
====Travel Insurance====<br />
Mozilla provides emergency medical accident and illness cover for all global employees/interns and their dependents. You can view more information on [https://mana.mozilla.org/wiki/display/PR/Travel+Insurance+-+Business Mana]. This coverage begins at the time the you leave home to start your business trip. It also has a provision for a 14 day extension for leisure travel outside of the business travel. If you have additional questions, please email benefits@mozilla.com. <br />
<br />
Mozilla does not cover travel insurance for volunteers.<br />
<br />
=====''Air Travel Fine Print''=====<br />
Change fees will be covered by Mozilla for business reasons only. If you need a change and have manager approval, email bmark@mozilla.com prior to requesting the change with Egencia. Once you have approval, call Egencia to make the change at +1 (702) 939-2530 or +1-877-264-1622 (note this will not be possible without prior approval so be sure to get that by way of an email from your manager to Brianna Mark). If you are changing for personal reasons, the change in airfare, change fee and Egencia fee is your responsibility.<br />
<br />
Mozilla will not reimburse for Business/First class upgrades or tickets. <br />
<br />
Any submitted expenses needs to have an itinerary attached to ensure it is employee expenses only and within policy.<br />
<br />
=='''Ground Transportation'''==<br />
=====Airport Shuttle=====<br />
All Mozillians and guests who have flights arriving anytime on Monday, June 26th in San Francisco International Airport (SFO) and out on Saturday, July 1, will be transferred to the hotel. If you arrive into another airport (OAK or SJC) or on a different date, ground transportation is on your own.<br />
<br />
====Mountain View Office Shuttle====<br />
We will provide a shuttle from the Mountain View office on Monday, June 26th (time and qty TBA). We will return to Mountain View on Saturday, July 1. <br />
<br />
You can get dropped off or park at the office. Normal property and office security will keep an eye on your cars.<br />
<br />
=='''Immigration'''==<br />
'''Any''' questions on immigration should be sent to immigration@mozilla.com.<br />
<br />
If you are from a country that requires a B-1/B-2 business visitor visa to enter the US, please plan for it early as government processing times constantly change.<br />
<br />
Please visit the following website to learn more about the visa application process and timing for your country: http://travel.state.gov/content/visas/english/visit/visitor.html#overview. Current estimated processing times at the US Embassies and Consulates abroad can be found at: https://travel.state.gov/content/visas/en/general/wait-times.html/<br />
<br />
Some travelers may be eligible to travel to the United States without first applying for a B-1/B-2 visa, if they are eligible for the Visa Waiver Program (VWP or "ESTA"). You are eligible to apply for admission under the Visa Waiver Program (VWP) if you:<br />
<br />
*Intend to enter the United States for 90 days or less for business, pleasure or transit<br />
*Have a valid passport lawfully issued to you by a Visa Waiver Program country: http://www.esta.us/visa_waiver_countries.html<br />
*Have authorization to travel via the Electronic System for Travel Authorization: https://esta.cbp.dhs.gov/<br />
*Arrive via a Visa Waiver Program signatory carrier (all commercial airlines meet this requirement)<br />
*Have a return or onward ticket<br />
*Travel may not terminate in contiguous territory or adjacent islands unless the traveler is a resident of one of those areas<br />
<br />
=====Employee Travel FAQ=====<br />
This [https://mana.mozilla.org/wiki/display/PR/Travel+FAQ FAQ] addresses questions about how to handle security concerns and electronic devices at the border and how to engage with US Customs & Border Protection (CBP). While it specifically focuses on concerns related to travel to the United States, much of this guidance is applicable to travel elsewhere. Mana access required.<br />
<br />
=====Pocket Letter=====<br />
A pocket letter is recommended to keep on hand for those who are entering the United States. It should accompany you whether or not you are required to have a visa to enter. You may request a copy of that letter when you register online. Please contact immigration@mozilla.com if you require a specific letter for your visa application or if you have any questions regarding your citizenship, visa capabilities or travel related questions.<br />
<br />
=====ESTA Point of Contact=====<br />
In the ESTA application you need to give a "U.S. Point of Contact Information". <br />
<br />
Please list Heather Durham as your US Point of Contact.<br />
Address: 331 East Evelyn Avenue, Mountain View, CA 94041 Phone: 408.505.3028</div>Dbaronhttps://wiki.mozilla.org/index.php?title=All_Hands/SanFrancisco2017&diff=1168108All Hands/SanFrancisco20172017-04-12T07:52:40Z<p>Dbaron: /* Dates, Location and Weather */ fix my bad wiki markup</p>
<hr />
<div>'''What is it?''' -- Multiple team meetings, happening in the same city, at the same time + some opportunity to get together as one big group as well as with other teams as it makes sense. Then, on the last day, we have a fun social event for all, Mozilla-style! <br />
<br />
'''''The information on this wiki primarily applies to Full time and contractor staff. If you are a volunteer contributor or intern, please inquire to your coordinator. '''''<br />
<br />
=='''Dates, Location and Weather'''==<br />
Monday, June 26 - Friday, June 30, 2017 (travel days are Monday the 26th & Saturday the 1st*) in San Francisco, CA.<br />
<br />
We are staying at [http://www3.hilton.com/en/hotels/california/hilton-san-francisco-union-square-SFOFHHH/index.html Hilton San Francisco Union Square] & [http://www.parc55hotel.com/ Parc 55] San Francisco. [https://osm.org/go/TZHvW7Hnn?m=&node=1941537172 map]<br />
<br />
''*For those countries where rest time is required on weekends (vs. work travel), Mozilla will cover a return on the next available work day, if you choose. This needs to pre-approved and pre-arranged.''<br />
<br />
Weather:<br />
* National Weather Service: [http://forecast.weather.gov/MapClick.php?smap=1&lat=37.785&lon=-122.410&unit=1&mp=1 forecast in ⁰C], [http://forecast.weather.gov/MapClick.php?smap=1&lat=37.785&lon=-122.410&mp=1 forecast in ⁰F]<br />
* Temperatures 'in downtown San Francisco' in late June are likely to have nighttime lows around 10-13 ⁰C / 50-56 ⁰F and daytime highs around 16-24 ⁰C / 61-75 ⁰F. But the weather is very occasionally warmer with highs around 27⁰C / 81⁰F.<br />
* Weather in San Francisco in the summer is variable; it can become substantially cooler and foggier in the late afternoon; be prepared for temperatures to fall to 13⁰C / 56⁰F and the winds to pick up in the afternoon. Be prepared by carrying a warmer layer with you.<br />
* Weather in other parts of the Bay Area can be much warmer than in San Francisco, even if you're only traveling 15km away. Look at the weather forecasts. It's entirely possible for it to be 19⁰C / 66⁰F in San Francisco and simultaneously be 32⁰C / 90⁰F in Orinda. But if you're right on the ocean, the air temperature is likely to match the water temperature, which is probably around 12⁰C / 54⁰F.<br />
<br />
=='''Registration'''==<br />
This is an invite-only event.<br />
<br />
=====New Hires=====<br />
We have a process to identify new hires each Monday and will invite them to book travel. No action necessary from managers other than to let them know about the event. Please work closely with your recruiting manager as they are aware of all deadlines.<br />
<br />
=='''Food & Drink'''==<br />
Breakfast, lunch & snacks will be provided and paid for centrally for attendees. Details about dinners will be shared soon. <br />
<br />
=='''Hotel'''==<br />
Hotel rooms are reserved for all employees & volunteers to stay all week, including employees based in San Francisco (just as if we were somewhere you don't live). We encourage everyone to stay in the hotel and be a part of the full week's activities.<br />
<br />
=====Pre/post=====<br />
A link ''will be'' available to book hotel 3 days pre and 3 days post at our negotiated rate. The pre/post reservations will require the use of an LDAP email* so we can link them to your All Hands reservation. Rooms booked by any method except this link will not be linked to your main reservation. <br />
<br />
=='''Travel'''==<br />
Booking travel is now open. Please book itineraries by Friday, April 14, 2017. <br />
<br />
====Arriving Early/Departing Late Guidelines====<br />
<br />
Our standard travel guidelines apply (pre-populated in Egencia) when booking with a few additional budget constraints. Anything booked outside of them will require approval. Most people will arrive on Monday, June 26 and leave on Saturday, July 1. Here are some exceptions: <br />
* If you live in a country where work travel is prohibited on weekends, you may travel on Friday, June 23 and Monday, July 3, if you’d prefer (not required). For hotel, you will book and pay on your own, and expense the manager approved amount (which is coded to your cost center).<br />
* If you plan to spend some extra personal time in San Francisco (choosing to arrive before Monday, June 26 or depart after Saturday, July 1), you'll need to create an itinerary in Egencia for standard dates/locations within the San Francisco Portal and compare to the custom dates you'd like. Please share the difference via email to bmark@mozilla.com or through the approval comment box when you submit the flight. You can sway up to +$100 over and Mozilla will cover it. Otherwise you'll need to come with an alternate itinerary that fits within the pricing (like a round trip in and out of SFO w/ longer dates, and you personally book & cover the rest). We do not have the ability for employees to reimburse Mozilla for any overage.<br />
* If you are attending the Monday Core Influencer's event (by invite).<br />
* If you would like to arrive early to recover from jetlag, you will need manager approval for any additional costs associated with the extension. There is no unilateral "All Hands" approval based upon timezone to arrive early. For hotel, you will book and pay on your own, and expense the manager approved amount (which is coded to your cost center).<br />
<br />
====Booking Family Travel====<br />
Once travel has opened to staff, you may book family, whether they will accompany you on your flight or join us later; and you have two options: Direct or through Egencia. <br />
<br />
If you choose to book family through Egencia, please first book your own flight and then call Egencia with your airline confirmation number (staff do have to go through Egencia). Otherwise, you can book family direct (either through the airline or through another third party) and call the ticketing airline(s) with both confirmation numbers and ask them to link your reservations, so they know you are traveling together. They should also be able to assign seats together. You will avoid the limited hours Egencia offers and avoid paying their ticketing fee. <br />
<br />
If you prefer to book your family through Egencia, you can pay (including the Egencia booking fees) and coordinate with your own travel (recommend to book and then call/email Egencia with your itinerary number to match for family). Note that booking through Egencia does not put you on the same reservation, nor guarantee the reservations will be linked (you would still need to call the airline to link them). <br />
* '''Call:''' +1 (877) 264-1622 or +1 (417) 521-0273; Monday - Friday 9 am - 6 pm EST. If you call outside these hours, you will get an after hours agent, who may not be as helpful. <br />
* '''Email:''' egegrp@expedia.com. The email is monitored Monday - Friday 9 am - 6 pm EST. If you email, you will eventually need to call with a credit card (for fares & fees for family) and personal details of travelers, but the email can get the flights set-up. The agents will need to following information in the initial email to search for flights: Departure City (hometown) & Arrival City (should be SFO), Travel dates & Number of people traveling together + legal names<br />
<br />
====Large Device bans on flights====<br />
Recently, the United States and United Kingdom announced a ban on devices larger than a phone on certain flights and certain airlines. <br />
<br />
Inbound to the US, this affects 9 airlines + 10 Direct flights into the US<br />
Airline:<br />
*EgyptAir; Emirates<br />
*Etihad Airways<br />
*Kuwait Airways<br />
*Qatar Airways<br />
*Royal Air Maroc<br />
*Royal Jordanian<br />
*Saudia (Saudi Arabian Airlines)<br />
*Turkish Airlines) <br />
<br />
Direct flights from specific airports:<br />
Istanbul, Turkey; Dubai and Abu Dhabi in the United Arab Emirates; Doha, Qatar; Amman, Jordan; Cairo, Egypt; Casablanca, Morocco; Jeddah and Riyadh in Saudi Arabia; Kuwait City, Kuwait.<br />
<br />
Inbound to the UK affects all inbound flights from 6 countries: Turkey, Lebanon, Jordan, Saudi Arabia & Tunisia. <br />
<br />
What does this mean for you if you are traveling through one of these airports or on one of these airlines? Potentially: <br />
*a decision between # of layovers and having your devices with you<br />
*Not bringing devices<br />
*Checking devices & ensuring everything is secured and backed up<br />
<br />
Please make sure to check layovers to ensure you are either aware of the bans, or to avoid flights. Keep in mind that your flight doesn't have to originate in one of these cities to be banned. You could have a layover and still have challenges. <br />
<br />
====Travel Insurance====<br />
Mozilla provides emergency medical accident and illness cover for all global employees/interns and their dependents. You can view more information on [https://mana.mozilla.org/wiki/display/PR/Travel+Insurance+-+Business Mana]. This coverage begins at the time the you leave home to start your business trip. It also has a provision for a 14 day extension for leisure travel outside of the business travel. If you have additional questions, please email benefits@mozilla.com. <br />
<br />
Mozilla does not cover travel insurance for volunteers.<br />
<br />
=====''Air Travel Fine Print''=====<br />
Change fees will be covered by Mozilla for business reasons only. If you need a change and have manager approval, email bmark@mozilla.com prior to requesting the change with Egencia. Once you have approval, call Egencia to make the change at +1 (702) 939-2530 or +1-877-264-1622 (note this will not be possible without prior approval so be sure to get that by way of an email from your manager to Brianna Mark). If you are changing for personal reasons, the change in airfare, change fee and Egencia fee is your responsibility.<br />
<br />
Mozilla will not reimburse for Business/First class upgrades or tickets. <br />
<br />
Any submitted expenses needs to have an itinerary attached to ensure it is employee expenses only and within policy.<br />
<br />
=='''Ground Transportation'''==<br />
=====Airport Shuttle=====<br />
All Mozillians and guests who have flights arriving anytime on Monday, June 26th in San Francisco International Airport (SFO) and out on Saturday, July 1, will be transferred to the hotel. If you arrive into another airport (OAK or SJC) or on a different date, ground transportation is on your own.<br />
<br />
====Mountain View Office Shuttle====<br />
We will provide a shuttle from the Mountain View office on Monday, June 26th (time and qty TBA). We will return to Mountain View on Saturday, July 1. <br />
<br />
You can get dropped off or park at the office. Normal property and office security will keep an eye on your cars.<br />
<br />
=='''Immigration'''==<br />
'''Any''' questions on immigration should be sent to immigration@mozilla.com.<br />
<br />
If you are from a country that requires a B-1/B-2 business visitor visa to enter the US, please plan for it early as government processing times constantly change.<br />
<br />
Please visit the following website to learn more about the visa application process and timing for your country: http://travel.state.gov/content/visas/english/visit/visitor.html#overview. Current estimated processing times at the US Embassies and Consulates abroad can be found at: https://travel.state.gov/content/visas/en/general/wait-times.html/<br />
<br />
Some travelers may be eligible to travel to the United States without first applying for a B-1/B-2 visa, if they are eligible for the Visa Waiver Program (VWP or "ESTA"). You are eligible to apply for admission under the Visa Waiver Program (VWP) if you:<br />
<br />
*Intend to enter the United States for 90 days or less for business, pleasure or transit<br />
*Have a valid passport lawfully issued to you by a Visa Waiver Program country: http://www.esta.us/visa_waiver_countries.html<br />
*Have authorization to travel via the Electronic System for Travel Authorization: https://esta.cbp.dhs.gov/<br />
*Arrive via a Visa Waiver Program signatory carrier (all commercial airlines meet this requirement)<br />
*Have a return or onward ticket<br />
*Travel may not terminate in contiguous territory or adjacent islands unless the traveler is a resident of one of those areas<br />
<br />
=====Employee Travel FAQ=====<br />
This [https://mana.mozilla.org/wiki/display/PR/Travel+FAQ FAQ] addresses questions about how to handle security concerns and electronic devices at the border and how to engage with US Customs & Border Protection (CBP). While it specifically focuses on concerns related to travel to the United States, much of this guidance is applicable to travel elsewhere. Mana access required.<br />
<br />
=====Pocket Letter=====<br />
A pocket letter is recommended to keep on hand for those who are entering the United States. It should accompany you whether or not you are required to have a visa to enter. You may request a copy of that letter when you register online. Please contact immigration@mozilla.com if you require a specific letter for your visa application or if you have any questions regarding your citizenship, visa capabilities or travel related questions.<br />
<br />
=====ESTA Point of Contact=====<br />
In the ESTA application you need to give a "U.S. Point of Contact Information". <br />
<br />
Please list Heather Durham as your US Point of Contact.<br />
Address: 331 East Evelyn Avenue, Mountain View, CA 94041 Phone: 408.505.3028</div>Dbaronhttps://wiki.mozilla.org/index.php?title=All_Hands/SanFrancisco2017&diff=1168107All Hands/SanFrancisco20172017-04-12T07:52:02Z<p>Dbaron: /* Dates, Location and Weather */ add some Weather info since it will be surprising to many folks</p>
<hr />
<div>'''What is it?''' -- Multiple team meetings, happening in the same city, at the same time + some opportunity to get together as one big group as well as with other teams as it makes sense. Then, on the last day, we have a fun social event for all, Mozilla-style! <br />
<br />
'''''The information on this wiki primarily applies to Full time and contractor staff. If you are a volunteer contributor or intern, please inquire to your coordinator. '''''<br />
<br />
=='''Dates, Location and Weather'''==<br />
Monday, June 26 - Friday, June 30, 2017 (travel days are Monday the 26th & Saturday the 1st*) in San Francisco, CA.<br />
<br />
We are staying at [http://www3.hilton.com/en/hotels/california/hilton-san-francisco-union-square-SFOFHHH/index.html Hilton San Francisco Union Square] & [http://www.parc55hotel.com/ Parc 55] San Francisco. [https://osm.org/go/TZHvW7Hnn?m=&node=1941537172 map]<br />
<br />
''*For those countries where rest time is required on weekends (vs. work travel), Mozilla will cover a return on the next available work day, if you choose. This needs to pre-approved and pre-arranged.''<br />
<br />
Weather:<br />
* National Weather Service: [http://forecast.weather.gov/MapClick.php?smap=1&lat=37.785&lon=-122.410&unit=1&mp=1 forecast in ⁰C], [http://forecast.weather.gov/MapClick.php?smap=1&lat=37.785&lon=-122.410&mp=1 forecast in ⁰F]<br />
* Temperatures *in downtown San Francisco* in late June are likely to have nighttime lows around 10-13 ⁰C / 50-56 ⁰F and daytime highs around 16-24 ⁰C / 61-75 ⁰F. But the weather is very occasionally warmer with highs around 27⁰C / 81⁰F.<br />
* Weather in San Francisco in the summer is variable; it can become substantially cooler and foggier in the late afternoon; be prepared for temperatures to fall to 13⁰C / 56⁰F and the winds to pick up in the afternoon. Be prepared by carrying a warmer layer with you.<br />
* Weather in other parts of the Bay Area can be much warmer than in San Francisco, even if you're only traveling 15km away. Look at the weather forecasts. It's entirely possible for it to be 19⁰C / 66⁰F in San Francisco and simultaneously be 32⁰C / 90⁰F in Orinda. But if you're right on the ocean, the air temperature is likely to match the water temperature, which is probably around 12⁰C / 54⁰F.<br />
<br />
=='''Registration'''==<br />
This is an invite-only event.<br />
<br />
=====New Hires=====<br />
We have a process to identify new hires each Monday and will invite them to book travel. No action necessary from managers other than to let them know about the event. Please work closely with your recruiting manager as they are aware of all deadlines.<br />
<br />
=='''Food & Drink'''==<br />
Breakfast, lunch & snacks will be provided and paid for centrally for attendees. Details about dinners will be shared soon. <br />
<br />
=='''Hotel'''==<br />
Hotel rooms are reserved for all employees & volunteers to stay all week, including employees based in San Francisco (just as if we were somewhere you don't live). We encourage everyone to stay in the hotel and be a part of the full week's activities.<br />
<br />
=====Pre/post=====<br />
A link ''will be'' available to book hotel 3 days pre and 3 days post at our negotiated rate. The pre/post reservations will require the use of an LDAP email* so we can link them to your All Hands reservation. Rooms booked by any method except this link will not be linked to your main reservation. <br />
<br />
=='''Travel'''==<br />
Booking travel is now open. Please book itineraries by Friday, April 14, 2017. <br />
<br />
====Arriving Early/Departing Late Guidelines====<br />
<br />
Our standard travel guidelines apply (pre-populated in Egencia) when booking with a few additional budget constraints. Anything booked outside of them will require approval. Most people will arrive on Monday, June 26 and leave on Saturday, July 1. Here are some exceptions: <br />
* If you live in a country where work travel is prohibited on weekends, you may travel on Friday, June 23 and Monday, July 3, if you’d prefer (not required). For hotel, you will book and pay on your own, and expense the manager approved amount (which is coded to your cost center).<br />
* If you plan to spend some extra personal time in San Francisco (choosing to arrive before Monday, June 26 or depart after Saturday, July 1), you'll need to create an itinerary in Egencia for standard dates/locations within the San Francisco Portal and compare to the custom dates you'd like. Please share the difference via email to bmark@mozilla.com or through the approval comment box when you submit the flight. You can sway up to +$100 over and Mozilla will cover it. Otherwise you'll need to come with an alternate itinerary that fits within the pricing (like a round trip in and out of SFO w/ longer dates, and you personally book & cover the rest). We do not have the ability for employees to reimburse Mozilla for any overage.<br />
* If you are attending the Monday Core Influencer's event (by invite).<br />
* If you would like to arrive early to recover from jetlag, you will need manager approval for any additional costs associated with the extension. There is no unilateral "All Hands" approval based upon timezone to arrive early. For hotel, you will book and pay on your own, and expense the manager approved amount (which is coded to your cost center).<br />
<br />
====Booking Family Travel====<br />
Once travel has opened to staff, you may book family, whether they will accompany you on your flight or join us later; and you have two options: Direct or through Egencia. <br />
<br />
If you choose to book family through Egencia, please first book your own flight and then call Egencia with your airline confirmation number (staff do have to go through Egencia). Otherwise, you can book family direct (either through the airline or through another third party) and call the ticketing airline(s) with both confirmation numbers and ask them to link your reservations, so they know you are traveling together. They should also be able to assign seats together. You will avoid the limited hours Egencia offers and avoid paying their ticketing fee. <br />
<br />
If you prefer to book your family through Egencia, you can pay (including the Egencia booking fees) and coordinate with your own travel (recommend to book and then call/email Egencia with your itinerary number to match for family). Note that booking through Egencia does not put you on the same reservation, nor guarantee the reservations will be linked (you would still need to call the airline to link them). <br />
* '''Call:''' +1 (877) 264-1622 or +1 (417) 521-0273; Monday - Friday 9 am - 6 pm EST. If you call outside these hours, you will get an after hours agent, who may not be as helpful. <br />
* '''Email:''' egegrp@expedia.com. The email is monitored Monday - Friday 9 am - 6 pm EST. If you email, you will eventually need to call with a credit card (for fares & fees for family) and personal details of travelers, but the email can get the flights set-up. The agents will need to following information in the initial email to search for flights: Departure City (hometown) & Arrival City (should be SFO), Travel dates & Number of people traveling together + legal names<br />
<br />
====Large Device bans on flights====<br />
Recently, the United States and United Kingdom announced a ban on devices larger than a phone on certain flights and certain airlines. <br />
<br />
Inbound to the US, this affects 9 airlines + 10 Direct flights into the US<br />
Airline:<br />
*EgyptAir; Emirates<br />
*Etihad Airways<br />
*Kuwait Airways<br />
*Qatar Airways<br />
*Royal Air Maroc<br />
*Royal Jordanian<br />
*Saudia (Saudi Arabian Airlines)<br />
*Turkish Airlines) <br />
<br />
Direct flights from specific airports:<br />
Istanbul, Turkey; Dubai and Abu Dhabi in the United Arab Emirates; Doha, Qatar; Amman, Jordan; Cairo, Egypt; Casablanca, Morocco; Jeddah and Riyadh in Saudi Arabia; Kuwait City, Kuwait.<br />
<br />
Inbound to the UK affects all inbound flights from 6 countries: Turkey, Lebanon, Jordan, Saudi Arabia & Tunisia. <br />
<br />
What does this mean for you if you are traveling through one of these airports or on one of these airlines? Potentially: <br />
*a decision between # of layovers and having your devices with you<br />
*Not bringing devices<br />
*Checking devices & ensuring everything is secured and backed up<br />
<br />
Please make sure to check layovers to ensure you are either aware of the bans, or to avoid flights. Keep in mind that your flight doesn't have to originate in one of these cities to be banned. You could have a layover and still have challenges. <br />
<br />
====Travel Insurance====<br />
Mozilla provides emergency medical accident and illness cover for all global employees/interns and their dependents. You can view more information on [https://mana.mozilla.org/wiki/display/PR/Travel+Insurance+-+Business Mana]. This coverage begins at the time the you leave home to start your business trip. It also has a provision for a 14 day extension for leisure travel outside of the business travel. If you have additional questions, please email benefits@mozilla.com. <br />
<br />
Mozilla does not cover travel insurance for volunteers.<br />
<br />
=====''Air Travel Fine Print''=====<br />
Change fees will be covered by Mozilla for business reasons only. If you need a change and have manager approval, email bmark@mozilla.com prior to requesting the change with Egencia. Once you have approval, call Egencia to make the change at +1 (702) 939-2530 or +1-877-264-1622 (note this will not be possible without prior approval so be sure to get that by way of an email from your manager to Brianna Mark). If you are changing for personal reasons, the change in airfare, change fee and Egencia fee is your responsibility.<br />
<br />
Mozilla will not reimburse for Business/First class upgrades or tickets. <br />
<br />
Any submitted expenses needs to have an itinerary attached to ensure it is employee expenses only and within policy.<br />
<br />
=='''Ground Transportation'''==<br />
=====Airport Shuttle=====<br />
All Mozillians and guests who have flights arriving anytime on Monday, June 26th in San Francisco International Airport (SFO) and out on Saturday, July 1, will be transferred to the hotel. If you arrive into another airport (OAK or SJC) or on a different date, ground transportation is on your own.<br />
<br />
====Mountain View Office Shuttle====<br />
We will provide a shuttle from the Mountain View office on Monday, June 26th (time and qty TBA). We will return to Mountain View on Saturday, July 1. <br />
<br />
You can get dropped off or park at the office. Normal property and office security will keep an eye on your cars.<br />
<br />
=='''Immigration'''==<br />
'''Any''' questions on immigration should be sent to immigration@mozilla.com.<br />
<br />
If you are from a country that requires a B-1/B-2 business visitor visa to enter the US, please plan for it early as government processing times constantly change.<br />
<br />
Please visit the following website to learn more about the visa application process and timing for your country: http://travel.state.gov/content/visas/english/visit/visitor.html#overview. Current estimated processing times at the US Embassies and Consulates abroad can be found at: https://travel.state.gov/content/visas/en/general/wait-times.html/<br />
<br />
Some travelers may be eligible to travel to the United States without first applying for a B-1/B-2 visa, if they are eligible for the Visa Waiver Program (VWP or "ESTA"). You are eligible to apply for admission under the Visa Waiver Program (VWP) if you:<br />
<br />
*Intend to enter the United States for 90 days or less for business, pleasure or transit<br />
*Have a valid passport lawfully issued to you by a Visa Waiver Program country: http://www.esta.us/visa_waiver_countries.html<br />
*Have authorization to travel via the Electronic System for Travel Authorization: https://esta.cbp.dhs.gov/<br />
*Arrive via a Visa Waiver Program signatory carrier (all commercial airlines meet this requirement)<br />
*Have a return or onward ticket<br />
*Travel may not terminate in contiguous territory or adjacent islands unless the traveler is a resident of one of those areas<br />
<br />
=====Employee Travel FAQ=====<br />
This [https://mana.mozilla.org/wiki/display/PR/Travel+FAQ FAQ] addresses questions about how to handle security concerns and electronic devices at the border and how to engage with US Customs & Border Protection (CBP). While it specifically focuses on concerns related to travel to the United States, much of this guidance is applicable to travel elsewhere. Mana access required.<br />
<br />
=====Pocket Letter=====<br />
A pocket letter is recommended to keep on hand for those who are entering the United States. It should accompany you whether or not you are required to have a visa to enter. You may request a copy of that letter when you register online. Please contact immigration@mozilla.com if you require a specific letter for your visa application or if you have any questions regarding your citizenship, visa capabilities or travel related questions.<br />
<br />
=====ESTA Point of Contact=====<br />
In the ESTA application you need to give a "U.S. Point of Contact Information". <br />
<br />
Please list Heather Durham as your US Point of Contact.<br />
Address: 331 East Evelyn Avenue, Mountain View, CA 94041 Phone: 408.505.3028</div>Dbaron