Also implements SourceTableEntry and nsIDHasher to switch ClientManagerService's
nsDataHashTable to a mozilla::HashMap<nsID, SourceTableEntry> in following
changesets.
Differential Revision: https://phabricator.services.mozilla.com/D66144
--HG--
extra : moz-landing-system : lando
Converts security.data_uri.unique_opaque_origin to a static pref. This pref was initialized by the ClientManager in ClientPrefs, so this commit also removes those files. Somehow this pref was getting added in VarCache twice, so it also removes the places where the pref was added in Networking.
Differential Revision: https://phabricator.services.mozilla.com/D67185
--HG--
extra : moz-landing-system : lando
ClientChannelHelperParent is the thing creating the ClientInfos which aren't
backed by existing ClientSources, so it may make sense for CCHP to tell the
ClientManagerService (CMS) to "expect" or "forget" a "future"
ClientSource(Parent).
When such a ClientInfo is created, CCHP notifies the CMS that a future
ClientSource may be created. This notification has to be observed before any
ClientHandles try to query CMS to a ClientSourceParent, which is the case
because the notification as well as ClientHandleParent constructors occur over
PBackground, and the notification sending method is called first.
CMS is told to forget the future ClientSource whenever a redirect occurs that
would result in the creation of a new ClientSource (i.e. a new ClientInfo). It's
also possible that the ClientInfo's LoadInfo's channel is cancelled. To account
for this, CHCP stores the most recent ClientInfo it's created and tells CMS
to _possibly_ forget the associated future ClientSource in its destructor. It's
possible that the channel completed its load, in which case this notification
is a no-op. This also relies on CHCP being destroyed after the reserved
ClientSource has a chance to both be created and register its
ClientSourceParent.
Differential Revision: https://phabricator.services.mozilla.com/D66529
--HG--
extra : moz-landing-system : lando
The changes only make it possible for ClientManagerService to store
FutureClientSourceParents, but it will not actually store them until
following changesets.
Differential Revision: https://phabricator.services.mozilla.com/D66145
--HG--
extra : moz-landing-system : lando
Also implements SourceTableEntry and nsIDHasher to switch ClientManagerService's
nsDataHashTable to a mozilla::HashMap<nsID, SourceTableEntry> in following
changesets.
Differential Revision: https://phabricator.services.mozilla.com/D66144
--HG--
extra : moz-landing-system : lando
Converts security.data_uri.unique_opaque_origin to a static pref. This pref was initialized by the ClientManager in ClientPrefs, so this commit also removes those files. Somehow this pref was getting added in VarCache twice, so it also removes the places where the pref was added in Networking.
Differential Revision: https://phabricator.services.mozilla.com/D67185
--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
Now that we're guaranteed to not have an existing ClientSource in the old process, we no longer need to allocate a new ClientInfo in the new process.
This lets us just create a ClientSource around the ClientInfo already on the channel (exactly as we do for same-process loads), and we no longer need to reconcile changes with the parent.
Differential Revision: https://phabricator.services.mozilla.com/D63808
--HG--
extra : moz-landing-system : lando
Rather than creating a ClientSource in the content process for the initial URL, this changes us to just create the ClientInfo in the parent, as we do for redirects.
Differential Revision: https://phabricator.services.mozilla.com/D63807
--HG--
extra : moz-landing-system : lando
This should be a no-op, but should make the following changes easier to reason about.
Differential Revision: https://phabricator.services.mozilla.com/D63805
--HG--
extra : moz-landing-system : lando
Rather than creating a ClientSource in the content process for the initial URL, this changes us to just create the ClientInfo in the parent, as we do for redirects.
Differential Revision: https://phabricator.services.mozilla.com/D63807
--HG--
extra : moz-landing-system : lando
This should be a no-op, but should make the following changes easier to reason about.
Differential Revision: https://phabricator.services.mozilla.com/D63805
--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
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
For some of these I had to take a guess due to lack of familiarity with this
code, so careful review of the actual strings would be much appreciated.
There's still a bunch of code in dom/serviceworkers that constructs a
CopyableErrorResult from just an nsresult, but I don't understand that code well
enough to write good error messages.
Differential Revision: https://phabricator.services.mozilla.com/D61201
--HG--
extra : moz-landing-system : lando
Some of these error messages are not very informative; better ones would be appreciated.
Differential Revision: https://phabricator.services.mozilla.com/D61200
--HG--
extra : moz-landing-system : lando
Replace all implicit copies by moves, or explicit clone operations.
Fixed a bug in /home/simon/work/ipdl/ipc/ipdl/ipdl/lower.py _cxxConstRefType,
which caused the const accessor to miss const on its return type for a moveonly
struct member.
Removed unused using directives for SerializedStructuredCloneBuffer in ipdl files.
Differential Revision: https://phabricator.services.mozilla.com/D59742
--HG--
extra : moz-landing-system : lando
Replace all implicit copies by moves, or explicit clone operations.
Fixed a bug in /home/simon/work/ipdl/ipc/ipdl/ipdl/lower.py _cxxConstRefType,
which caused the const accessor to miss const on its return type for a moveonly
struct member.
Removed unused using directives for SerializedStructuredCloneBuffer in ipdl files.
Differential Revision: https://phabricator.services.mozilla.com/D59742
--HG--
extra : moz-landing-system : lando
This intended to fix some windows builds, but that didn't end up working.
This removes some unused members and such, and fixes some missing includes
that they uncover (whoops).
This was needed because some windows headers used in the sandbox redefine STRICT
(which is used by `StyleContain`) and `TRANSPARENT`, which is used by some WR
stuff.
Differential Revision: https://phabricator.services.mozilla.com/D56317
--HG--
extra : moz-landing-system : lando
The inclusions were removed with the following very crude script and the
resulting breakage was fixed up by hand. The manual fixups did either
revert the changes done by the script, replace a generic header with a more
specific one or replace a header with a forward declaration.
find . -name "*.idl" | grep -v web-platform | grep -v third_party | while read path; do
interfaces=$(grep "^\(class\|interface\).*:.*" "$path" | cut -d' ' -f2)
if [ -n "$interfaces" ]; then
if [[ "$interfaces" == *$'\n'* ]]; then
regexp="\("
for i in $interfaces; do regexp="$regexp$i\|"; done
regexp="${regexp%%\\\|}\)"
else
regexp="$interfaces"
fi
interface=$(basename "$path")
rg -l "#include.*${interface%%.idl}.h" . | while read path2; do
hits=$(grep -v "#include.*${interface%%.idl}.h" "$path2" | grep -c "$regexp" )
if [ $hits -eq 0 ]; then
echo "Removing ${interface} from ${path2}"
grep -v "#include.*${interface%%.idl}.h" "$path2" > "$path2".tmp
mv -f "$path2".tmp "$path2"
fi
done
fi
done
Differential Revision: https://phabricator.services.mozilla.com/D55442
--HG--
extra : moz-landing-system : lando
The inclusions were removed with the following very crude script and the
resulting breakage was fixed up by hand. The manual fixups did either
revert the changes done by the script, replace a generic header with a more
specific one or replace a header with a forward declaration.
find . -name "*.idl" | grep -v web-platform | grep -v third_party | while read path; do
interfaces=$(grep "^\(class\|interface\).*:.*" "$path" | cut -d' ' -f2)
if [ -n "$interfaces" ]; then
if [[ "$interfaces" == *$'\n'* ]]; then
regexp="\("
for i in $interfaces; do regexp="$regexp$i\|"; done
regexp="${regexp%%\\\|}\)"
else
regexp="$interfaces"
fi
interface=$(basename "$path")
rg -l "#include.*${interface%%.idl}.h" . | while read path2; do
hits=$(grep -v "#include.*${interface%%.idl}.h" "$path2" | grep -c "$regexp" )
if [ $hits -eq 0 ]; then
echo "Removing ${interface} from ${path2}"
grep -v "#include.*${interface%%.idl}.h" "$path2" > "$path2".tmp
mv -f "$path2".tmp "$path2"
fi
done
fi
done
Differential Revision: https://phabricator.services.mozilla.com/D55442
--HG--
extra : moz-landing-system : lando
Although many Clients API usages are inherently exclusive (a specific claim
or control request), the execution-ready promise is shared by all requests
to get the state of a client that is not yet execution ready.
Differential Revision: https://phabricator.services.mozilla.com/D49976
--HG--
extra : moz-landing-system : lando
We fail navigation-redirect.https.html?client without this (with the subtest to redirects to a cross-origin page and then redirects back again to a same-origin page). In this case the ClientChannelHelper running in the child only sees a same-origin redirect (the first URL to the final one), but we've still allocated a new ClientInfo in the parent and we want to create the corresponding ClientSource.
Differential Revision: https://phabricator.services.mozilla.com/D49870
--HG--
extra : moz-landing-system : lando
Although many Clients API usages are inherently exclusive (a specific claim
or control request), the execution-ready promise is shared by all requests
to get the state of a client that is not yet execution ready.
Differential Revision: https://phabricator.services.mozilla.com/D49976
--HG--
extra : moz-landing-system : lando
We fail navigation-redirect.https.html?client without this (with the subtest to redirects to a cross-origin page and then redirects back again to a same-origin page). In this case the ClientChannelHelper running in the child only sees a same-origin redirect (the first URL to the final one), but we've still allocated a new ClientInfo in the parent and we want to create the corresponding ClientSource.
Differential Revision: https://phabricator.services.mozilla.com/D49870
--HG--
extra : moz-landing-system : lando
This does many things:
1) stops producing (and consuming) `FennecJNI*` JNI wrappers
2) removes the :app and :thirdparty Gradle projects
3) removes relevant pieces of the Gradle target configuration
4) updates lints
5) purges old configurations
After this commit, the `mobile/android` project/application builds
only GeckoView.
Differential Revision: https://phabricator.services.mozilla.com/D46536
--HG--
extra : moz-landing-system : lando
This patch introduces the concept of a "future ClientSource" to the
ClientManagerService. A "future ClientSource" is registered/removed
from the ClientManagerService by
ClientManager::{Register,Forget}FutureClientSource and is required
when a ClientInfo is initially created without a backing ClientSource.
As a result, the ClientManagerService can distinguish between a
ClientSourceParent* that has yet to register itself with the
ClientManagerService and a ClientSourceParent* that has already
both registered and removed itself from the ClientManagerService.
Differential Revision: https://phabricator.services.mozilla.com/D47592
--HG--
extra : moz-landing-system : lando
NS_ERROR_DOM_TYPE_ERR is not much better, but this at least allows us to get
rid of NS_ERROR_TYPE_ERR completely...
Differential Revision: https://phabricator.services.mozilla.com/D46485
--HG--
extra : moz-landing-system : lando
Adds a ServiceWorkerDelegate to GeckoRuntime that allows GeckoView applications
to handle ServiceWorkerClient.openWindow() requests.
Differential Revision: https://phabricator.services.mozilla.com/D45572
--HG--
extra : moz-landing-system : lando
There are some unfortunate aspects of openWindow() and openWindow2() that make
this difficult. Namely, they sometimes return top-level chrome windows, and
sometimes a single content window from the top-level chrome window that they
open, depending on how they're called.
There really isn't any reason to return a BrowsingContext rather than a chrome
window in the former case, but there also really isn't a way to make the API
polymorphic in a way that would allow handling the two cases differently. So
at some point, the two cases should ideally be split into separate APIs rather
than separate special cases of a single API.
In the mean time, I've left openWindow() returning local mozIDOMWindowProxy
objects, since it isn't used by the DOM window.open() or openDialog() APIs,
and only updated openWindow2(). As a follow-up, we should remove both
openWindow() and openWindow2(), and replace them with openChromeWindow() and
openContentWindow() (or similar) methods which make it immediately clear what
type of window is being returned.
Differential Revision: https://phabricator.services.mozilla.com/D35689
--HG--
extra : moz-landing-system : lando
This is the first step in making it possible to return remote WindowProxy
objects from window.open() and related APIs.
This patch also incidentally fixes a bug where getContentWindowOrOpenURI
returned the top-level browser window rather than the new content window when
passed OPEN_NEWWINDOW for the `aWhere` parameter. This was not the expected
behavior, and was a potentially major footgun for any new users who expected
to always get the content window for the URL they were loading, rather than
sometimes getting a chrome browser window instead.
For now, that case just returns null, which is only a minor footgun, rather
than the major one we had before.
Differential Revision: https://phabricator.services.mozilla.com/D35688
--HG--
extra : moz-landing-system : lando
Also, in many place, we use document uri as referrer. It is not right
for the case srdoc iframe. We should use the last non-srdoc parent
document's uri
Differential Revision: https://phabricator.services.mozilla.com/D30191
--HG--
rename : testing/web-platform/tests/referrer-policy/generic/iframe-inheritance.html => testing/web-platform/tests/referrer-policy/generic/inheritance/iframe-inheritance-data.html
rename : testing/web-platform/tests/referrer-policy/generic/iframe-inheritance.html => testing/web-platform/tests/referrer-policy/generic/inheritance/iframe-inheritance-srcdoc.html
extra : moz-landing-system : lando
Right now there's some duplicated code with the focus manager and the
DOMWindowFocus event.
Android didn't handle the new framefocusrequested event, so the test-cases in
bug 416771 still didn't work there.
I think using the focus manager codepath everywhere is preferable. I confirmed
manually that the stuff that sent DOMWindowFocus events still works as expected
with this patch (i.e., switching to the right tab when you click on a
notification, etc.).
This fixes it so that it works in Fennec, and it sends the focus events right in
GeckoView Example (i.e., we get here[1] properly).
The snippet that Snorp provided on IRC to implement the "bring activity to
front" stuff (`startActivity(getIntent())`) didn't actually work for me, but I
confirmed that the right message is sent when the focus is requested, and that
we get there.
[1]: https://searchfox.org/mozilla-central/rev/952521e6164ddffa3f34bc8cfa5a81afc5b859c4/mobile/android/geckoview_example/src/main/java/org/mozilla/geckoview_example/GeckoViewActivity.java#503
Depends on D32353
Differential Revision: https://phabricator.services.mozilla.com/D32354
--HG--
extra : moz-landing-system : lando
The class contains original full referrer and referrer policy will be
applied to the referrer.
Differential Revision: https://phabricator.services.mozilla.com/D17923
--HG--
extra : moz-landing-system : lando
Summary: Really sorry for the size of the patch. It's mostly automatic
s/nsIDocument/Document/ but I had to fix up in a bunch of places manually to
add the right namespacing and such.
Overall it's not a very interesting patch I think.
nsDocument.cpp turns into Document.cpp, nsIDocument.h into Document.h and
nsIDocumentInlines.h into DocumentInlines.h.
I also changed a bunch of nsCOMPtr usage to RefPtr, but not all of it.
While fixing up some of the bits I also removed some unneeded OwnerDoc() null
checks and such, but I didn't do anything riskier than that.
We'll always need a URI for DocShellLoadState, and it should only
change is special circumstances. Construct the object with it, and
then follow up in Bug 1515433 for more cleanup.
Differential Revision: https://phabricator.services.mozilla.com/D13490
--HG--
extra : moz-landing-system : lando
By forcing our subject principal to be that of the service worker, we confuse
the permissions-checking code in the new process we create for
clients.openWindow. We need to tell the new process about the principal that's
doing work before it does any work.
Further principals (such as the principal for the loaded page) will be passed
down to the child via the various networking channels that we create for it.
Differential Revision: https://phabricator.services.mozilla.com/D14799
--HG--
extra : moz-landing-system : lando
By forcing our subject principal to be that of the service worker, we confuse
the permissions-checking code in the new process we create for
clients.openWindow. We need to tell the new process about the principal that's
doing work before it does any work.
Further principals (such as the principal for the loaded page) will be passed
down to the child via the various networking channels that we create for it.
Differential Revision: https://phabricator.services.mozilla.com/D14799
--HG--
extra : moz-landing-system : lando
The missing return would have caused an assertion if OpenWindow had failed as you can't reject a promise twice.
Differential Revision: https://phabricator.services.mozilla.com/D14030
--HG--
extra : moz-landing-system : lando
Make consistent use of MozPromise chaining where possible and remove unnecessary refcount.
Differential Revision: https://phabricator.services.mozilla.com/D14029
--HG--
extra : moz-landing-system : lando
- Expose FetchEvent.resultingClientId on non-subresource, non-"report"-destination requests.
- Delay Clients.get(FetchEvent.resultingClientId) resolution until the resulting client is execution ready.
- Add WPTs to test for existence of resultingClientId and Clients.get promise resolution values.
Differential Revision: https://phabricator.services.mozilla.com/D5333
--HG--
extra : moz-landing-system : lando
LocalStorage needs to be exposed in every context except for sandboxes and
NullPrincipals (data: URLs, for instance). But we need to keep data
separate in some scenarios: private-browsing and trackers.
In private-browsing, LocalStorage keeps data in memory, and it shares
StorageEvents just with other origins in the same private-browsing
environment.
For Trackers, we expose a partitioned LocalStorage, which doesn't share
data with other contexts, and it's just in memory. Partitioned localStorage
is available only for trackers listed in the
privacy.restrict3rdpartystorage.partitionedHosts pref. See
nsContentUtils::IsURIInPrefList to know the syntax for the pref value.
Creates the nsDocShellLoadState object, which is basically
nsDocShellLoadInfo plus a few extra fields to make it usable as a
single argument to nsDocShell::LoadURI (and eventually
nsDocShell::InternalLoad).
Subframe history handling is a huge logic block in
nsDocShell::LoadURI, which is only used on history loads. This patch
also extracts the logic out into its own function to make the body of
LoadURI clearer.
Creates the nsDocShellLoadState object, which is basically
nsDocShellLoadInfo plus a few extra fields to make it usable as a
single argument to nsDocShell::LoadURI (and eventually
nsDocShell::InternalLoad).
Subframe history handling is a huge logic block in
nsDocShell::LoadURI, which is only used on history loads. This patch
also extracts the logic out into its own function to make the body of
LoadURI clearer.
Differential Revision: https://phabricator.services.mozilla.com/D6944
--HG--
rename : docshell/base/nsDocShellLoadInfo.cpp => docshell/base/nsDocShellLoadState.cpp
rename : docshell/base/nsDocShellLoadInfo.h => docshell/base/nsDocShellLoadState.h
extra : moz-landing-system : lando
Creates the nsDocShellLoadState object, which is basically
nsDocShellLoadInfo plus a few extra fields to make it usable as a
single argument to nsDocShell::LoadURI (and eventually
nsDocShell::InternalLoad).
Subframe history handling is a huge logic block in
nsDocShell::LoadURI, which is only used on history loads. This patch
also extracts the logic out into its own function to make the body of
LoadURI clearer.
Differential Revision: https://phabricator.services.mozilla.com/D6944
--HG--
rename : docshell/base/nsDocShellLoadInfo.cpp => docshell/base/nsDocShellLoadState.cpp
rename : docshell/base/nsDocShellLoadInfo.h => docshell/base/nsDocShellLoadState.h
extra : moz-landing-system : lando
The suppressing of the error NS_ERROR_UNKNOWN_PROTOCOL will break the
web-platform-test 'windowclient-navigate.https.html' since navigating
to an invalid view-source url through the client API won't receive
any error due to the suppressing. So the test will time-out since it
waits for an error.
While navigating to an invalid view-source url with its inner url as
relative, this will pass the validity check we have right now and
do the navigation because of it takes account the baseURL while doing
the check. The invalid view-source url will be resolved into a valid
view-source url in the case. Fortunately, we won't encounter any issue
in the test in the past since the docShell will block this loading
because it's loading a view-source url inside an iframe and reports a
NS_ERROR_UNKNOWN_PROTOCOL error. But, we should faild with a
NS_ERROR_MALFORMED_URI error when doing the URL validity check.
For addressing this, this patch makes the client.navigate to not take
the baseURL into account if it is a view-source URL.
Differential Revision: https://phabricator.services.mozilla.com/D6587
--HG--
extra : moz-landing-system : lando
This patch removes the 'ScreenOrientationInternal' type from
dom/base/ScreenOrientation.h and moves it into the
HalScreenConfiguration.h header, renaming it simply to 'ScreenOrientation'
in the process. This has several knock-off effects:
- It allows files that needed ScreenOrientationInternal to include a much
smaller header than before
- It greatly reduces the number of headers pulled in when including Hal.h
- It clarifies the role of the type. The 'Internal' part in the name had
nothing to do with it being part of the implementation. The type was public
and called that way only to avoid clashing with the 'ScreenOrientation'
class. Since we moved it into a different namespace it can be renamed
safely.
- It allows a file that was manually re-declaring 'ScreenConfigurationInternal'
type to use the original one
- Finally this fixes a few files which were missing headers they actually
required but that would still build because unified compilation put them into
units that already had those headers thanks to ScreenConfiguration.h
Differential Revision: https://phabricator.services.mozilla.com/D4458
--HG--
extra : moz-landing-system : lando
We have 2 different LoadType enums with two different values, which
have to be converted between depending on whether we're going to/from
LoadInfo/nsISHEntry/etc. We should be able to just use the same enum
everywhere and not have to deal with conversion, especially since we
don't have any type safety around the enum.
MozReview-Commit-ID: 2t9vVGLpOte
Same approach as the other bug, mostly replacing automatically by removing
'using mozilla::Forward;' and then:
s/mozilla::Forward/std::forward/
s/Forward</std::forward</
The only file that required manual fixup was TestTreeTraversal.cpp, which had
a class called TestNodeForward with template parameters :)
MozReview-Commit-ID: A88qFG5AccP
This was done automatically replacing:
s/mozilla::Move/std::move/
s/ Move(/ std::move(/
s/(Move(/(std::move(/
Removing the 'using mozilla::Move;' lines.
And then with a few manual fixups, see the bug for the split series..
MozReview-Commit-ID: Jxze3adipUh
Our Client.id values were being normalized from "{uuid}" to "uuid", but not
our FetchEvent.clientId values. Because nsID::Parse accepts both forms,
this was not being caught by any tests.
Although there are ServiceWorker WPT tests that verify consistency of
returned Client.id values across multiple matchAll invocations (ex:
client-id.https.html), there are no tests that compare Client.id with
FetchEvent.clientId. All the tests largely use Clients.get() to verify
correctness/round-tripping. I looked into adding WPT tests, but we
quickly run into the test logistics problem where it's preferable to
avoid adding tests that involve effectively global state.
So, this patch:
- Changes Clients::Get() to explicitly treat client id's that start with a
"{" as invalid. This causes existing FetchEvent.clientId-related WPT
tests to fail, as we would hope.
- Duplicates the client id normalization logic that strips {} for the
FetchEvent.clientId to its point of origin in
ContinueDispatchFetchEventRunnable::Run.
- Augments our dom/serviceworkers/test/test_match_all_client_properties.html
test, which has been enforcing {}-less UUIDs for a while, to also test
FetchEvent.clientId to verify it conforms. I added some comments to the
test files too.
--HG--
extra : rebase_source : dd6d07ea880eb2c3115d8810ea246b4469ad5f96
Perry Jiang
Bas Schouten
Daniel Huigens
Kristen Wright
Mihai Alexandru Michis
Stefan Hindli
Kashav Madan
David Teller
Boris Zbarsky
Matt Woodrow
Dorel Luca
Simon Giesecke
Andrea Marchesini
Narcis Beleuzu
Oana Pop Rus
pbz
Emilio Cobos Álvarez
Gabriele Svelto
Liang-Heng Chen
Andrew Sutherland
Brindusan Cristian
Nick Alexander
Bogdan Tara
Tom Tung
Elliot Stirling
Jean-Yves Avenard
Kris Maglione
arthur.iakab
Sebastian Streich
Thomas Nguyen
Ehsan Akhgari
Christoph Kerschbaumer
Noemi Erli
Sylvestre Ledru
Cosmin Sabou
Csoregi Natalia
Jan Varga
Alex Gaynor
Kyle Machulis
Blake Kaplan
James Willcox
Perry Jiang
Yaron Tausky
Tiberius Oros
Margareta Eliza Balazs
Tim Huang
Jan de Mooij
Brian Hackett
Ben Kelly
Jeff Gilbert
Miko Mynttinen
Gurzau Raul
Nika Layzell
Sebastian Hengst
Andrew Osmond
Hiroyuki Ikezoe
Chris Peterson