If an XPIDL interface has a method or attribute that is [notxpcom],
then it is implicitly treated as [builtinclass], even if it is not
marked as such. For clarity, this patch goes through and marks every
place that relies on this behavior (aside from some test code).
Differential Revision: https://phabricator.services.mozilla.com/D30714
--HG--
extra : moz-landing-system : lando
We never emit an XPT for an interface that is not scriptable, so this
flag is never used.
Differential Revision: https://phabricator.services.mozilla.com/D30529
--HG--
extra : moz-landing-system : lando
With changes from bug 1548555, some of the gtests previously disabled on Android
can be re-enabled.
Differential Revision: https://phabricator.services.mozilla.com/D30080
--HG--
extra : moz-landing-system : lando
Consumers that just care about this boolean state should use this instead of
getting the JSObject* directly.
Differential Revision: https://phabricator.services.mozilla.com/D29705
--HG--
extra : moz-landing-system : lando
This patch makes editors return new error code internally when clipboard event
is dispatched and canceled by script. This is for making each caller stop
handling the edit action. However, it's not actual failure. Therefore, making
public methods return `NS_SUCCESS_DOM_NO_OPERATION` instead via
`EditorBase::ToGenericNSResult()`.
Differential Revision: https://phabricator.services.mozilla.com/D28935
--HG--
extra : moz-landing-system : lando
There's no good reason why we should let unnamed threads through this interface.
Differential Revision: https://phabricator.services.mozilla.com/D29672
--HG--
extra : moz-landing-system : lando
Temporarily just sidestep the issue in bug 1546498 (crash with latest SDK
on startup in Windows 7) by just continuing to use the old method in
Windows 7. We saw no wins in telemetry for Windows 7 anyway, so we should
investigate why that is, and why we see a mysterious crash in the fallback
code, in a followup bug.
Differential Revision: https://phabricator.services.mozilla.com/D29239
--HG--
extra : moz-landing-system : lando
Temporarily just sidestep the issue in bug 1546498 (crash with latest SDK
on startup in Windows 7) by just continuing to use the old method in
Windows 7. We saw no wins in telemetry for Windows 7 anyway, so we should
investigate why that is, and why we see a mysterious crash in the fallback
code, in a followup bug.
Differential Revision: https://phabricator.services.mozilla.com/D29239
--HG--
extra : moz-landing-system : lando
Changes:
- added comments for tests being disabled
- disabled two additional tests in order to green the run
Differential Revision: https://phabricator.services.mozilla.com/D28085
--HG--
extra : moz-landing-system : lando
nsITabParent is exposed to frontend code and is generally used as a representation of a remote tab. We could just rename the interface to nsIBrowserParent and worry about it later, but I think it's better to rename the interface to nsIRemoteTab so that we can later work on splitting the interface away from the PBrowser protocol.
Note: Some frontend code refers to a TabParentId. This commit renames this to RemoteTabId. We need to figure out the purpose of TabId with fission.
Differential Revision: https://phabricator.services.mozilla.com/D28132
--HG--
rename : dom/interfaces/base/nsITabParent.idl => dom/interfaces/base/nsIRemoteTab.idl
extra : rebase_source : 9d8a1790a7bb10195ad063644d1a93d63b2afb72
Also, this checks for strings with nulls, which is nice (though I guess an
uncommon mistake).
Differential Revision: https://phabricator.services.mozilla.com/D28312
--HG--
extra : moz-landing-system : lando
Don't assume XPCOM_MEM_BLOAT_LOG is a filename. XPCOM_MEM_BLOAT_LOG and XPCOM_MEM_LEAK_LOG can be set to a filename or "1" or "2" for logging to stdout and stderr respectively.
Set the debug write directory for XPCOM_MEM_LEAK_LOG in the same way we already to for XPCOM_MEM_BLOAT_LOG.
Differential Revision: https://phabricator.services.mozilla.com/D27968
--HG--
extra : moz-landing-system : lando
- `Array.map` becomes `Array.from`
- Array copying via `Array.slice` becomes `Array.from`.
- `Array.forEach` that did not rely on closures becomes `for`-`of` loops.
- Anything else: `Array.X` becomes `Array.prototype.X`.
Complex cases:
dom/bindings/test/TestInterfaceJS.js and
dom/bindings/test/test_exception_options_from_jsimplemented.html
use `Array.indexOf` to generate an error with a specific error message.
Switched to `Array.prototype.forEach` to generate the same error.
js/src/jit-test/tests/basic/exception-column-number.js
In this test `Array.indexOf()` is used to generate an error. Since the
exact message doesn't matter, I switched to `Array.from()`.
Intentionally not changed:
editor/libeditor/tests/browserscope/lib/richtext/richtext/js/range.js
Did not modify because this is 3rd-party code and the code uses
feature detection as a fall back when Array generics are not used.
testing/talos/talos/tests/dromaeo/lib/mootools.js
Did not modify because mootools adds the `Array.slice` method to the
`Array` object.
Not changed because they check the implementation of Array generics:
js/src/jit-test/tests/basic/arrayNatives.js
js/src/jit-test/tests/basic/bug563243.js
js/src/jit-test/tests/basic/bug618853.js
js/src/jit-test/tests/basic/bug830967.js
js/src/jit-test/tests/jaeger/recompile/bug656753.js
js/src/jit-test/tests/self-hosting/alternate-static-and-instance-array-extras.js
js/src/tests/non262/Array/generics.js
js/src/tests/non262/Array/regress-415540.js
js/src/tests/non262/extensions/regress-355497.js
js/src/tests/non262/extensions/typedarray-set-neutering.js
Depends on D27802
Differential Revision: https://phabricator.services.mozilla.com/D27803
--HG--
extra : moz-landing-system : lando
On startup we record the size and modified time of the profile lists. If
changed we refuse to flush any new changes to disk. Also adds a getter to check
if they've changed so the UI can do something sensible.
All attempts to flush are now checked for success. In some cases in early
startup the failure mode isn't great, we just quit startup. The assumption
though is that it's extremely unlikely that the files will have changed on disk
in the time between when they are read and when profile selection occurs, likely
less than a second later.
The profile reset flow is changed to only delete the old profile and flush once
all the migration has completed, so if something fails the user gets back to
their old profile.
In testing I ended up having to fix bug 1522584 so background file deletions on
a background thread are safer.
I haven't implemented any UI tests right now since making modifications to the
profiles means modifying the actual user's profiles which I'm not keen to do.
See bug 1539868.
Differential Revision: https://phabricator.services.mozilla.com/D25278
--HG--
extra : moz-landing-system : lando
On startup we record the size and modified time of the profile lists. If
changed we refuse to flush any new changes to disk. Also adds a getter to check
if they've changed so the UI can do something sensible.
All attempts to flush are now checked for success. In some cases in early
startup the failure mode isn't great, we just quit startup. The assumption
though is that it's extremely unlikely that the files will have changed on disk
in the time between when they are read and when profile selection occurs, likely
less than a second later.
The profile reset flow is changed to only delete the old profile and flush once
all the migration has completed, so if something fails the user gets back to
their old profile.
In testing I ended up having to fix bug 1522584 so background file deletions on
a background thread are safer.
I haven't implemented any UI tests right now since making modifications to the
profiles means modifying the actual user's profiles which I'm not keen to do.
See bug 1539868.
Differential Revision: https://phabricator.services.mozilla.com/D25278
--HG--
extra : moz-landing-system : lando
This patch introduces an asynchronous XPCOM interface for the bits client added in Bug 1523417
Differential Revision: https://phabricator.services.mozilla.com/D25161
--HG--
extra : moz-landing-system : lando
I missed this intermittent when enabling Android gtests in bug 1318091. Disable
the failing test on Android only, to green up Android gtest.
Differential Revision: https://phabricator.services.mozilla.com/D27535
--HG--
extra : moz-landing-system : lando
Our old approach was reading this into a region of unexecutable memory,
meaning when we actually loaded the library it needed to be loaded into
executable memory. This fixes that. I suspect that any gains we were
seeing previously were due to hardware effects.
Differential Revision: https://phabricator.services.mozilla.com/D26018
--HG--
extra : moz-landing-system : lando
There shouldn't be any need to do this for content processes as
the DLL should already be in the system file cache.
Differential Revision: https://phabricator.services.mozilla.com/D26017
--HG--
extra : moz-landing-system : lando
This is just to make it simpler to use PrefetchVirtualMemory in subsequent patches.
Differential Revision: https://phabricator.services.mozilla.com/D26016
--HG--
extra : moz-landing-system : lando
Our old approach was reading this into a region of unexecutable memory,
meaning when we actually loaded the library it needed to be loaded into
executable memory. This fixes that. I suspect that any gains we were
seeing previously were due to hardware effects.
Differential Revision: https://phabricator.services.mozilla.com/D26018
--HG--
extra : moz-landing-system : lando
There shouldn't be any need to do this for content processes as
the DLL should already be in the system file cache.
Differential Revision: https://phabricator.services.mozilla.com/D26017
--HG--
extra : moz-landing-system : lando
This is just to make it simpler to use PrefetchVirtualMemory in subsequent patches.
Differential Revision: https://phabricator.services.mozilla.com/D26016
--HG--
extra : moz-landing-system : lando
(more a feedback request than review request at this stage)
Adding a new attribute to the panel was the easiest way I could find to make this work without too much plumbing
However I don't know how to check that the attribute comes from a chrome privileged script. I tried using PresContext()->IsChrome() but this is also false in our situation.
Would you prefer another approach? Otherwise what kind of test would you write for this kind of feature?
Differential Revision: https://phabricator.services.mozilla.com/D26211
--HG--
extra : moz-landing-system : lando
Because not all static components are using the static registration yet,
we can end up in situations where a same component is registered
multiple times, which can have some unexpected consequences.
Interestingly enough, this change revealed that we did have static
registration in place for components that were kept under the old system
after bug 1478124 and bug 1524687.
There are also possibly some non-obvious things that can happen while
migrating the remaining components, like what happened to me while I
worked on @mozilla.org/widget/components;1 (see bug 1542214 comment 0).
Differential Revision: https://phabricator.services.mozilla.com/D26698
--HG--
extra : moz-landing-system : lando
Bug 1478124 and bug 1524687 converted many things to static xpcom
component registration, but somehow left the corresponding C++
initialization.
Differential Revision: https://phabricator.services.mozilla.com/D26697
--HG--
extra : moz-landing-system : lando
Originally, RDD reused the GPU process selector since they were
using all the same services, and it reduced the number of places
that had to be touched. Now that RDD needs pref handling, it
needs its own process selector to avoid GPU inheriting pref
handling.
Differential Revision: https://phabricator.services.mozilla.com/D26566
--HG--
extra : moz-landing-system : lando
Whenever chrome JS code leaks, we leak the dynamic atom "[System
Principal]". This causes an assertion, which hangs the browser in
stack walking code for multiple minutes on OSX. As a bandaid, make
this atom static so it won't leak.
My first instinct is that it would make sense to use this new atom
directly in SystemPrincipal, but atoms are represented internally as a
kind of nsAString, but principal code uses nsACStrings, so you end up
with an extra conversion from 16-bit to 8-bit.
This atom is also going to be present in any process running chrome
JS, so this will save a little bit of memory.
Differential Revision: https://phabricator.services.mozilla.com/D26590
--HG--
extra : moz-landing-system : lando
Before bug 938437, we had a rather large and error-prone
nsStaticXULComponents.cpp used to register all modules. That was
replaced with clever use of the linker, which allowed to avoid the mess
that maintaining that file was.
Fast forward to now, where after bug 1524687 and other work that
preceded it, we have a much smaller number of remaining static xpcom
components, registered via this linker hack, and don't expect to add
any new ones. The list should eventually go down to zero.
Within that context, it seems to be the right time to get rid of the
magic, and with it the problems it causes on its own.
Some of those components could probably be trivially be converted to
static registration via .conf files, but I didn't want to deal with the
possible need to increase the number of dummy modules in XPCOMInit.cpp.
They can still be converted as a followup.
Differential Revision: https://phabricator.services.mozilla.com/D26076
--HG--
extra : moz-landing-system : lando
The binary path type of a particular content process is useful information
outside of IPC. Given that `XRE_EnableSameExecutableForContentProc` already
exists, and given that the binary path type is closely related to
`GeckoProcessType`, I've added a new function, `XRE_GetContentProcBinPathType`.
The mapping of process type to binary type has been moved to the
`GeckoProcessTypes` definitions.
This patch also modifies `ipc::GeckoChildProcessHost` to call into the new
function.
Differential Revision: https://phabricator.services.mozilla.com/D25816
--HG--
extra : histedit_source : acdfd2357fd06551dff5286c6b7c56bd92dd347b
Disable gtests observed to fail on Android. Some of these are simple build
failures and failures due to file permissions or paths, while other failures
are more obscure.
Once Android gtests are running on mozilla-central, I will file follow-up
bugs inviting teams to investigate the failures and re-enable Android gtests
that are important to them.
Differential Revision: https://phabricator.services.mozilla.com/D26606
--HG--
extra : moz-landing-system : lando
The binary path type of a particular content process is useful information
outside of IPC. Given that `XRE_EnableSameExecutableForContentProc` already
exists, and given that the binary path type is closely related to
`GeckoProcessType`, I've added a new function, `XRE_GetContentProcBinPathType`.
The mapping of process type to binary type has been moved to the
`GeckoProcessTypes` definitions.
This patch also modifies `ipc::GeckoChildProcessHost` to call into the new
function.
Differential Revision: https://phabricator.services.mozilla.com/D25816
--HG--
extra : moz-landing-system : lando
This is based on the `c_str` macro in `js/rust/src/heap.rs`, but
returns a `NulTerminatedCStr` type that can be cast to a pointer.
This commit also changes `ThreadPtrHolder::new` to take a
`NulTerminatedCStr`, and removes an unnecessary `RefPtr` reference in
`is_current_thread`.
Differential Revision: https://phabricator.services.mozilla.com/D26429
--HG--
extra : moz-landing-system : lando
If the environment variable MOZ_GC_LOG_SIZE is set, then GC logs will
include some extra data that indicates how much memory the GC thing
uses, including extra data hanging off of it. This can be used
calculate finer grained information about the memory usage of scripts.
Differential Revision: https://phabricator.services.mozilla.com/D25882
--HG--
extra : moz-landing-system : lando
XPCConvert::IsMethodReflectable() is derived entirely from
nsXPTMethodInfo, so we can compute it at build time and include it in
nsXPTMethodInfo. It is the only use of mNotXPCOM and mHidden, so we
can get rid of those fields at the same time.
This paves the way for getting rid of XPCWrappedJSClass::mDescriptors
in the next patch.
Differential Revision: https://phabricator.services.mozilla.com/D26070
--HG--
extra : moz-landing-system : lando
Otherwise, LTO will eliminate it because the compiler can't see the
calls to PrepareAndDispatch from the relevant assembly file.
Differential Revision: https://phabricator.services.mozilla.com/D26244
--HG--
extra : moz-landing-system : lando
ARM's xptcstubs use a slightly different setup for PrepareAndDispatch
than...well, all of our other stubs. This difference appears to be
causing problems with LTO builds. Change the setup to be more like our
other stubs, which additionally gets rid of some of the `asm` nonsense.
Differential Revision: https://phabricator.services.mozilla.com/D26243
--HG--
extra : moz-landing-system : lando
XPCConvert::IsMethodReflectable() is derived entirely from
nsXPTMethodInfo, so we can compute it at build time and include it in
nsXPTMethodInfo. It is the only use of mNotXPCOM and mHidden, so we
can get rid of those fields at the same time.
This paves the way for getting rid of XPCWrappedJSClass::mDescriptors
in the next patch.
Differential Revision: https://phabricator.services.mozilla.com/D26070
--HG--
extra : moz-landing-system : lando
PR_SetCurrentThreadName() is broken on Android (Bug 1541216).
In order to work around this issue, NS_SetCurrentThreadName() will
call prctl(PR_SET_NAME, name) until the underlying nspr can be
fixed.
Differential Revision: https://phabricator.services.mozilla.com/D25891
--HG--
extra : moz-landing-system : lando
I am 90% sure that this is wrong but this is the only way I can get it to
compile and work. Unlike other examples of supporting MOZ_DBG it only declares
an operator for `nsIURI* not` `const nsIURI`. I had to drop the const because
then I couldn't call GetSpec as it isn't marked const. I had to switch to a
pointer since otherwise it would complain about virtual methods.
Still in practice this works, I think it is rare that we hold an nsIURI in
anything other than a pointer and same for the constness.
Differential Revision: https://phabricator.services.mozilla.com/D25669
--HG--
extra : rebase_source : 9760674375563ec312568caf4a5ad46facfb6f68
In addition to knowing whether we're running x86-on-x86-64, we'd also
like to know about the x86-on-arm64 case. The current code doesn't
provide enough information to determine that, so we need to query a
little bit harder.
The img decode API allows a web author to request that an image be
decoded at its intrinsic size and be notified when it has been
completed. This is useful to ensure an image is ready to display before
adding it to the DOM tree -- this will help reduce flickering.
Differential Revision: https://phabricator.services.mozilla.com/D11362
1. Adding a new attribute chromeContext in ConsoleEvent
2. Adding a new boolean attribute isFromChromeContext in nsIConsoleMessage
3. Sending IsFromChromeContext to the parent process
Differential Revision: https://phabricator.services.mozilla.com/D23330
--HG--
extra : moz-landing-system : lando
Testing has determined that doing this has no detrimental size benefit,
and a small positive performance impact.
Differential Revision: https://phabricator.services.mozilla.com/D25848
--HG--
extra : moz-landing-system : lando
Mechanical change from Matcher::match(...) to Matcher::operator()(...).
This will now permit the use of generic lambdas, and facilitate the
implementation of multi-lambda match.
Differential Revision: https://phabricator.services.mozilla.com/D24889
--HG--
extra : moz-landing-system : lando
This way we don't have to go through a bunch of printf nonsense, and we
ought to be able to arrive at optimized routines that take advantage of
constant radices, etc.
Differential Revision: https://phabricator.services.mozilla.com/D25141
--HG--
extra : moz-landing-system : lando
Outside code shouldn't have to care how many levels of priority
PrioritizedEventQueue manages.
Differential Revision: https://phabricator.services.mozilla.com/D25226
--HG--
extra : moz-landing-system : lando
Originally we stored the new information about installation defaults in
installs.ini since older versions of Firefox would throw away any new data in
profiles.ini any time they made changes to the profiles. That does however mean
we have to load two files on startup.
This changes things so that we save all the data in profiles.ini as well as a
version tag and still save the install data into installs.ini. An older version
will throw away the install data and version tag from profiles.ini but leave
installs.ini alone. On startup if the version tag is gone from profiles.ini then
we reload the install data from installs.ini and put it back into profiles.ini.
At some point in the future where we don't care about supporting older versions
of Firefox we can just drop installs.ini entirely.
A lot of the changes here involve moving to loading profiles.ini into an
in-memory ini, keeping it up to date and flushing it to disk. This means that we
no longer throw away any information in the ini file that this version does not
understand allowing the possibility of adding new data to this file in the
future.
Differential Revision: https://phabricator.services.mozilla.com/D22576
--HG--
extra : rebase_source : d00edf1ceb200a73a60bb1a90afabcdf95b01acf
extra : intermediate-source : e1c9790cd3bee060da99ffe37026721e36bc46c3
extra : source : d4feb17faf013134f5eac8b5e19b714c56410973
Cache the result of nsMacUtilsImpl::GetAppPath() to avoid doing I/O on repeated calls.
Differential Revision: https://phabricator.services.mozilla.com/D22410
--HG--
extra : moz-landing-system : lando
Originally we stored the new information about installation defaults in
installs.ini since older versions of Firefox would throw away any new data in
profiles.ini any time they made changes to the profiles. That does however mean
we have to load two files on startup.
This changes things so that we save all the data in profiles.ini as well as a
version tag and still save the install data into installs.ini. An older version
will throw away the install data and version tag from profiles.ini but leave
installs.ini alone. On startup if the version tag is gone from profiles.ini then
we reload the install data from installs.ini and put it back into profiles.ini.
At some point in the future where we don't care about supporting older versions
of Firefox we can just drop installs.ini entirely.
A lot of the changes here involve moving to loading profiles.ini into an
in-memory ini, keeping it up to date and flushing it to disk. This means that we
no longer throw away any information in the ini file that this version does not
understand allowing the possibility of adding new data to this file in the
future.
Differential Revision: https://phabricator.services.mozilla.com/D22576
--HG--
extra : moz-landing-system : lando
Originally we stored the new information about installation defaults in
installs.ini since older versions of Firefox would throw away any new data in
profiles.ini any time they made changes to the profiles. That does however mean
we have to load two files on startup.
This changes things so that we save all the data in profiles.ini as well as a
version tag and still save the install data into installs.ini. An older version
will throw away the install data and version tag from profiles.ini but leave
installs.ini alone. On startup if the version tag is gone from profiles.ini then
we reload the install data from installs.ini and put it back into profiles.ini.
At some point in the future where we don't care about supporting older versions
of Firefox we can just drop installs.ini entirely.
A lot of the changes here involve moving to loading profiles.ini into an
in-memory ini, keeping it up to date and flushing it to disk. This means that we
no longer throw away any information in the ini file that this version does not
understand allowing the possibility of adding new data to this file in the
future.
Differential Revision: https://phabricator.services.mozilla.com/D22576
--HG--
extra : moz-landing-system : lando
1. Adding a new attribute chromeContext in ConsoleEvent
2. Adding a new boolean attribute isFromChromeContext in nsIConsoleMessage
3. Sending IsFromChromeContext to the parent process
Differential Revision: https://phabricator.services.mozilla.com/D23330
--HG--
extra : moz-landing-system : lando
Originally we stored the new information about installation defaults in
installs.ini since older versions of Firefox would throw away any new data in
profiles.ini any time they made changes to the profiles. That does however mean
we have to load two files on startup.
This changes things so that we save all the data in profiles.ini as well as a
version tag and still save the install data into installs.ini. An older version
will throw away the install data and version tag from profiles.ini but leave
installs.ini alone. On startup if the version tag is gone from profiles.ini then
we reload the install data from installs.ini and put it back into profiles.ini.
At some point in the future where we don't care about supporting older versions
of Firefox we can just drop installs.ini entirely.
A lot of the changes here involve moving to loading profiles.ini into an
in-memory ini, keeping it up to date and flushing it to disk. This means that we
no longer throw away any information in the ini file that this version does not
understand allowing the possibility of adding new data to this file in the
future.
Differential Revision: https://phabricator.services.mozilla.com/D22576
--HG--
extra : moz-landing-system : lando
This is done by incorporating the ensure_param macro into the implementation of the xpcom_method macro
Differential Revision: https://phabricator.services.mozilla.com/D23568
--HG--
extra : moz-landing-system : lando
This commit adds `ThreadPtr{Handle, Holder}` to wrap an `XpCom` object
with thread-safe refcounting. These are analagous to
`nsMainThreadPtr{Handle, Holder}`, but can hold references to
objects from any thread, not just the main thread.
`ThreadPtrHolder` is similar to `ThreadBoundRefPtr`. However, it's
not possible to clone a `ThreadBoundRefPtr`, so it can't be shared
among tasks. This is fine for objects that are only used once, like
callbacks. However, `ThreadBoundRefPtr` doesn't work well for loggers
or event emitters, which might need to be called multiple times on
the owning thread.
Unlike a `ThreadBoundRefPtr`, it's allowed and expected to
clone and drop a `ThreadPtrHolder` on other threads. Internally,
the holder keeps an atomic refcount, and releases the wrapped object
on the owning thread once the count reaches zero.
This commit also changes `TaskRunnable` to support dispatching from
threads other than the main thread.
Differential Revision: https://phabricator.services.mozilla.com/D20074
--HG--
extra : moz-landing-system : lando
This commit wraps just enough of the mozStorage API to support the
bookmarks mirror. It's not complete: for example, there's no way
to open, clone, or close a connection, because the mirror handles
that from JS. The wrapper also omits shutdown blocking and retrying on
`SQLITE_BUSY`.
This commit also changes the behavior of sync and async mozStorage
connections. Async (`mozIStorageAsyncConnection`) methods may be called
from any thread on any connection. Sync (`mozIStorageConnection`)
methods may be called from any thread on a sync connection, and from
background threads on an async connection. All connections now QI
to `mozIStorageConnection`, but attempting to call a sync method on
an async connection from the main thread throws.
Finally, this commit exposes an `OpenedConnection::unsafeRawConnection`
getter in Sqlite.jsm, for JS code to access the underlying connection.
Differential Revision: https://phabricator.services.mozilla.com/D20073
--HG--
extra : moz-landing-system : lando
Before the Array<T> type, the calltype argument could be in, out, or inout,
however with Array<T> the element type was added.
When I added Array<T>, I changed the checks in files which check calltype !=
'in' to instead check 'out' in calltype, such that element would act more like
in in most cases (not adding the outparam *).
However, I never made that change for rust code, as it didn't support Array<T>
at the time. When I turned on Array<T> support for rust code, I forgot to go
through and change the conditions, which lead to this bug.
Differential Revision: https://phabricator.services.mozilla.com/D24283
--HG--
extra : moz-landing-system : lando
This is a large patch that contains all of the core changes for
renderroot splitting.
Differential Revision: https://phabricator.services.mozilla.com/D20701
--HG--
extra : moz-landing-system : lando
This is a large patch that contains all of the core changes for
renderroot splitting.
Differential Revision: https://phabricator.services.mozilla.com/D20701
--HG--
extra : moz-landing-system : lando
The definitions can't be entirely removed yet because NSS still needs them.
Differential Revision: https://phabricator.services.mozilla.com/D23454
--HG--
extra : moz-landing-system : lando
The old code for member method calls did the following:
1) Find the member method calls.
2) Look at their "this" expression.
3) If the "this" is an operator call, check for any of the arguments of the
operator call being invalid.
4) Otherwise (if not an operator call) check for the "this" value being
invalid.
This wasn't right, because the "is invalid" check checks the type and only
considers refcounted things. So if the code looked something like
"foo[i]->call_method()", we would look at the types of "foo" and "i" and
determine that none of those are refcounted types so there is nothing invalid
here (since "foo" is some sort of array type and "i" is an integer). The new
setup just checks whether the "this" value is invalid, which does the type
check on the "this" value itself; in the "foo[i]->call_method()" case on
"foo[i]". We then adjust the exclusions in InvalidArg to consider operator->
on known-live things valid, to allow the thing that we were really trying to
accomplish with the "check for an operator call" bits:
"stackRefPtr->some_method()".
The test coverage being added for the made-up TArray type is meant to catch
things like the geolocation issue that was being hidden by the buggy behavior.
I'm not using nsTArray itself because some header included by nsTArray.h
tries to define operator new/delete bits inline and that triggers warnings that
then cause a clang-plugin test failure, because they're unexpected.
Differential Revision: https://phabricator.services.mozilla.com/D24117
--HG--
extra : moz-landing-system : lando
"this" is guaranteed to stay alive as long as other MOZ_CAN_RUN_SCRIPT
conditions hold, and its const members can't change value and drop
their refs.
Differential Revision: https://phabricator.services.mozilla.com/D23997
--HG--
extra : moz-landing-system : lando
The old code for member method calls did the following:
1) Find the member method calls.
2) Look at their "this" expression.
3) If the "this" is an operator call, check for any of the arguments of the
operator call being invalid.
4) Otherwise (if not an operator call) check for the "this" value being
invalid.
This wasn't right, because the "is invalid" check checks the type and only
considers refcounted things. So if the code looked something like
"foo[i]->call_method()", we would look at the types of "foo" and "i" and
determine that none of those are refcounted types so there is nothing invalid
here (since "foo" is some sort of array type and "i" is an integer). The new
setup just checks whether the "this" value is invalid, which does the type
check on the "this" value itself; in the "foo[i]->call_method()" case on
"foo[i]". We then adjust the exclusions in InvalidArg to consider operator->
on known-live things valid, to allow the thing that we were really trying to
accomplish with the "check for an operator call" bits:
"stackRefPtr->some_method()".
The test coverage being added for the made-up TArray type is meant to catch
things like the geolocation issue that was being hidden by the buggy behavior.
I'm not using nsTArray itself because some header included by nsTArray.h
tries to define operator new/delete bits inline and that triggers warnings that
then cause a clang-plugin test failure, because they're unexpected.
Differential Revision: https://phabricator.services.mozilla.com/D24117
--HG--
extra : moz-landing-system : lando
"this" is guaranteed to stay alive as long as other MOZ_CAN_RUN_SCRIPT
conditions hold, and its const members can't change value and drop
their refs.
Differential Revision: https://phabricator.services.mozilla.com/D23997
--HG--
extra : moz-landing-system : lando
On startup we record the size and modified time of the profile lists. If
changed we refuse to flush any new changes to disk. Also adds a getter to check
if they've changed so the UI can do something sensible.
All attempts to flush are now checked for success. In some cases in early
startup the failure mode isn't great, we just quit startup. The assumption
though is that it's extremely unlikely that the files will have changed on disk
in the time between when they are read and when profile selection occurs, likely
less than a second later.
The profile reset flow is changed to only delete the old profile and flush once
all the migration has completed, so if something fails the user gets back to
their old profile.
In testing I ended up having to fix bug 1522584 so background file deletions on
a background thread are safer.
I haven't implemented any UI tests right now since making modifications to the
profiles means modifying the actual user's profiles which I'm not keen to do.
See bug 1539868.
Differential Revision: https://phabricator.services.mozilla.com/D25278
--HG--
extra : rebase_source : b9fb01c5f2faaf7d534800b700bb02b8c88af023
extra : source : ad5ac4d5c8f7240809a205be2960924813f1e705
We should catch these issues ASAP. This NS_ASSERTION also bit me in the past.
Differential Revision: https://phabricator.services.mozilla.com/D24115
--HG--
extra : moz-landing-system : lando
After analyzing crash ping data we've established that the current low-memory
detection threshold is too low, there are still a fair number of crashes
happening above it. A 50% increase to 384 MiB should be just about right in
the light of recent telemetry data.
Differential Revision: https://phabricator.services.mozilla.com/D23826
--HG--
extra : moz-landing-system : lando
NS_InitXPCOM() is currently not called in Gecko. It has been a one-line wrapper around NS_InitXPCOM2() since the year 2000 (bug 46320), presumably to maintain ABI compatibility for third-party users of XPCOM. We no longer need to worry about XPCOM ABI compatibility.
https://searchfox.org/mozilla-central/commit/cddb62593d786e0ff12b25037c74b01cb1a802e5
clang's -Wmissing-prototypes option identifies global functions that can be made static (because they're only called from one compilation unit) or removed (if they're never called).
xpcom/build/XPCOMInit.cpp:187:1 [-Wmissing-prototypes] no previous prototype for function 'NS_InitXPCOM'
Differential Revision: https://phabricator.services.mozilla.com/D23266
--HG--
extra : rebase_source : 0ad5580e2978a8d5141bd6a9623c5af7359c78ca
extra : source : a9e4205868dbb847c01980051a56e99ad24a8ac1
The NonASCII16 test function was removed in bug 1402247 but the NonASCII16_helper() function was not:
https://hg.mozilla.org/mozilla-central/rev/4ef0f163fdeb
xpcom/tests/gtest/TestUTF.cpp:119:6 [-Wmissing-prototypes] no previous prototype for function 'NonASCII16_helper'
Differential Revision: https://phabricator.services.mozilla.com/D23267
--HG--
extra : rebase_source : c53118479acc6ea866dafb04617bfb2706dddb2b
extra : source : de3a70ccef6c09d0d317c7b4b5c1f8a2f93d78c7
clang's -Wmissing-prototypes option identifies global functions that can be made static (because they're only called from one compilation unit) or removed (if they're never called). The .cpp files defining these functions did not include the headers with the corresponding function prototypes used by other compilation units. Including a header file in its corresponding .cpp file can help catch mismatched declarations and definitions.
xpcom/components/nsCategoryManager.cpp:637:6 [-Wmissing-prototypes] no previous prototype for function 'NS_CreateServicesFromCategory'
xpcom/io/nsPipe3.cpp:1824:10 [-Wmissing-prototypes] no previous prototype for function 'nsPipeConstructor'
xpcom/io/nsStringStream.cpp:475:10 [-Wmissing-prototypes] no previous prototype for function 'nsStringInputStreamConstructor'
xpcom/threads/ThreadDelay.cpp:18:6 [-Wmissing-prototypes] no previous prototype for function 'DelayForChaosMode'
Differential Revision: https://phabricator.services.mozilla.com/D23265
--HG--
extra : rebase_source : a2085a090394a5d3f5c319258b782a5d9f217751
extra : source : 18c3e569ff15987eb200c62eaa9f4943ff08cb25
clang's -Wmissing-prototypes option identifies global functions that can be made static (because they're only called from one compilation unit) or removed (if they're never called).
xpcom/base/Logging.cpp:85:13 [-Wmissing-prototypes] no previous prototype for function 'ToLogStr'
xpcom/base/Logging.cpp:132:13 [-Wmissing-prototypes] no previous prototype for function 'ExpandPIDMarker'
xpcom/base/LogModulePrefWatcher.cpp:37:6 [-Wmissing-prototypes] no previous prototype for function 'ResetExistingPrefs'
xpcom/base/LogModulePrefWatcher.cpp:109:6 [-Wmissing-prototypes] no previous prototype for function 'LoadExistingPrefs'
xpcom/base/nsCycleCollector.cpp:212:6 [-Wmissing-prototypes] no previous prototype for function 'SuspectUsingNurseryPurpleBuffer'
xpcom/components/nsComponentManager.cpp:421:31 [-Wmissing-prototypes] no previous prototype for function 'begin'
xpcom/components/nsComponentManager.cpp:427:31 [-Wmissing-prototypes] no previous prototype for function 'end'
xpcom/ds/Dafsa.cpp:23:6 [-Wmissing-prototypes] no previous prototype for function 'GetNextOffset'
xpcom/ds/Dafsa.cpp:55:6 [-Wmissing-prototypes] no previous prototype for function 'IsEOL'
xpcom/ds/Dafsa.cpp:62:6 [-Wmissing-prototypes] no previous prototype for function 'IsMatch'
xpcom/ds/Dafsa.cpp:70:6 [-Wmissing-prototypes] no previous prototype for function 'IsEndCharMatch'
xpcom/ds/Dafsa.cpp:78:6 [-Wmissing-prototypes] no previous prototype for function 'GetReturnValue'
xpcom/ds/Dafsa.cpp:91:5 [-Wmissing-prototypes] no previous prototype for function 'LookupString'
xpcom/io/CocoaFileUtils.mm:195:13 [-Wmissing-prototypes] no previous prototype for function 'GetQuarantinePropKey'
xpcom/io/CocoaFileUtils.mm:203:24 [-Wmissing-prototypes] no previous prototype for function 'CreateQuarantineDictionary'
xpcom/rust/gtest/bench-collections/Bench.cpp:65:11 [-Wmissing-prototypes] no previous prototype for function 'MyRand'
xpcom/rust/gtest/bench-collections/Bench.cpp:85:6 [-Wmissing-prototypes] no previous prototype for function 'Bench_Cpp_unordered_set'
xpcom/rust/gtest/bench-collections/Bench.cpp:125:6 [-Wmissing-prototypes] no previous prototype for function 'Bench_Cpp_PLDHashTable'
xpcom/rust/gtest/bench-collections/Bench.cpp:166:6 [-Wmissing-prototypes] no previous prototype for function 'Bench_Cpp_MozHashSet'
xpcom/tests/gtest/TestAtoms.cpp:114:6 [-Wmissing-prototypes] no previous prototype for function 'isStaticAtom'
xpcom/tests/gtest/TestCallTemplates.cpp:72:6 [-Wmissing-prototypes] no previous prototype for function 'JustTestingCompilation'
xpcom/tests/gtest/TestCOMPtr.cpp:87:10 [-Wmissing-prototypes] no previous prototype for function 'CreateIFoo'
xpcom/tests/gtest/TestCOMPtr.cpp:98:6 [-Wmissing-prototypes] no previous prototype for function 'set_a_IFoo'
xpcom/tests/gtest/TestCOMPtr.cpp:105:16 [-Wmissing-prototypes] no previous prototype for function 'return_a_IFoo'
xpcom/tests/gtest/TestCOMPtr.cpp:164:10 [-Wmissing-prototypes] no previous prototype for function 'CreateIBar'
xpcom/tests/gtest/TestCOMPtr.cpp:175:6 [-Wmissing-prototypes] no previous prototype for function 'AnIFooPtrPtrContext'
xpcom/tests/gtest/TestCOMPtr.cpp:177:6 [-Wmissing-prototypes] no previous prototype for function 'AVoidPtrPtrContext'
xpcom/tests/gtest/TestCOMPtr.cpp:179:6 [-Wmissing-prototypes] no previous prototype for function 'AnISupportsPtrPtrContext'
xpcom/tests/gtest/TestCOMPtr.cpp:263:6 [-Wmissing-prototypes] no previous prototype for function 'Comparison'
xpcom/tests/gtest/TestCOMPtr.cpp:298:6 [-Wmissing-prototypes] no previous prototype for function 'DontAddRef'
xpcom/tests/gtest/TestCRT.cpp:17:5 [-Wmissing-prototypes] no previous prototype for function 'sign'
xpcom/tests/gtest/TestDeadlockDetector.cpp:62:6 [-Wmissing-prototypes] no previous prototype for function 'DisableCrashReporter'
xpcom/tests/gtest/TestDeadlockDetector.cpp:74:5 [-Wmissing-prototypes] no previous prototype for function 'Sanity_Child'
xpcom/tests/gtest/TestDeadlockDetector.cpp:95:5 [-Wmissing-prototypes] no previous prototype for function 'Sanity2_Child'
xpcom/tests/gtest/TestDeadlockDetector.cpp:159:5 [-Wmissing-prototypes] no previous prototype for function 'Sanity4_Child'
xpcom/tests/gtest/TestDeadlockDetector.cpp:182:5 [-Wmissing-prototypes] no previous prototype for function 'Sanity5_Child'
xpcom/tests/gtest/TestDeadlockDetector.cpp:303:5 [-Wmissing-prototypes] no previous prototype for function 'ContentionNoDeadlock_Child'
xpcom/tests/gtest/TestHashtables.cpp:88:6 [-Wmissing-prototypes] no previous prototype for function 'testTHashtable'
xpcom/tests/gtest/TestHashtables.cpp:205:10 [-Wmissing-prototypes] no previous prototype for function 'CreateIFoo'
xpcom/tests/gtest/TestMoveString.cpp:25:6 [-Wmissing-prototypes] no previous prototype for function 'SetAsOwned'
xpcom/tests/gtest/TestMoveString.cpp:34:6 [-Wmissing-prototypes] no previous prototype for function 'ExpectTruncated'
xpcom/tests/gtest/TestMoveString.cpp:40:6 [-Wmissing-prototypes] no previous prototype for function 'ExpectNew'
xpcom/tests/gtest/TestMruCache.cpp:52:11 [-Wmissing-prototypes] no previous prototype for function 'MakeStringKey'
xpcom/tests/gtest/TestMultiplexInputStream.cpp:106:34 [-Wmissing-prototypes] no previous prototype for function 'CreateStreamHelper'
xpcom/tests/gtest/TestNonBlockingAsyncInputStream.cpp:62:10 [-Wmissing-prototypes] no previous prototype for function 'ReadSegmentsFunction'
xpcom/tests/gtest/TestNsDeque.cpp:240:6 [-Wmissing-prototypes] no previous prototype for function 'CheckIfQueueEmpty'
xpcom/tests/gtest/TestNsRefPtr.cpp:105:10 [-Wmissing-prototypes] no previous prototype for function 'CreateFoo'
xpcom/tests/gtest/TestNsRefPtr.cpp:116:6 [-Wmissing-prototypes] no previous prototype for function 'set_a_Foo'
xpcom/tests/gtest/TestNsRefPtr.cpp:123:13 [-Wmissing-prototypes] no previous prototype for function 'return_a_Foo'
xpcom/tests/gtest/TestNsRefPtr.cpp:391:6 [-Wmissing-prototypes] no previous prototype for function 'AnFooPtrPtrContext'
xpcom/tests/gtest/TestNsRefPtr.cpp:392:6 [-Wmissing-prototypes] no previous prototype for function 'AVoidPtrPtrContext'
xpcom/tests/gtest/TestPLDHash.cpp:33:6 [-Wmissing-prototypes] no previous prototype for function 'TestCrashyOperation'
xpcom/tests/gtest/TestPipes.cpp:98:10 [-Wmissing-prototypes] no previous prototype for function 'TestPipe'
xpcom/tests/gtest/TestPipes.cpp:212:10 [-Wmissing-prototypes] no previous prototype for function 'TestShortWrites'
xpcom/tests/gtest/TestPipes.cpp:354:6 [-Wmissing-prototypes] no previous prototype for function 'RunTests'
xpcom/tests/gtest/TestPLDHash.cpp:90:6 [-Wmissing-prototypes] no previous prototype for function 'InitCapacityOk_InitialLengthTooBig'
xpcom/tests/gtest/TestPLDHash.cpp:95:6 [-Wmissing-prototypes] no previous prototype for function 'InitCapacityOk_InitialEntryStoreTooBig'
xpcom/tests/gtest/TestPLDHash.cpp:102:6 [-Wmissing-prototypes] no previous prototype for function 'InitCapacityOk_EntrySizeTooBig'
xpcom/tests/gtest/TestSlicedInputStream.cpp:111:20 [-Wmissing-prototypes] no previous prototype for function 'CreateSeekableStreams'
xpcom/tests/gtest/TestSlicedInputStream.cpp:125:20 [-Wmissing-prototypes] no previous prototype for function 'CreateNonSeekableStreams'
xpcom/tests/gtest/TestStrings.cpp:471:6 [-Wmissing-prototypes] no previous prototype for function 'test_assign_helper'
xpcom/tests/gtest/TestTArray.cpp:60:22 [-Wmissing-prototypes] no previous prototype for function 'DummyArray'
xpcom/tests/gtest/TestTArray.cpp:72:22 [-Wmissing-prototypes] no previous prototype for function 'FakeHugeArray'
xpcom/tests/gtest/TestThrottledEventQueue.cpp:96:6 [-Wmissing-prototypes] no previous prototype for function 'Enqueue'
xpcom/threads/BlockingResourceBase.cpp:86:6 [-Wmissing-prototypes] no previous prototype for function 'PrintCycle'
xpcom/threads/CPUUsageWatcher.cpp:41:10 [-Wmissing-prototypes] no previous prototype for function 'GetMicroseconds'
xpcom/threads/CPUUsageWatcher.cpp:46:10 [-Wmissing-prototypes] no previous prototype for function 'GetMicroseconds'
xpcom/threads/CPUUsageWatcher.cpp:51:40 [-Wmissing-prototypes] no previous prototype for function 'GetProcessCPUStats'
xpcom/threads/CPUUsageWatcher.cpp:80:40 [-Wmissing-prototypes] no previous prototype for function 'GetGlobalCPUStats'
xpcom/threads/nsTimerImpl.cpp:196:21 [-Wmissing-prototypes] no previous prototype for function 'GetTimerFiringsLog'
Differential Revision: https://phabricator.services.mozilla.com/D23264
--HG--
extra : rebase_source : e03df033209e0a08fc263603e78bc16a09467f15
extra : source : 3beec9fbfdedf346fff85309029e7805717958ac
Originally we stored the new information about installation defaults in
installs.ini since older versions of Firefox would throw away any new data in
profiles.ini any time they made changes to the profiles. That does however mean
we have to load two files on startup.
This changes things so that we save all the data in profiles.ini as well as a
version tag and still save the install data into installs.ini. An older version
will throw away the install data and version tag from profiles.ini but leave
installs.ini alone. On startup if the version tag is gone from profiles.ini then
we reload the install data from installs.ini and put it back into profiles.ini.
At some point in the future where we don't care about supporting older versions
of Firefox we can just drop installs.ini entirely.
A lot of the changes here involve moving to loading profiles.ini into an
in-memory ini, keeping it up to date and flushing it to disk. This means that we
no longer throw away any information in the ini file that this version does not
understand allowing the possibility of adding new data to this file in the
future.
Differential Revision: https://phabricator.services.mozilla.com/D22576
--HG--
extra : rebase_source : 9264bfebc7b0781ee903ef2772686d4cf920d1c9
extra : source : d4feb17faf013134f5eac8b5e19b714c56410973
Originally we stored the new information about installation defaults in
installs.ini since older versions of Firefox would throw away any new data in
profiles.ini any time they made changes to the profiles. That does however mean
we have to load two files on startup.
This changes things so that we save all the data in profiles.ini as well as a
version tag and still save the install data into installs.ini. An older version
will throw away the install data and version tag from profiles.ini but leave
installs.ini alone. On startup if the version tag is gone from profiles.ini then
we reload the install data from installs.ini and put it back into profiles.ini.
At some point in the future where we don't care about supporting older versions
of Firefox we can just drop installs.ini entirely.
A lot of the changes here involve moving to loading profiles.ini into an
in-memory ini, keeping it up to date and flushing it to disk. This means that we
no longer throw away any information in the ini file that this version does not
understand allowing the possibility of adding new data to this file in the
future.
Differential Revision: https://phabricator.services.mozilla.com/D22576
--HG--
extra : rebase_source : d097342b0c26fb92e5236e83035b87bb7da84321
This change sets up nsLocalFileWin to mirror the behavior of
nsLocalFileUnix, which is all-around more reasonable than the behavior
nsLocalFileWin had before. We also, in passing, fix up some unnecessary
error-handling code at the end of Create().
Depends on D22360
Differential Revision: https://phabricator.services.mozilla.com/D22361
--HG--
extra : moz-landing-system : lando
We eventually want to make the common path just attempt file creation,
and only fall back to creating all the ancestor directories if the
initial attempt failed. To do that in a reasonable way, we'll need
re-usable code for the creation code, which is what this patch creates.
Depends on D22359
Differential Revision: https://phabricator.services.mozilla.com/D22360
--HG--
extra : moz-landing-system : lando
Add a check that this array isn't using the static empty header before updating the size field.
Differential Revision: https://phabricator.services.mozilla.com/D22616
--HG--
extra : moz-landing-system : lando
This will allow devtools to clear cached error messages, like
we already can with ConsoleAPI messages.
Differential Revision: https://phabricator.services.mozilla.com/D21693
--HG--
extra : moz-landing-system : lando
If we are running a background thread in the launcher process to log failures,
then allowing the main thread to proceed with monkeypatching system calls is a
Bad Idea. This patch gives us an environment variable that, when set, indicates
that it is unsafe for PoisonIOInterposer to run.
This scenario is an uncommon one, but one that we must account for nonetheless.
Differential Revision: https://phabricator.services.mozilla.com/D21607
--HG--
extra : moz-landing-system : lando
Counting CPUs accesses the filesystem (sysfs or procfs), which we'd like
to disallow when sandboxed if possible, and fails silently if access
is denied. Because the CPU count rarely changes, this patch handles
that problem for the RDD process by caching a copy before starting
sandboxing.
Tested with a local patch to have the sandbox file broker client crash
if accessing the sysfs node for the CPU count, to verify that it's not
accessed.
Depends on D14524
Differential Revision: https://phabricator.services.mozilla.com/D20895
--HG--
extra : moz-landing-system : lando
This commit adds a `storage_variant::HashPropertyBag` type that
exposes an idiomatic Rust interface for `nsIWritablePropertyBag`.
Differential Revision: https://phabricator.services.mozilla.com/D21062
--HG--
extra : moz-landing-system : lando
If main thread is busy handling runnables in the normal priority queue, control-type of messages from
workers are possibly postponed to run after those. That can lead to bad performance, if the page
expects workers to be able to proceed simultanously with the main thread.
This patch makes the control messages to use medium high priority queue in order to try to
ensure they are handled in timely manner.
Pref dom.worker.use_medium_high_event_queue can be set to false to disable this new behavior.
Differential Revision: https://phabricator.services.mozilla.com/D22128
--HG--
extra : rebase_source : 447dec6dbcccaa0206a1815c21ccf713c523fc91
Boris Zbarsky
Andrew McCreight
Olli Pettay
Jean-Yves Avenard
Brindusan Cristian
Nathan Froyd
Sean Feng
Haik Aftandilian
Geoff Brown
Edgar Chen
arthur.iakab
Frederik Braun
Masayuki Nakano
Bogdan Tara
Randell Jesup
Mike Conley
Emilio Cobos Álvarez
Andreea Pavel
Gijs Kruitbosch
Sylvestre Ledru
Doug Thayer
Dorel Luca
Honza Bambas
Noemi Erli
Zibi Braniecki
Edwin Gao
Ryan Hunt
Myk Melez
Coroiu Cristina
Byron Campen [:bwc]
Razvan Maries
Rob Wu
Dave Townsend
Gurzau Raul
Gabriele Svelto
Ian Moody
Kirk Steuber
Henri Sivonen
Cosmin Sabou
Cameron McCormack
Mike Hommey
Martin Stransky
Julian Descottes
Michael Froman
Aaron Klotz
Lina Cambridge
Jeff Walden
Csoregi Natalia
Narcis Beleuzu
Ciure Andrei
Randall E. Barker
Daniel Varga
Petr Sumbera
Daosheng Mu
Andrew Osmond
Eden Chuang
Jeff Gilbert
Gerald Squelart
Jonathan Kew
Philip Chimento
Oana Pop Rus
Mark Banner
Mats Palmgren
shindli
Nika Layzell
Nicholas Nethercote
Mark Goodwin
Valentin Gosu
Alex Gaynor
ffxbld
Chris Peterson
Andrea Marchesini
David Major
Chris Pearce
Nathan Froyd
Florian Quèze
Eric Rahm
Masatoshi Kimura
Brian Hackett
Yaron Tausky
Nicolas Chevobbe
Peter Van der Beken
Jed Davis
Karl Tomlinson