This turned out to be simpler than expected. Apart from generated bindings, a lot of the callers didn't make use of the fact that the return value was a handle.
Differential Revision: https://phabricator.services.mozilla.com/D72120
- Enable BackdropFilter pref by default
- Add function IsBackdropFilterAavailable()
- Use IsBackdropFilterAvailable for relevant WebIDL instead of pref
- Add test for BackdropFilter availability
Differential Revision: https://phabricator.services.mozilla.com/D73967
- Enable BackdropFilter pref by default
- Add function IsBackdropFilterAavailable()
- Use IsBackdropFilterAvailable for relevant WebIDL instead of pref
- Add test for BackdropFilter availability
Differential Revision: https://phabricator.services.mozilla.com/D73967
`ply`, [by design](https://github.com/dabeaz/ply/issues/79), does not produce reproducible table files; hence bug 1633156. (Note that this was *always* true, but only became a problem once we switched to Python 3, which has more unpredictable dict iteration order than Python 2.7, at least prior to [3.7](https://docs.python.org/3/whatsnew/3.7.html#summary-release-highlights).)
In any other circumstance I would consider submitting a patch to `ply` to fix this, but as of the [in-progress version 4.0 of the library](https://github.com/dabeaz/ply/blob/master/CHANGES), it doesn't even emit this cached data any more, and indeed the [latest version of the code](1fac9fed64/ply) doesn't even call `open()` at all except to do logging or to read the text data to be parsed from `stdin`. So if we were going to pin our future on `ply` and upgrade to later versions of the library in the future, we would have to live in a world where `ply` doesn't generate cached table files for us anyway.
Emitting the cached table files so later build steps can consume them is an "optimization", but it's not clear exactly how much actual value that optimization provides overall. Quoth the `CHANGES` file from that repository:
```
PLY no longer writes cached table files. Honestly, the use of
the cached files made more sense when I was developing PLY on
my 200Mhz PC in 2001. It's not as much as an issue now. For small
to medium sized grammars, PLY should be almost instantaneous.
```
In practice, I have found this to be true; namely, `./mach build pre-export export` takes just about as long on my machine after this patch as it did before, and in a try push I performed, there's no noticeable performance regression from applying this patch. In local testing I also found that generating the LALR tables in calls to `yacc()` takes about 0.01s on my machine generally, and we generate these tables a couple dozen times total over the course of the `export` tier now. This isn't *nothing*, but in my opinion it's also not nearly long enough where it would be a concern given how long `export` already takes.
That `CHANGES` file also stresses that if caching this data is important, we have the option of doing so via `pickle`. If and when we decide that re-enabling this optimization is valuable for us, we should take control of this process and perform the generation in such a way that we can guarantee reproducibility.
Differential Revision: https://phabricator.services.mozilla.com/D73484
This rule is based on the ESLint built-in no-throw-literal. Cr.ERRORs are also
literals since they are just integers and so have all the same disadvantages of
no stack info.
TestInterfaceJS.js is explicitly testing handling of throwing raw Cr.ERRORs and
thus needs to stay.
Differential Revision: https://phabricator.services.mozilla.com/D28072
Instead of manually defining toStringTag we now add the toStringTag symbol to the list of properties.
This is also how we usually define toStringTag in the JS engine.
Even though this changes more code I like this approach better. Everything is centralized in the generated bindings file.
Differential Revision: https://phabricator.services.mozilla.com/D72179
This also allows us to remove JSID_FROM_BITS and gives us stronger assertions everywhere for the whack integer-string case.
Differential Revision: https://phabricator.services.mozilla.com/D72564
I am honstely still not convinced that this function should actually exists.
It seems like a convulted way of saying AtomToId, while also asserting that the atom is pinned.
Differential Revision: https://phabricator.services.mozilla.com/D72563
So that we can update the holders table correctly we will need to remove the wrapper from its original vector and add it to the one associated with the new zone.
I tried to make SetPreservingWrapper private but there's still a use in layout/style/Rule.cpp that I couldn't see an obvious fix for.
Differential Revision: https://phabricator.services.mozilla.com/D68521
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
So that we can update the holders table correctly we will need to remove the wrapper from its original vector and add it to the one associated with the new zone.
I tried to make SetPreservingWrapper private but there's still a use in layout/style/Rule.cpp that I couldn't see an obvious fix for.
Differential Revision: https://phabricator.services.mozilla.com/D68521
--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
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
I made some changes in preparation for removing nsIScriptError.flags in favor
of nsIConsoleMessage.logLevel.
Differential Revision: https://phabricator.services.mozilla.com/D66878
--HG--
extra : moz-landing-system : lando
I am not sure if you are okay with reviewing all those test changes.
Sadly it's not that easy to search through our huge JavaScript code
base for some generic name like 'isStrict'.
Differential Revision: https://phabricator.services.mozilla.com/D66573
--HG--
extra : moz-landing-system : lando
Dictionary iteration under Python 3 is in an inherently unpredictable order, and while we try to keep DEFINES ordered through the use of OrderedDicts, if at any point we populate DEFINES directly or indirectly while iterating through the contents of a non-ordered dictionary, the order of the DEFINES (and therefore the contents of the output Makefile) will be nondeterministic as well. This patch makes a number of changes to ensure that we only ever populate DEFINES in a deterministic fashion. (Note that in Python 3.7 and later, the built-in dict class actually has deterministic ordering, so these changes are technically only necessary until our minimum Python version becomes 3.7.)
Differential Revision: https://phabricator.services.mozilla.com/D66089
--HG--
extra : moz-landing-system : lando
We should throw a DOMException SyntaxError when setting pseudoElement a
syntactically invalid string or an unsupported pseudo.
Differential Revision: https://phabricator.services.mozilla.com/D66321
--HG--
extra : moz-landing-system : lando
Dictionary iteration under Python 3 is in an inherently unpredictable order, and while we try to keep DEFINES ordered through the use of OrderedDicts, if at any point we populate DEFINES directly or indirectly while iterating through the contents of a non-ordered dictionary, the order of the DEFINES (and therefore the contents of the output Makefile) will be nondeterministic as well. This patch makes a number of changes to ensure that we only ever populate DEFINES in a deterministic fashion. (Note that in Python 3.7 and later, the built-in dict class actually has deterministic ordering, so these changes are technically only necessary until our minimum Python version becomes 3.7.)
Differential Revision: https://phabricator.services.mozilla.com/D66089
--HG--
extra : moz-landing-system : lando
Callers should pass in UTF-8, since that's what the JS engine ends up with in the end anyway.
The various URL changes are because NS_NewURI converts incoming nsAString to
UTF-8 anyway. So we might as well do that up-front and then use the UTF-8
string for both the NS_NewURI call and the error-reporting if it fails.
Differential Revision: https://phabricator.services.mozilla.com/D65543
--HG--
extra : moz-landing-system : lando
CStringArrayAppender is just a copy of StringArrayAppender with the incoming
types expanded to accept both wide and narrow strings. Later patches will
remove the wide-string variants incrementally.
Differential Revision: https://phabricator.services.mozilla.com/D65537
--HG--
extra : moz-landing-system : lando
Instead of something like
"ByteStringSequenceSequenceOrByteStringByteStringRecord" we should have
"(sequence<sequence<ByteString>> or record<ByteString, Bytestring>)" in error
messages.
Please take a careful look at the resulting error messages (see attachment
in the bug) to see whether this makes sense.
Differential Revision: https://phabricator.services.mozilla.com/D64890
--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
We basically need this because some of the type conversions those guts need to
do may need a BindingCallContext.
We could probably do more optimization here to only generate the
BindingCallContext bits if we will really need them, more or less based on our
return type. But for now that doesn't seem worthwhile.
Differential Revision: https://phabricator.services.mozilla.com/D64886
--HG--
extra : moz-landing-system : lando
Dictionaries always need a BindingCallContext, because they can throw
MSG_NOT_DICTIONARY from Init().
We allow non-binding callsites to pass JSContext*, in which case they will not
get quite-as-nice error reporting.
Differential Revision: https://phabricator.services.mozilla.com/D64885
--HG--
extra : moz-landing-system : lando
We instantiate this class in various binding methods. Future patches will make
use of it to throw errors.
Differential Revision: https://phabricator.services.mozilla.com/D64883
--HG--
extra : moz-landing-system : lando
This does not change behavior at the moment, because the only callers of
ThrowErrorMessage that pass an error number that has a context pass an empty
string for the first (context) arg. Both of those callers are changed to pass
nullptr for the context in this patch.
We want to support nullptr to mean "empty context", because that way at
callsites we can avoid having extra empty strings.
We could avoid putting this machinery in place if we hardcoded the trailing
": " at all the callsites, but that would reduce future flexibility in where the
context is placed in the message string (e.g. if we wanted to move it to the
end instead of the beginning) and increase the amount of string data we have to
cart around in the binary quite noticeably: we have a _lot_ of places in
bindings where we call ThrowErrorMessage.
Differential Revision: https://phabricator.services.mozilla.com/D64882
--HG--
extra : moz-landing-system : lando
Instead of something like
"ByteStringSequenceSequenceOrByteStringByteStringRecord" we should have
"(sequence<sequence<ByteString>> or record<ByteString, Bytestring>)" in error
messages.
Please take a careful look at the resulting error messages (see attachment
in the bug) to see whether this makes sense.
Differential Revision: https://phabricator.services.mozilla.com/D64890
--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
We basically need this because some of the type conversions those guts need to
do may need a BindingCallContext.
We could probably do more optimization here to only generate the
BindingCallContext bits if we will really need them, more or less based on our
return type. But for now that doesn't seem worthwhile.
Differential Revision: https://phabricator.services.mozilla.com/D64886
--HG--
extra : moz-landing-system : lando
Dictionaries always need a BindingCallContext, because they can throw
MSG_NOT_DICTIONARY from Init().
We allow non-binding callsites to pass JSContext*, in which case they will not
get quite-as-nice error reporting.
Differential Revision: https://phabricator.services.mozilla.com/D64885
--HG--
extra : moz-landing-system : lando
We instantiate this class in various binding methods. Future patches will make
use of it to throw errors.
Differential Revision: https://phabricator.services.mozilla.com/D64883
--HG--
extra : moz-landing-system : lando
This does not change behavior at the moment, because the only callers of
ThrowErrorMessage that pass an error number that has a context pass an empty
string for the first (context) arg. Both of those callers are changed to pass
nullptr for the context in this patch.
We want to support nullptr to mean "empty context", because that way at
callsites we can avoid having extra empty strings.
We could avoid putting this machinery in place if we hardcoded the trailing
": " at all the callsites, but that would reduce future flexibility in where the
context is placed in the message string (e.g. if we wanted to move it to the
end instead of the beginning) and increase the amount of string data we have to
cart around in the binary quite noticeably: we have a _lot_ of places in
bindings where we call ThrowErrorMessage.
Differential Revision: https://phabricator.services.mozilla.com/D64882
--HG--
extra : moz-landing-system : lando
We don't really need the OOMReporterInstantiator bit. We can just use
FastErrorResult on the binding side, with casting to OOMReporter to ensure
callees take that, not an ErrorResult.
Differential Revision: https://phabricator.services.mozilla.com/D64184
--HG--
extra : moz-landing-system : lando
The callsite in DOMIntersectionObserver did end up throwing a RangeError, as the
spec requires, because in the end we just used the exception code to determine
the kind of exception to throw, but was misleading about what it was doing.
Differential Revision: https://phabricator.services.mozilla.com/D64175
--HG--
extra : moz-landing-system : lando
The method is exposed only if the consumer has the same principal as the PDF
would have if it were not getting the PDF viewer treatment.
The method just calls the print() method in the PDF viewer window.
It's enough to expose this on nsOuterWindowProxy, not RemoteOuterWindowProxy,
because PDF documents end up in the process they would have been in based on
their pre-PDF-viewer principal, since we do process determination in the parent
process but only run the pdfjs stream converter in the content process, once we
have decided which one to use.
Differential Revision: https://phabricator.services.mozilla.com/D63711
--HG--
extra : moz-landing-system : lando
The method is exposed only if the consumer has the same principal as the PDF
would have if it were not getting the PDF viewer treatment.
The method just calls the print() method in the PDF viewer window.
It's enough to expose this on nsOuterWindowProxy, not RemoteOuterWindowProxy,
because PDF documents end up in the process they would have been in based on
their pre-PDF-viewer principal, since we do process determination in the parent
process but only run the pdfjs stream converter in the content process, once we
have decided which one to use.
Differential Revision: https://phabricator.services.mozilla.com/D63711
--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
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
Replace ElementOrCSSPseudoElement with Element and add PseudoElement (which is
a DOMString) into KeyframeAnimationOptions and KeyframeEffect.
Differential Revision: https://phabricator.services.mozilla.com/D62667
--HG--
extra : moz-landing-system : lando
Converting a shared buffer source to buffer souce type should
always throw if the type isn't annotated with [AllowShared].
Differential Revision: https://phabricator.services.mozilla.com/D63047
--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 only behavior change here is that now we consistently use "Foo constructor"
to describe constructors. Before this we used "Foo" for the argument count and
arguments up to the overload resolution distinguishing argument and "Foo
constructor" for later arguments.
Differential Revision: https://phabricator.services.mozilla.com/D62346
--HG--
extra : moz-landing-system : lando
This keeps us from passing it to functions that are planning to throw on the
ErrorResult and might throw a JS exception on it.
Differential Revision: https://phabricator.services.mozilla.com/D62633
--HG--
extra : moz-landing-system : lando
The rejection process consumes the ErrorResult, so an rvalue reference is the honest thing here.
Differential Revision: https://phabricator.services.mozilla.com/D62632
--HG--
extra : moz-landing-system : lando
We need the explicit constructor because otherwise which conversion operator to
use when constructing an ErrorResult from a CopyableErrorResult&& is
ambiguous. And we want the conversion operator to allow passing
CopyableErrorResult& to functions that expect ErrorResult&&.
Differential Revision: https://phabricator.services.mozilla.com/D62631
--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
this makes us closer to the upstream spec and removes a bunch of useless code
Differential Revision: https://phabricator.services.mozilla.com/D62377
--HG--
extra : moz-landing-system : lando
Please review the changes to Errors.msg very carefully. I caught a number of
mistakes there in self-review (e.g. not renumbering replacement markers
correctly when I added {0} to the beginnings of strings), and my confidence
that I caught them all is only middling.
A few lines (MSG_USELESS_SETTIMEOUT, MSG_TYPEDARRAY_IS_DETACHED,
MSG_NOT_SUBMIT_BUTTON) were removed from Errors.msg either because they were
already unused or because they either were single-user constant strings or
became such in the new setup and we could just use the string version of
ThrowTypeError.
Differential Revision: https://phabricator.services.mozilla.com/D61523
--HG--
extra : moz-landing-system : lando
This makes it easier to static_assert correct use. It caught several bugs in
the next patch in this stack.
I had to disambiguate some calls to the templated ThrowDOMException that are
inside the binding_detail namespace, because otherwise they were trying to call
teh non-template function of the same name that's declared in binding_detail.
Differential Revision: https://phabricator.services.mozilla.com/D61522
--HG--
extra : moz-landing-system : lando
This adds the name of the interface and method to the beginning of the exception
string when reporting the exception from Web IDL codegen, so it's clearer what
was called.
Some existing error messages are adjusted to not duplicate the information
about which method was called.
Differential Revision: https://phabricator.services.mozilla.com/D61521
--HG--
extra : moz-landing-system : lando
There's no need for two explicit APIs as we get safety from the IDL layer. And
treating a SharedArrayBuffer as an empty buffer is wrong too.
Differential Revision: https://phabricator.services.mozilla.com/D60003
--HG--
extra : moz-landing-system : lando
We need this for upcoming change which supports having [AllowShared] on
ArrayBuffer type in WebIDL.
Differential Revision: https://phabricator.services.mozilla.com/D59989
--HG--
extra : moz-landing-system : lando
This was done by:
This was done by applying:
```
diff --git a/python/mozbuild/mozbuild/code-analysis/mach_commands.py b/python/mozbuild/mozbuild/code-analysis/mach_commands.py
index 789affde7bbf..fe33c4c7d4d1 100644
--- a/python/mozbuild/mozbuild/code-analysis/mach_commands.py
+++ b/python/mozbuild/mozbuild/code-analysis/mach_commands.py
@@ -2007,7 +2007,7 @@ class StaticAnalysis(MachCommandBase):
from subprocess import Popen, PIPE, check_output, CalledProcessError
diff_process = Popen(self._get_clang_format_diff_command(commit), stdout=PIPE)
- args = [sys.executable, clang_format_diff, "-p1", "-binary=%s" % clang_format]
+ args = [sys.executable, clang_format_diff, "-p1", "-binary=%s" % clang_format, '-sort-includes']
if not output_file:
args.append("-i")
```
Then running `./mach clang-format -c <commit-hash>`
Then undoing that patch.
Then running check_spidermonkey_style.py --fixup
Then running `./mach clang-format`
I had to fix four things:
* I needed to move <utility> back down in GuardObjects.h because I was hitting
obscure problems with our system include wrappers like this:
0:03.94 /usr/include/stdlib.h:550:14: error: exception specification in declaration does not match previous declaration
0:03.94 extern void *realloc (void *__ptr, size_t __size)
0:03.94 ^
0:03.94 /home/emilio/src/moz/gecko-2/obj-debug/dist/include/malloc_decls.h:53:1: note: previous declaration is here
0:03.94 MALLOC_DECL(realloc, void*, void*, size_t)
0:03.94 ^
0:03.94 /home/emilio/src/moz/gecko-2/obj-debug/dist/include/mozilla/mozalloc.h:22:32: note: expanded from macro 'MALLOC_DECL'
0:03.94 MOZ_MEMORY_API return_type name##_impl(__VA_ARGS__);
0:03.94 ^
0:03.94 <scratch space>:178:1: note: expanded from here
0:03.94 realloc_impl
0:03.94 ^
0:03.94 /home/emilio/src/moz/gecko-2/obj-debug/dist/include/mozmemory_wrap.h:142:41: note: expanded from macro 'realloc_impl'
0:03.94 #define realloc_impl mozmem_malloc_impl(realloc)
Which I really didn't feel like digging into.
* I had to restore the order of TrustOverrideUtils.h and related files in nss
because the .inc files depend on TrustOverrideUtils.h being included earlier.
* I had to add a missing include to RollingNumber.h
* Also had to partially restore include order in JsepSessionImpl.cpp to avoid
some -WError issues due to some static inline functions being defined in a
header but not used in the rest of the compilation unit.
Differential Revision: https://phabricator.services.mozilla.com/D60327
--HG--
extra : moz-landing-system : lando
rg -l 'mozilla/Move.h' | xargs sed -i 's/#include "mozilla\/Move.h"/#include <utility>/g'
Further manual fixups and cleanups to the include order incoming.
Differential Revision: https://phabricator.services.mozilla.com/D60323
--HG--
extra : moz-landing-system : lando
* Context loss using RAII
* Move Program reflection Client-side
Depends on D54018
Differential Revision: https://phabricator.services.mozilla.com/D54019
--HG--
extra : moz-landing-system : lando
Splits WebGLContext into ClientWebGLContext and HostWebGLContext. The Client enables the JS-control of a WebGL context in a content procecss while the Host executes the WebGL graphics operations (via a WebGLContext that maintains much of the existing code) in the compositor process. At this point, the cross-process behavior is disabled -- this series of patches is an incremental step toward that final goal.
Differential Revision: https://phabricator.services.mozilla.com/D54018
--HG--
extra : moz-landing-system : lando
Automatic but manually checked via s/IsBaseOf</std::is_base_of</g and so on.
Differential Revision: https://phabricator.services.mozilla.com/D59145
--HG--
extra : moz-landing-system : lando
The bounds check becomes needed now, though it should hopefully be optimized
away too as all the involved calls that you need to know about to determine that
it can't happen are inline.
Differential Revision: https://phabricator.services.mozilla.com/D58909
--HG--
extra : moz-landing-system : lando
This changeset is a simple find and replace of `MOZ_FALLTHROUGH` and `[[fallthrough]]`.
Unfortunately, the MOZ_FALLTHROUGH_ASSERT macro (to assert on case fallthrough in debug builds) is still necessary after switching from [[clang::fallthrough]] to [[fallthrough]] because:
* MOZ_ASSERT(false) followed by [[fallthrough]] triggers a -Wunreachable-code warning in DEBUG builds
* but MOZ_ASSERT(false) without [[fallthrough]] triggers a -Wimplicit-fallthrough warning in NDEBUG builds.
Differential Revision: https://phabricator.services.mozilla.com/D56440
--HG--
extra : moz-landing-system : lando
We can just take void* and then cast it explicitly, which avoids the undefined-behavior issue here.
Differential Revision: https://phabricator.services.mozilla.com/D57168
--HG--
extra : moz-landing-system : lando
Mihai Alexandru Michis
Masatoshi Kimura
Jon Coppeard
Peter Van der Beken
Simon Giesecke
Tom Schuster
Nico Grunbaum
Ricky Stewart
Sylvestre Ledru
Erik Nordin
Razvan Maries
Ian Moody
Bogdan Tara
Andrea Marchesini
Cosmin Sabou
Nika Layzell
Zibi Braniecki
Stefan Hindli
Mike Hommey
Kearwood Gilbert
Andi-Bogdan Postelnicu
André Bargull
Andrew Sutherland
Ciure Andrei
Csoregi Natalia
Byron Campen [:bwc]
Jeff Walden
David Teller
Arthur Iakab
Anthony Ramine
Marco Bonardo
Narcis Beleuzu
Boris Chiou
Daniel Varga
Boris Zbarsky
Mark Banner
Andrew McCreight
Tetsuharu OHZEKI
Dorel Luca
Mike Shal
Edgar Chen
Brindusan Cristian
Dzmitry Malyshau
Emilio Cobos Álvarez
Andreas Farre
pbz
Jeff Gilbert
David Parks
Chris Peterson
Oana Pop Rus