One could possibly make larger changes to make the setup less error prone, but hopefully we'll
replace this code with the new scheduler relatively soon.
And the assertion there should still enforce correct behavior.
Differential Revision: https://phabricator.services.mozilla.com/D69988
--HG--
extra : moz-landing-system : lando
Through their use of Smprintf, the existing warning message formatting
is resistant to OOM errors. So I figured that we should probably use
something that doesn't infallibly allocate like GetErrorName does.
Differential Revision: https://phabricator.services.mozilla.com/D70771
--HG--
extra : moz-landing-system : lando
This commit removes `test_fix_stack_using_bpsyms.py`. That test can't easily be
modified to work with `fix_stacks.py` because it relies on internal
implementation details of `fix_stack_using_bpsym.py`. The unit testing done in
the `fix-stacks` repo provides test coverage that is as good or better.
Differential Revision: https://phabricator.services.mozilla.com/D66924
--HG--
extra : moz-landing-system : lando
The instantiations of the externed templates need to be in the same translation unit as the definitions. Currently they work due to building in unified mode.
Differential Revision: https://phabricator.services.mozilla.com/D69467
--HG--
extra : moz-landing-system : lando
This is necessary to avoid the use of setOriginAttributesBeforeLoading, which is
being removed in this patch set.
Differential Revision: https://phabricator.services.mozilla.com/D67042
--HG--
extra : moz-landing-system : lando
Also moves `nsThreadShutdownContext` to `nsThread.h` so it can be used by `nsThreadPool`.
Differential Revision: https://phabricator.services.mozilla.com/D69657
--HG--
extra : moz-landing-system : lando
TabGroup never really made any difference in which thread something go
dispatched to. This was the intended use, but development of TabGroups
with abstract main threads never made it that far. The good thing is
that thish makes it safe to also remove to the SystemGroup and instead
switch all SystemGroup dispatches to dispatches to main thread.
Timers for setTimeout and workers were the sole users of wrapped and
throttled event targets, that those throttled queues have been moved
to the BrowsingContextGroup and are now accessed explicitly.
The SchedulerEventTarget has been removed, since there are no longer a
separate event target for every TaskCategory. Instead a
LabellingEventTarget has been added to DocGroup to handle the case
where an event is dispatched do DocGroup or when an AbstractThread is
created using a DocGroup. This means that we'll actually label more
events correctly with the DocGroup that they belong to.
DocGroups have also been moved to BrowsingContextGroup.
Depends on D67636
Differential Revision: https://phabricator.services.mozilla.com/D65936
--HG--
extra : moz-landing-system : lando
This patch also tries to remove the event target entirely if it would
default to the main thread on a null event target.
Depends on D67634
Differential Revision: https://phabricator.services.mozilla.com/D67635
--HG--
extra : moz-landing-system : lando
To be able to remove SystemGroup, NS_ReleaseOnMainThreadSystemGroup
needs to have its dependency on SystemGroup removed. Since all
releases using SystemGroup would've released on the main thread anyway
we can safely replace NS_ReleaseOnMainThreadSystemGroup with
NS_ReleaseOnMainThread.
Depends on D64390
Differential Revision: https://phabricator.services.mozilla.com/D67631
--HG--
extra : moz-landing-system : lando
We cache this information in compatibility.ini so we can just expose it on
nsIXULRuntime.
Differential Revision: https://phabricator.services.mozilla.com/D66112
--HG--
extra : moz-landing-system : lando
This makes nsTHashtable usable with range-based for and STL-style algorithms.
Differential Revision: https://phabricator.services.mozilla.com/D69522
--HG--
extra : moz-landing-system : lando
Implement DOM interfaces for the WebXR Core Module. Additional work to implement the WebXR Core Module are marked with TODO (Bug #) comments within the patch and must be landed before enabling the dom.vr.webxr.enabled flag.
Differential Revision: https://phabricator.services.mozilla.com/D62369
--HG--
extra : moz-landing-system : lando
This makes nsTHashtable usable with range-based for and STL-style algorithms.
Differential Revision: https://phabricator.services.mozilla.com/D69522
--HG--
extra : moz-landing-system : lando
In the Windows API, the maximum length for a path is MAX_PATH in general.
However, the Windows API has many functions that also have Unicode versions to
permit an extended-length path for a maximum total path length of 32,767
characters. To specify an extended-length path, use the "\\?\" prefix.
A path component which ends with a dot is not allowed for Windows API. However,
using the "\\?\" prefix can also resolved this issue.
This patch aims to fix the issues which are mentioned above by prepending the
prefix to the path of nsLocalFile if mDisableStringParsing is set to true.
Differential Revision: https://phabricator.services.mozilla.com/D67014
--HG--
extra : moz-landing-system : lando
This commit adds a `dispatch_with_options` method to Rust task
runnables, which takes a builder-style `DispatchOptions`
argument controlling how the runnable should be dispatched.
Currently, the only supported option is `may_block`, which
corresponds to `nsIEventTarget::DISPATCH_EVENT_MAY_BLOCK`.
Differential Revision: https://phabricator.services.mozilla.com/D68688
--HG--
extra : moz-landing-system : lando
Also adds missing includes in some files, these were previously only transivitely
included through mozilla/TypeTraits.h.
Differential Revision: https://phabricator.services.mozilla.com/D68561
--HG--
extra : moz-landing-system : lando
Also move MOZ_MUST_USE before function declarations' specifiers and return type. While clang and gcc's __attribute__((warn_unused_result)) can appear before, between, or after function specifiers and return types, the [[nodiscard]] attribute must precede the function specifiers.
Also remove MOZ_MUST_USE from nsIMemoryReporter's function pointer typedefs. [[nodiscard]] is an attribute of a function's declaration, not the function's type, and thus can't be applied to function pointers or lambdas.
Differential Revision: https://phabricator.services.mozilla.com/D68138
--HG--
extra : moz-landing-system : lando
This is being added to facilitate moving generation of the update URL to Rust (Bug 1567286). Once that has been completed, we should be able to remove the update URL from its current location in firefox.js so that it is not being duplicated in application.ini.
Differential Revision: https://phabricator.services.mozilla.com/D43300
--HG--
extra : moz-landing-system : lando
We cache this information in compatibility.ini so we can just expose it on
nsIXULRuntime.
Differential Revision: https://phabricator.services.mozilla.com/D66112
--HG--
extra : moz-landing-system : lando
Set the flag on the affected classes, which are:
- CallbackTimeoutHandler
- nsJSArgArray
- CallbackObject
- Console
- MessageEvent
- IDBIndexCursor
- ExtendableMessageEvent
- JSPurpleBuffer
Differential Revision: https://phabricator.services.mozilla.com/D68196
--HG--
extra : moz-landing-system : lando
This adds the flag itself and a means of setting it for a cycle collected class.
The proper way to do this would be to add versions of all the NS_DECL_CYCLE_COLLECTION_CLASS macros that also set this flag but we end up needing to create separate versions for five of these and it's a lot of macro code to add. Here I added a version of NS_IMPL_CYCLE_COLLECTION_CLASS that sets the flag. This has the disadvantage that it wouldn't work well if we needed to set the flag on a base class as we'd have to use this macro for every derived class. However that situation doesn't actually arise (and ideally this flag will bet set on the fewest number of classes possible).
Differential Revision: https://phabricator.services.mozilla.com/D68195
--HG--
extra : moz-landing-system : lando
Currently classes derived from nsCycleCollectionParicipant have one flag to pass and adding more makes the class delcaration macros get messy really quickly. This patch replaces boolean flags with a bitfield which makes adding new flags easier.
Differential Revision: https://phabricator.services.mozilla.com/D68194
--HG--
extra : moz-landing-system : lando
We cache this information in compatibility.ini so we can just expose it on
nsIXULRuntime.
Differential Revision: https://phabricator.services.mozilla.com/D66112
--HG--
extra : moz-landing-system : lando
Now that we have some per-zone vectors we can skip tracing those for zones that are not being collected.
Differential Revision: https://phabricator.services.mozilla.com/D68523
--HG--
extra : moz-landing-system : lando
Currently the JS holders table is represented as a map which contains pointers to entries in a SegmentedVector. This patch keeps the single map but use a vector per zone and also has a catch-all vector for where we don't know the zone or the holder can have pointers to more than one zone.
Differential Revision: https://phabricator.services.mozilla.com/D68522
--HG--
extra : moz-landing-system : lando
Currently, to remove a holder entry from a vector we swap the entry with the last one in the vector and then shrink the vector (and fix up the map). With per-zone vectors we won't have a reference to the vector to get the last entry. One solution would be to store the zone in the entry and look up the vector in a map but I'd like to avoid this if possible because of the space overhead and the extra lookup.
This patch defers clears the entry's pointers when it is removed and actually removes it when the vector is next iterated.
Differential Revision: https://phabricator.services.mozilla.com/D68518
--HG--
extra : moz-landing-system : lando
This is necessary to avoid the use of setOriginAttributesBeforeLoading, which is
being removed in this patch set.
Differential Revision: https://phabricator.services.mozilla.com/D67042
--HG--
extra : moz-landing-system : lando
We cache this information in compatibility.ini so we can just expose it on
nsIXULRuntime.
Differential Revision: https://phabricator.services.mozilla.com/D66112
--HG--
extra : moz-landing-system : lando
To correctly implement this, it must be known on instantiation whether E is
copy-constructible, which is not the case if only a forward declaration is
available. This can be resolved either by making sure a full definition of E is
available, which is preferable. But in cases where this is not (easily) possible,
the information can be explicitly provided by the MOZ_DECLARE_COPY_CONSTRUCTIBLE
and MOZ_DECLARE_NON_COPY_CONSTRUCTIBLE macros. In particular, declarations for
IPDL-declared types are added to nsTArray.h itself, like it was already done
for MOZ_DECLARE_RELOCATE_USING_MOVE_CONSTRUCTOR.
Differential Revision: https://phabricator.services.mozilla.com/D66244
--HG--
extra : moz-landing-system : lando
Specifically, this renames
* nsTArray_CopyChooser to nsTArray_RelocationStrategy
* the Copy template argument of nsTArray_base to RelocationStrategy
* nsTArray_CopyWithConstructors to nsTArray_RelocateUsingMoveConstructor
* nsTArray_CopyWithMemutils to nsTArray_RelocateUsingMemutils
* DECLARE_USE_COPY_CONSTRUCTORS to MOZ_DECLARE_RELOCATE_USING_MOVE_CONSTRUCTOR
Differential Revision: https://phabricator.services.mozilla.com/D66243
--HG--
extra : moz-landing-system : lando
This works on all platforms with the exception of Linux where we remove the
exception handler only if the sandbox is disabled. With the sandbox enabled we
would have to whitelist sigaltstack() which breakpad uses to remove the
alternate signal stack which is not worth the fuss.
Besides this patch refactors the code that sets and unsets the exception
handler, cutting down on the duplication:
* The XRE_UnsetRemoteExceptionHandler() call is removed from XULAppAPI.h since it
was no longer used
* The duplicate checks for the special strings used to disable the remote exception
handler have been removed from CrashReporter::UnsetRemoteExceptionHandler()
leaving them in the calling code
* The SetRemoteExceptionHandler() function was consolidated into only one
piece of code with only one non-platform-specific shared prototype
* Some additional code was factored out to improve the readability
These changes pave the way both for bug 1614933 and for the oxidation of the
exception handler code.
Differential Revision: https://phabricator.services.mozilla.com/D67213
--HG--
extra : moz-landing-system : lando
- Do not remove elements one-by-one but use remove-erase pattern.
- Move mPendingIDBTransactions array instead of copying.
Differential Revision: https://phabricator.services.mozilla.com/D67159
--HG--
extra : moz-landing-system : lando
Ply doesn't actually support python3. The generation of the files seems
to work with python3 for some reason, but running the corresponding
tests doesn't. The only version of ply that supports python3 is
currently in beta, so upgrading ply is probably not an option at the
moment.
Other commands that do use ply (mach webidl-parser-test and
ipc/ipdl/Makefile.in) have not switched to python3 (probably because
they don't work). Let's go with the simpler thing for now: switch back
to python 2 for xpidllex.py and xpidlyacc.py, which will make them
deterministically created again.
Differential Revision: https://phabricator.services.mozilla.com/D67400
--HG--
extra : moz-landing-system : lando
This never worked, but it's more visible with the new form controls which have
more padding.
Make the anonymous div and co a pseudo-element, so that they inherit from the
<input> properly in all cases. This works for non-number inputs because the
editor root is a direct child of the <input>, but it doesn't for number inputs
because there's a flex wrapper in between.
This way overflow-clip-box: inherit does what we want. Reset the padding in the
inline direction, as the padding for <input type=number> applies to the arrow
boxes as well, and thus we'd double-apply it.
Differential Revision: https://phabricator.services.mozilla.com/D65271
--HG--
extra : moz-landing-system : lando
There's no existing macro to allow use declare a final
DeleteCycleCollectable, this patch adds one
Differential Revision: https://phabricator.services.mozilla.com/D63262
--HG--
extra : moz-landing-system : lando
This commit moves `NS_CreateBackgroundTaskQueue` into an `extern "C"`
block, adds a `create_background_task_queue` function to `moz_task`,
and makes it possible to dispatch Rust `TaskRunnable`s to any event
target, instead of just an `nsIThread`.
Differential Revision: https://phabricator.services.mozilla.com/D66700
--HG--
extra : moz-landing-system : lando
This is one of the efforts to reduce usage of `ShellExecuteByExplorer`
(bug 1620335).
The purpose of using `ShellExecuteByExplorer` in the scenario to open a
downloaded file is to support applications which are not compatible with
the mitigation policies of our process. When a downloaded file is an
executable, however, we prefer security to compatibility and in particular
we want to prevent binary planting on a user's download directory.
The proposed fix is to go to `ShellExecuteExW` straight if the target
file to launch is an executable.
Differential Revision: https://phabricator.services.mozilla.com/D66325
--HG--
extra : moz-landing-system : lando
This is one of the efforts to reduce usage of `ShellExecuteByExplorer`
(bug 1620335).
The purpose of using `ShellExecuteByExplorer` in the scenario to open a
downloaded file is to support applications which are not compatible with
the mitigation policies of our process. When a downloaded file is an
executable, however, we prefer security to compatibility and in particular
we want to prevent binary planting on a user's download directory.
The proposed fix is to go to `ShellExecuteExW` straight if the target
file to launch is an executable.
Differential Revision: https://phabricator.services.mozilla.com/D66325
--HG--
extra : moz-landing-system : lando
BrowserTestUtils.crashFrame now accepts additional `options`, with an argument `crashType` that may
take "CRASH_OOM" or "CRASH_INVALID_POINTER_DEREF"|null to specify the nature of the crash. The names
are taken from CrashTestUtils.jsm but this module cannot be imported as such as it has non-trivial
binary dependencies.
Depends on D54130
Differential Revision: https://phabricator.services.mozilla.com/D54700
--HG--
extra : moz-landing-system : lando
Right now, we sync finalize for a sync GC, even if it is triggered by the JS
engine itself. This can cause issues because the finalizer can run JS, which
can break assumptions made by the JIT.
This patch avoids that by running the finalizers incrementally for most internal
GC triggers. We still run sync for DESTROY_RUNTIME because we're going to shut
down right away.
Differential Revision: https://phabricator.services.mozilla.com/D65649
--HG--
extra : moz-landing-system : lando
The BindingCallContext tracks what method the conversion is for, and the source
description is how the primitive is involved in that method (e.g. "argument 5").
Differential Revision: https://phabricator.services.mozilla.com/D64887
--HG--
extra : moz-landing-system : lando
The BindingCallContext tracks what method the conversion is for, and the source
description is how the primitive is involved in that method (e.g. "argument 5").
Differential Revision: https://phabricator.services.mozilla.com/D64887
--HG--
extra : moz-landing-system : lando
This is already done for the outer nsJAR, but it wasn't done for the inner nsJAR.
(The omnijar is a nested zip archive on Android: the outer archive is the APK and the inner is the omnijar file.)
So we were re-using the file mapping but not the result of the uncompression.
Differential Revision: https://phabricator.services.mozilla.com/D63970
--HG--
extra : moz-landing-system : lando
Idle runnables do weird things involving unlocking the event queue mutex while
looking for runnables, such that queueing one from off the main thread might
cause it to basically never run if it gets queued during one of those
temporary-unlock periods.
Differential Revision: https://phabricator.services.mozilla.com/D65019
--HG--
extra : moz-landing-system : lando
Note that perfecthash.py is also used by other scripts, so it needs to
remain py2 compatible for now.
Differential Revision: https://phabricator.services.mozilla.com/D64620
--HG--
extra : moz-landing-system : lando
Make it a regular stylesheet.
This allows it to be cached in shared memory if possible, and will allow me to
stop adding the stylesheet based on a pref for bug 1618202.
Differential Revision: https://phabricator.services.mozilla.com/D64377
--HG--
rename : mobile/android/themes/geckoview/content.css => layout/style/res/geckoview.css
extra : moz-landing-system : lando
Make it a regular stylesheet.
This allows it to be cached in shared memory if possible, and will allow me to
stop adding the stylesheet based on a pref for bug 1618202.
Differential Revision: https://phabricator.services.mozilla.com/D64377
--HG--
rename : mobile/android/themes/geckoview/content.css => layout/style/res/geckoview.css
extra : moz-landing-system : lando
We are intending to advance the toolkit.shutdown.lateWriteChecksStage
pref, to collect information (and crash on DEBUG) about writes which
happen during and after the xpcom-shutdown-threads notification. This
is producing failures in the PrintTargetPDF.cpp destructor because
we end up calling write_func and writing to (I presume) the target
PDF. This _feels_ like something we can just skip, so that's the
review request I am sending, but please let me know if it's critical
that we write to this file during shutdown.
Differential Revision: https://phabricator.services.mozilla.com/D63218
--HG--
extra : moz-landing-system : lando
This moves the late write checking forward to before xpcom-shutdown-threads
in Nightly, and it turns it on for after the last cycle collection on
beta/release.
Differential Revision: https://phabricator.services.mozilla.com/D63215
--HG--
extra : moz-landing-system : lando
We want to be able to send IPC messages from the translation in the parent. So
the simplest thing it move the top level actor parts of CanvasParent into
CanvasTranslator.
This patch also moves the canvas thread management parts out into a new
CanvasThreadHolder class and hopefully makes the lifecycle management of these
much more robust. This includes the use of a TaskQueue per CanvasTranslator to
manage serial processing on the canvas workers, instead of a boolean.
Differential Revision: https://phabricator.services.mozilla.com/D60887
--HG--
rename : gfx/layers/ipc/CanvasParent.cpp => gfx/layers/ipc/CanvasThread.cpp
rename : gfx/layers/ipc/CanvasParent.h => gfx/layers/ipc/CanvasThread.h
rename : gfx/layers/CanvasTranslator.cpp => gfx/layers/ipc/CanvasTranslator.cpp
rename : gfx/layers/CanvasTranslator.h => gfx/layers/ipc/CanvasTranslator.h
extra : moz-landing-system : lando
This removes the need for explicit #ifdef NS_BUILD_REFCNT_LOGGING without
introducing user-defined destructors when it is not defined.
Also, some uses of virtual for declaring destructors are replaced by the
appropriate override declaration through these changes.
Differential Revision: https://phabricator.services.mozilla.com/D62604
--HG--
extra : moz-landing-system : lando
This removes the need for explicit #ifdef NS_BUILD_REFCNT_LOGGING without
introducing user-defined destructors when it is not defined.
Also, some uses of virtual for declaring destructors are replaced by the
appropriate override declaration through these changes.
Differential Revision: https://phabricator.services.mozilla.com/D62604
--HG--
extra : moz-landing-system : lando
GENERATED_FILES now defaults to python3 unless py2=True is specified as
an argument. All existing GENERATED_FILES scripts and GeneratedFile
templates have the py2=True attribute added, so this patch should
effectively be a no-op.
Going forward, individual scripts can be converted to python3 and their
corresponding py2=True attribute can be deleted. In effect, this patch
will be backed out in pieces until all scripts run in python3, at which
point the py2 attribute itself can be removed.
Differential Revision: https://phabricator.services.mozilla.com/D60919
--HG--
extra : moz-landing-system : lando
The exact circumstances of how this is showing up in the wild aren't
clear - there seem to be a couple of ways we can get here. However it
all revolves around early shutdowns (i.e., from the select profile popup)
- before the StartupCache is ever initialized. In any case, the solution
shouldn't change based on the exact circumstances - if we don't have a
StartupCache, there's no need to write one. Also, don't bother lazy
initializing it if it doesn't exist yet.
Differential Revision: https://phabricator.services.mozilla.com/D63208
--HG--
extra : moz-landing-system : lando
The patch removes the tad odd interleave behavior from the main thread and makes RefreshDriver to give
at least a tiny bit time for non-high priority tasks.
Given the recent change to have similar block-until behavior in child and parent process, this should work
consistently in all the processes.
Differential Revision: https://phabricator.services.mozilla.com/D63098
--HG--
extra : moz-landing-system : lando
This change is a little gross, because we don't totally control where
the statically initialized instances of `RWLock` live, due to its uses
in third-party libraries.
Differential Revision: https://phabricator.services.mozilla.com/D62936
--HG--
extra : moz-landing-system : lando
When we support `InputEvent.getTargetRanges()`, editor needs to create
`StaticRange` instances at starting to handle every edit operations/commands.
Therefore, we need a hack for saving allocation cost like `nsRange`.
This patch moves `nsRange::MaybeCacheToReuse()` and `nsRange::Shutdown()` to
`AbstractRange` to reduce copy&paste same code into `nsRange` and `StaticRange`.
However, `Create(nsINode*)` and `Release()` are duplicated unfortunately.
Differential Revision: https://phabricator.services.mozilla.com/D62692
--HG--
extra : moz-landing-system : lando
TSan reports a benign race when accessing a string between main thread and IPDL background thread. The reason is that we use `memory_order_relaxed` to check the reference count of StringBuffer. To avoid the benign race, this patch uses `memory_order_acquire` to perform acquire memory synchronization only for TSan build.
Differential Revision: https://phabricator.services.mozilla.com/D57620
--HG--
extra : moz-landing-system : lando
GENERATED_FILES now defaults to python3 unless py2=True is specified as
an argument. All existing GENERATED_FILES scripts and GeneratedFile
templates have the py2=True attribute added, so this patch should
effectively be a no-op.
Going forward, individual scripts can be converted to python3 and their
corresponding py2=True attribute can be deleted. In effect, this patch
will be backed out in pieces until all scripts run in python3, at which
point the py2 attribute itself can be removed.
Differential Revision: https://phabricator.services.mozilla.com/D60919
--HG--
extra : moz-landing-system : lando
GENERATED_FILES now defaults to python3 unless py2=True is specified as
an argument. All existing GENERATED_FILES scripts and GeneratedFile
templates have the py2=True attribute added, so this patch should
effectively be a no-op.
Going forward, individual scripts can be converted to python3 and their
corresponding py2=True attribute can be deleted. In effect, this patch
will be backed out in pieces until all scripts run in python3, at which
point the py2 attribute itself can be removed.
Differential Revision: https://phabricator.services.mozilla.com/D60919
--HG--
extra : moz-landing-system : lando
Since we've decoupled the writing of the StartupCache from the freeing
of the StartupCache's tables (which takes nontrivial time), this patch
moves the StartupCache's destructor later in shutdown so it will be
skipped in the early _exit(0) efforts. There is a remaining
WaitOnWriteThread in the StartupCache's destructor, but this is a
minor sanity check to avoid use-after-frees in the write thread during
shutdown. In general it won't matter as we already wait for the write
thread in the xpcom-shutdown observer, and if we shut down during write,
the system is set up to be okay with that (because it already happens).
Differential Revision: https://phabricator.services.mozilla.com/D62295
--HG--
extra : source : d79f1d283acde1a971fe0e5e6f1a8db075f8589a
extra : histedit_source : 32a2b4fec1fcf35960155b0f4280a38bcb54ec19
The initial thought for getting the StartupCache out of the shutdown
path was to simply not write it during shutdown, as it should write
60 seconds after startup, and the theory was that if the user shut
down within the first 60 seconds of use, they were likely updating or
something and it shouldn't matter. However, considering how many of
our users only ever open one tab, I think it's rather likely that
users are starting up firefox to go to a web site, then closing it
when done with that website, and then maybe opening up a new instance
in order to go to a different website. Accordingly it still makes
sense to continue writing it. However, we may as well leverage a
background thread for this and get it kicked off earlier during
shutdown, so we don't sit there blocking in the destructor late
during shutdown.
Differential Revision: https://phabricator.services.mozilla.com/D62294
--HG--
extra : source : 7b7b147b6955cee07e0c115993446bfbd59cf7e2
extra : histedit_source : 6990122d6b1ac4939b0e4b0a5e452183fb981e19
Olli Pettay
Simon Giesecke
Tooru Fujisawa
Cameron McCormack
Nicholas Nethercote
Narcis Beleuzu
Honza Bambas
Emma Malysz
Jon Coppeard
Matt Woodrow
Gerald Squelart
Eric Rahm
Marco Bonardo
Nika Layzell
Razvan Maries
Andreas Farre
Dave Townsend
Cosmin Sabou
Ciure Andrei
Mozilla Releng Treescript
Sylvestre Ledru
Andrew McCreight
Bas Schouten
Kearwood Gilbert
Erik Nordin
Tom Tung
Lina Cambridge
André Bargull
Marcos Cáceres
Chris Peterson
Stefan Hindli
Kirk Steuber
Byron Campen [:bwc]
Dzmitry Malyshau
Mihai Alexandru Michis
Bogdan Tara
Doug Thayer
Daniel Varga
Gabriele Svelto
Mike Hommey
Emilio Cobos Álvarez
Sean Feng
Markus Stange
Kartikaya Gupta
Toshihito Kikuchi
David Teller
Oana Pop Rus
ffxbld
Boris Zbarsky
Arthur Iakab
Marco Zehe
Mike Shal
David Major
Mike Conley
Kris Maglione
Bob Owen
Masatoshi Kimura
Ehsan Akhgari
Csoregi Natalia
Dorel Luca
Kershaw Chang
Christoph Walcher
Nathan Froyd
Masayuki Nakano
Brindusan Cristian
Tuan