Let's see if this manages to reopen the CLOSED TREE. It's either raciness on
load, or it's timing out, so I hope it's this, really.
MozReview-Commit-ID: KUbJvRcTlNF
There are some places where we have a thing which may not even be a node, and
we end up hardcoding the value of DOCUMENT_NODE there, because
"foo.nodeType == foo.DOCUMENT_NODE" will test true if foo is not a node: both
sides will be undefined.
I ended up not using the nsIFrame methods both for consistency with the plain
text serializer and because of include hell due to nsStyleStructInlines /
nsIFrameInlines.
Find doesn't care about nodes with no frames anyway, so it didn't seem worth
doing the fallback if there's no style information.
I'll file a bug for IsHTMLBlock.
MozReview-Commit-ID: 3T317a4xCB
These tests ensures the feature interacts well with our setup in XUL.
They work when bug 1460815 was implemented so they sits in its own changeset.
MozReview-Commit-ID: Ia08tAewZyN
--HG--
extra : rebase_source : b7ee577efc5cb5cc573cb07df2cfeeb0a9c88699
extra : source : c142c5c69a04c86f192526f8324a0278cbb721ba
nsContentUtils::NS_NewXULOrHTMLElement will call into
CustomElementRegisty::RegisterCallbackUpgradeElement, which keeps
the newly created element, allowing RunCustomElementCreationCallback
to upgrade them after the callback runs.
It is unclear if this changes the order of constructor executions,
but even so it should not affact our use case.
MozReview-Commit-ID: LWTn7B35aBv
--HG--
extra : rebase_source : 15382431f34dd887c14142ff47337e8d1eec74ef
extra : source : 47058a61951c2974514e41e316e5370cfa4f9d8b
This would help in the case where it is safe to run script in-place and
the CustomElementDefinition is available before the function exits.
This fixes the tests changed.
MozReview-Commit-ID: Ays91W94WZm
--HG--
extra : rebase_source : 6b0f1f90de9a6bfd7db577f1fb0e76564c3627e7
extra : source : 47c62a1e2f268e1be24c3fddfc006c3ad45ba4ac
Consider the test-case where we have:
<div>
<span id=a />
<span id=b />
</div>
We try to set one bit on "a", and a different one on "b".
Ideally we'll end up with <div> as the root with both bits. But with the current
code we'd go all the way to the document unnecessarily. This fixes it by
checking the bits we've propagated up to the top instead of existingBits.
MozReview-Commit-ID: GfwjwCBpkuy
Also removes the stub workerbootstrap extensions, which previously allowed
this to work for Mochitest extensions.
MozReview-Commit-ID: LPlk8qIgJmr
--HG--
extra : rebase_source : 329f7fe11dde7a2713652591ac735b0d745070c8
extra : amend_source : 125481f030980c610217a9a1f6e51d592bda3c65
XPCShell allows interaction with object that are cycle collected, but we never run the
cycle collector in it. In XPCShell we don't call nsJSContext::EnsureStatics.
nsJSContext::EnsureStatics is responsible for setting DOMGCSliceCallback as a GC callback,
which we need for running the cycle collector.
--HG--
extra : rebase_source : 5f12c15dabf3b23d9e4b1d8d88920e476d2d4bd6
A call to NotifyDataEnded is required even if the size was known when the resource was created. This ensures that the readyState is properly updated and that playback can immediately as no more data can be added once first loaded.
MozReview-Commit-ID: FaJMBxJ9NkM
--HG--
extra : rebase_source : 448087a22635dac2aa31611c2b58a8e9c77121ec
If the particular track isn't encrypted, there's no need to wait for a CDMProxy.
MozReview-Commit-ID: DPbvbwsO58N
--HG--
extra : rebase_source : 0e7fea134404c861268dc8759cd7c0ebdf83dca4
The code couldn't have worked and didn't do what the comment stated. When the CDMProxy changes, the current PDMFactory for encrypted content can no longer be used.
MozReview-Commit-ID: 7LpcQkK5gLL
--HG--
extra : rebase_source : e3926034069285be1559d0a1ea20d5f3c1561eb7
If the content being played was first non-encrypted, the PDMFactory would have been set without a CDMProxy. As such, it is necessary to use a new PDMFactory when the encryption type changes (from clear to encrypted).
Rather than attempting to detect if the encryption status has changed, simply use two PDMFactory, one with CDMProxy set and one without (for clear content)
Also, never attempt to recycle a decoder if the encryption type changed (used only on Android)
The TrackBuffersManager would have already handle the dispatching of the encrypted event when parsing the new init segment. As such, nothing more is necessary.
MozReview-Commit-ID: Jn14P2F6N5V
--HG--
extra : rebase_source : afe254fa8c4b835b15d9d48bb52d832f28196b7e
Adding some documentation to clarify on the difference between mInfo and mOriginalInfo
MozReview-Commit-ID: DWBsoi16QKf
--HG--
extra : rebase_source : 719c17b9ce61efdb633db108230f1bf78773ee51
New windows cannot execute fullscreen requests until after the first
MozAfterPaint event has been fired on the window, because some of the
machinery in browser-fullScreenAndPointerLock.js isn't initialized until
that point. This test exercises that behaviour, and therefore should also
wait until the first MozAfterPaint before requesting fullscreen.
MozReview-Commit-ID: Igy7WfjslWA
--HG--
extra : rebase_source : 4b16293a107468bd53b8d1f54560b8acf326631f
Our behavior is correct, this uses the same setup that nsDocument and the
stylesets use, which I may look into fixing up / making more explicit in
bug 1465031.
MozReview-Commit-ID: 75AToXCw1pV
--HG--
extra : rebase_source : b7c11ca66b416c32b8fc0c5eedbc9383c63bad70
Changed DOMEventMarkerPayload to use tracing markers to be able to see unfinished
DOMEvents in the profiler. DOMEventMarkerPayload was containing both start and
end timestamps and we were adding it once DOMEvent finishes. Now, we are adding
two tracing markers. Once the event starts and once the event ends. That makes the
start of the event visible on the profiler.
MozReview-Commit-ID: Gak6dGsgMDt
--HG--
extra : rebase_source : 6d2c9930964503a4865b92d85a0437e33acf8dc7
Fairly straightforward, just a blanket removal. Haven't heard
anything on dev-platform or fx-data-dev regarding this removal,
so I think it's likely safe to remove on Nightly, and we can
revert if anyone makes a fuss.
As part of removing the HangMonitor, I renamed a few things and
reorganized the namespaces to not depend on a HangMonitor
namespace. Hopefully this doesn't produce too much noise in the
diff, it just seemed appropriate to move everything around
rather than keep dangling vestiges of the old system.
MozReview-Commit-ID: 8C8NFnOP5GU
--HG--
extra : rebase_source : a8840bd26f4b01b756ffa72345ababb625048550
Bug 1415090 attempted to remove the need to access from the MediaResource members of MediaCacheStream from the main thread.
However, by doing so the logic flow for resuming the channel changed from a synchronous access to an asynchronous one.
This changed some assumptions and allowed the ChannelMediaResource to be used before the Seek call completed.
For now, re-add a cross thread access to the MediaCacheStream. A more elegant fix will be worked on in bug 1464045
MozReview-Commit-ID: 2xBTjDEqrkI
--HG--
extra : rebase_source : 0aa3cfcb8371d5147cbed746d9200dd22df4821b
Created new class 'nsContentUtilsReporter' which reports 'content-utils-string-bundles' allocations that are not a part of the reported StringBundleService bundles
--HG--
extra : rebase_source : f683ce214d634c9c6f169fafe5b5de12d3f3508a
This will force the benchmark to be re-run, following de-activation of the AMD VP9 decoder.
MozReview-Commit-ID: KwwoQNfSJ4t
--HG--
extra : rebase_source : 4edc750d448d6f023a645457edcbd138974c7d9a
Previously, with early first paint enabled, nsXULWindow incorrectly loaded the
persisted window settings from about:blank and would only load them once.
Instead, load the settings before starting layout.
MozReview-Commit-ID: 6K4ofkbmHHb
--HG--
extra : rebase_source : 7bcd804cfabbd47ee5a747800a2ef81852213889
I've made the returned object from .bounds not live. If that's not OK, I'll
resurrect DOMBounds (removed in a previous patch). This also forces
DOMQuad.toJSON() to only return the points.
MozReview-Commit-ID: 10TY5oJUmTN
--HG--
extra : rebase_source : ab209d584390c584aa0d0814b4dd2bbf48c6cca3
Without this fix layout/reftests/css-animations/ib-split-sibling-opacity.html
would have failed if the next change in this patch series is applied.
MozReview-Commit-ID: CFNXePkXuOs
--HG--
extra : rebase_source : 48df6bf107e1a14dd2b2ae7c23d38d29581aabcb
There are a few things going on here:
1) Better tracking of whether we've done our synthetic document stuff so we
don't redo it when it's not needed. We should only be doing it on initial
load.
2) Better handling of our readystate transitions. We're only responsible for
the transition to READYSTATE_INTERACTIVE if we're the ones setting up the DOM.
Otherwise whoever is doing that should do the readystate transition.
Both of these really use the same mechanism, which is why I ended up doing them
together.
This is grafted from the first part of bug 1425104.
MozReview-Commit-ID: 4aW2w81LDTI
--HG--
extra : rebase_source : 898b926da42f7a2e332d8e01521dcd5adf381be1
extra : source : 12f8659f76fe5e23e42cb881eb7ed0b31de73864
Using concrete class types with static IIDs in QueryInterface methods is a
pretty common pattern which isn't supported by any existing helper macros.
That's lead to separate ad-hoc implementations, with varying degrees of
dodginess, being scattered around the tree.
This patch adds a helper macro with a canonical (and safe) implementation, and
updates existing ad-hoc users to use it.
MozReview-Commit-ID: HaTGF7MN5Cv
--HG--
extra : rebase_source : ace930129d85960d22bc3048ca3bb19bbbd4a63e
extra : histedit_source : 03a87f746d957789d41381e4e1bfcc4fd7eebaf2%2C9c5bae9feeeef7721105db67be0f83e0ded66bb7
This permits opening the DLL from the plugin sandbox under the USER_LIMITED sandbox setting (plugin sandbox level 3).
--HG--
extra : rebase_source : cf3719f7b418b3fcbb5244d06203836fd32e3900
extra : histedit_source : 9bacced088b9965cee10c871f3934980e0361dcc
Process and non-process managers have different script loader interfaces
(ProcessScriptLoader/GlobalProcessScriptLoader vs FrameScriptLoader). The WebIDL
conversion used the same interface for some process and
non-process managers, but because of the different script loader interfaces they really
should be using separate interfaces.
--HG--
rename : dom/base/ChromeMessageBroadcaster.cpp => dom/base/MessageBroadcaster.cpp
rename : dom/base/ChromeMessageBroadcaster.h => dom/base/MessageBroadcaster.h
rename : dom/base/ChromeMessageBroadcaster.cpp => dom/base/ParentProcessMessageManager.cpp
rename : dom/base/ChromeMessageBroadcaster.h => dom/base/ParentProcessMessageManager.h
rename : dom/base/ChromeMessageSender.cpp => dom/base/ProcessMessageManager.cpp
rename : dom/base/ChromeMessageSender.h => dom/base/ProcessMessageManager.h
extra : rebase_source : 6694ae975bc2af1b496db6b8cef645ec62582d9a
The frame is notified via its mListener, which is an observer of the
nsImageLoadingContent (mContent).
This last one only notifies for the current and pending requests, otherwise it's
a bug we need to fix there, not wallpaper here, since that'd mean that we forgot
to cancel the previous request. Added assertions to that effect.
Notify() is only called with the this object as a first argument from
imgRequestProxy, so it'd better be non-null, too.
MozReview-Commit-ID: DHaOLph2EAo
Before that we were not notifying the image frame in any way if we ended up not
doing a load, and we were instead relying on the reflow the viewport resize
caused to get the new density in ComputeSize from the content node (but nowhere
else, since that's the bug part 1 fixes).
This was generally unsound, since you can stash random media in a sizes=
attribute, which don't necessarily needs to cause a reflow.
Now we need to notify necessarily because nsImageFrame stores the adjusted
intrinsic size.
mCurrentDensity could also get out of sync as well, when the selected image
density changed, but we ended up returning early because our source hadn't
change in the first early exit.
This patch moves us to a model where we don't re-trigger loads for density
changes if the source doesn't change (unless we pass aAlwaysLoad when we need
to, per spec).
This matches our previous behavior (without the bugginess of not updating the
intrinsic size), and also Chromium, at least.
This changes behavior in one case, which is when we don't load the same source
node, but we have the same source URL, and the density does change. This could
happen with <picture> and two <source>s with same source and different media and
sizes. This makes our behavior consistent with the behavior we have when both
the source and the density doesn't change.
Blink and WebKit do trigger a second image load both when the source changes
without changing density and when density changes. I'll file a spec issue, since
per:
https://html.spec.whatwg.org/#reacting-to-environment-changes
We should be triggering the load when the density changes but the source
doesn't as well, but no UA does that.
I filed https://github.com/whatwg/html/issues/3709 with a little summary of the
situation and what I think the behavior should be (which is what this patch
implements). That being said, I'll update the impl if the spec people think
otherwise :).
MozReview-Commit-ID: Eqy16ygHRLo
Only doing it in ComputeSize (via GetNaturalSize) is unsound, and the rest of
the users of mIntrinsicSize definitely do need scaling accounted for.
Move the adjustment to nsImageFrame for two reasons:
* Prevents adding more dependencies from nsIImageLoadingContent, which
otherwise would need to go away anyway in bug 215083.
* Avoids having to duplicate the image orientation logic, since mImage is
already an OrientedImage if needed.
MozReview-Commit-ID: EA0n0TctZhN
Process and non-process managers have different script loader interfaces
(ProcessScriptLoader/GlobalProcessScriptLoader vs FrameScriptLoader). The WebIDL
conversion used the same interface for some process and
non-process managers, but because of the different script loader interfaces they really
should be using separate interfaces.
--HG--
rename : dom/base/ChromeMessageBroadcaster.cpp => dom/base/MessageBroadcaster.cpp
rename : dom/base/ChromeMessageBroadcaster.h => dom/base/MessageBroadcaster.h
rename : dom/base/ChromeMessageBroadcaster.cpp => dom/base/ParentProcessMessageManager.cpp
rename : dom/base/ChromeMessageBroadcaster.h => dom/base/ParentProcessMessageManager.h
rename : dom/base/ChromeMessageSender.cpp => dom/base/ProcessMessageManager.cpp
rename : dom/base/ChromeMessageSender.h => dom/base/ProcessMessageManager.h
extra : rebase_source : d19120fb59b413aecf4e78aee8dc845022cd84dd
This is fairly straightforward, other than the fact that the
nomenclature gets a bit awkward with the aForce parameter on
the ForcePaint methods. I'm not sure which direction to go with
this - "aForce" seems a fairly intuitive name for what we want,
and I'm kind of inclined to say the existing ForcePaint mechanic
should be renamed to something like PaintWithInterrupt, or
PaintWithPriority.
MozReview-Commit-ID: Bj9DROug1pC
--HG--
extra : rebase_source : a3d91fec940d83325d36bafb13fe892e9c9530e8
After digging into this, I'm still not entirely sure why the timing
has changed such that the checks don't work immediately. I have a
strong suspicion though that it's simply because our tab switch is
now instant, resulting in the necessary messages just being a
little bit behind. Hopefully this is an acceptable bandaid.
MozReview-Commit-ID: H1wKW1UQBxp
--HG--
extra : rebase_source : 993c3e97852894ddd64561d039fbf0e71d607066
Nodes copied from DOMParser document fragment would need to be
created with the proper custom element data.
CustomElementRegistry::IsCustomElementEnabled() is changed to allow
it to run in the test document.
MozReview-Commit-ID: 4GACDR8FIc7
--HG--
extra : rebase_source : 39da41dd1ca56bf62043418c503c526e2895254f
the id was a b2g feature only settable via chrome privd xhr and is no
longer active in the code base
MozReview-Commit-ID: 84GPNvhvjNb
--HG--
extra : rebase_source : ab5c2229b98e1407b8b74ef2ee00dcfea45e046a
Currently we can end up dispatching a 'playing' event right before we reject
play() promises, and this confuses YouTube's controls, and it doesn't make
sense to dispatch a 'playing' event when we're not playing anyway.
This is because the logic to delay resolving the play() promise until after
we've reached loadedmetadata doesn't prevent the 'playing' event from being
dispatched. We shouldn't dispatch 'playing' until we resolve the play()
promise(s).
MozReview-Commit-ID: 5H4dcObfu4M
--HG--
extra : rebase_source : b4036a8fead95cd3070f9fc4d30e0feb23d1f64c
This also removes the workerbootstrap test extension, which is no longer used,
and contains the last references to the Worker and ChromeWorker bootstrap
globals.
MozReview-Commit-ID: 8YWReXMqX5W
--HG--
extra : rebase_source : b0aa59b2b5e6a08f4be803e828bd507f894e4a19
There are two issues being fixed here. First, if DisallowBFCaching is called
before CanSavePresentation, we should really return false from
CanSavePresentation. Otherwise we'll end up doing a bunch of state-capturing
work for no reason.
Second, if DisallowBFCaching is called between CanSavePresentation and
nsDocumentViewer::Destroy, we need to actually tear down the viewer state.
What we do right now is avoid putting the viewer into the SHEntry, but still
not tear down its presshell and so forth, which leads to asserts in
~nsDocumentViewer when this case is hit.
1) The passed-in constructor is already same-compartment with the passed-in
aCx, so there is no need to enter its Realm to work with it.
2) aCx is already in the compartment of constructorProtoUnwrapped when we do
JS_WrapValue on rootedv, which is initialized to constructorProtoUnwrapped.
That JS_WrapValue call is not needed.
This check is already done by the dictionary init method. This function just
makes us do extra non-spec get operations.
For now this introduces more failures due to bug 1419323 and the spec issue at
<https://github.com/whatwg/html/issues/3580>. The tests testing for that stuff
were passing due to exceptions getting thrown from CheckLifeCycleCallbacks.
1. Add AddressErrors in PaymentRequest.webidl.
2. IPC for passing AddressErrors.
3. Getters for AddressErrors in nsIPaymentDetails.
--HG--
extra : rebase_source : 64c57003d57e064b5284cc64447c0c0740f16121
We currently set the Android JavaVM pointer in MediaEngineWebRTC.
However, because of that, we end up setting the pointer in the child
process, even though we really want to set the pointer in the parent
process because that's where the camera will be accessed.
This patch makes us set JavaVM inside VideoEngine itself, where we
actually access the camera in the parent process.
MozReview-Commit-ID: 3TeLiiK2vyh
We want to have some class names with spaces in them, but everything assumes
that an interface identifier is in fact an identifier (e.g. uses it in C++
identifiers like namespace names).
Compared to the spec, we had the following differences:
* Date was a JSON type in our implementation. It doesn't even exist as a type
in the spec. It stops being a JSON type.
* Annotated types are not supported yet. Nothing changes here.
* Typedef types were not JSON types in our implementation. They become JSON
types if the type it's a typedef for is one.
* Frozen arrays are not supported yet. nothing changes here.
* Records were not JSON types in our implementation. They become JSON types
when the value type is a JSON type.
* Object was not a JSON type in our implementation. It becomes a JSON type.
* Interface types were only JSON types in our implementation if they had a
jsonifier. We change to treating them as JSON types if there is a jsonifier
anywhere on the inheritance chain.
In terms of observable behavior, the following properties now get included by
toJSON methods that didn't use to be included:
PaymentResponse.details
Performance.mozMemory
both because they're of type "object".
Without this, we will start including mozMemory in performance.toJSON() even if
the pref for it is not set, once 'object' becomes a JSON type.
This changes behavior in the following observable ways:
1) We stop exposing PerformanceResourceTiming's .serverTiming in the JSON
serialization in insecure contexts.
2) We stop exposing PerformanceTiming's timeToNonBlankPaint and
timeToDOMContentFlushed in the JSON serialization unless the relevant
preferences are turned on.
This patch enables us to specify a custom element type with |is| attribute
or property when creating a XUL element. Because non-dashed names are valid
custom element names in XUL (bug 1446247), other checks has to modified
accordingly.
The checks I am settling with are
1) Forbids the custom built-in element names to be a non-dashed name.
2) Forbids the custom built-in element to extend a dashed built-in element name.
This also ensures the custom built-in element types don't take on the same
name as the element name it extends.
MozReview-Commit-ID: GCQ9RnfvvrC
--HG--
extra : rebase_source : 2fa13742525d2107580d50872ff5b0fc42539498
extra : source : 2dc5513660d78a4de4801109140743ffc9297f71
Doesn't look like it's strictly necessary, but suppresses the warning.
MozReview-Commit-ID: EQBar71yNVg
--HG--
extra : rebase_source : 063639000fd47b32343d47a8ca428c134fdce43b
Add .eslintrc.js to configure globals from mediasource.js and to add extra
rules to encourage use of let and const over var.
Linting changes:
- Prefer const and let to var. This provides tighter scoping and avoids
reassignment.
- Mozilla rules do not allow for shadowing of variables, so several tests have
had promise lists renamed to avoid this.
- Numerous minor fixes to formatting including using double quotes, spacing,
missing semicolons.
- Remove some unused variables.
- Arrays have spaces after opening braces and before closing braces, e.g.
[ "foo" ], this is to be consistent with our clang-format rules.
- Fix naming of resourcePathSeen in test_MediaSource_memory_reporting.html.
MozReview-Commit-ID: 5q6oS7EWLTk
--HG--
extra : rebase_source : 9b67b294f338ca9205b52fded3af63e6c3ac9a5a
Add back code to block big messages in DispatchAsyncMessage that wasn't added to the
codepath used by the WebIDL bindings. Also remove the non-WebIDL version of
DispatchAsyncMessage, as it's now unused.
--HG--
extra : rebase_source : ec7e5663683c98de4275ce05d6ada2f175dcb355
Under most cases, the frame decoded height is just the displayed height rounded to the next 16 row aligned value.
However, this doesn't appear to always be the case. So we query the WMF framework for the decoded frame size.
We continue to use the displayed sizes as found in the SPS to ensure proper display of non 1:1 aspect ratio.
Adding diagnostic assertion to find potential regressions, we will address those as they come.
MozReview-Commit-ID: L8VowEw6L9F
--HG--
extra : rebase_source : 49acd9fd36469ee0a4e1ed0fe5cd6f2211ba8117
TaskQueue::Dispatch returns a nsresult which must be checked.
MozReview-Commit-ID: 7Tl7O96rQNt
--HG--
extra : rebase_source : e898b776f765a5641a794a7242715728940075f6
This patch creates a chrome-only method
customElements.setElementCreationCallback() so that custom elements migrated
from XBL bindings doesn't have to be define()'d on document loading. With this
method, we will set callbacks and the platform will get back to us when it
encounters a matched custom element type -- and the callback will load the
relevant script.
It's important to note that the callback runs after construction of the first
element; it will be upgraded when it's being appended.
MozReview-Commit-ID: 80z72zwXRlf
--HG--
extra : rebase_source : 826188e56bb0b167d1e5bafb7d2a487a32bd9dfa
For doing this, ServoComputedData is split into separate files, so that
files don't need to include ServoBindings.h just for accessing style
structs from ComputedStyles.
MozReview-Commit-ID: DPAd7PUUCl9
--HG--
extra : rebase_source : 7d6f739b7fb58a46e1624ba62e717412057ea9c1
The term "entry" is already used for elements in the profile buffer.
MozReview-Commit-ID: 1aB22V6veQh
--HG--
extra : rebase_source : c664eb4d6bed6cb74ba8a1b67ea99bd8ca57bcf7
extra : source : 3264c0cc0027b240b55bd3aebf27263b1e1d1cc0
David Parks
Cosmin Sabou
Noemi Erli
Emilio Cobos Álvarez
Andrea Marchesini
Boris Zbarsky
Tom Ritter
shindli
Timothy Guan-tin Chien
Alexander Surkov
Kris Maglione
rahul0379
Alex Gaynor
Jan-Ivar Bruaroey
Jan de Mooij
Peter Van der Beken
Margareta Eliza Balazs
Paul Adenot
Jean-Yves Avenard
Kartikaya Gupta
Dorel Luca
Kearwood Gilbert
Olli Pettay
Coroiu Cristina
Makoto Kato
Vinothkumar Nagasayanan
Gurzau Raul
Shane Caraveo
Nazım Can Altınova
Doug Thayer
Bogdan Tara
Narcis Beleuzu
Kristen Wright
Brindusan Cristian
Brendan Dahl
Blake Kaplan
Hiroyuki Ikezoe
Andreea Pavel
Natalia Csoregi
Jon Coppeard
Xidorn Quan
Jeff Gilbert
Tom Schuster
Stephen A Pohl
Nicolas B. Pierron
Ben Kelly
Andreea Pavel
Patrick McManus
Chris Pearce
Jim Mathies
Eden Chuang
Jim Chen
Ciure Andrei
Jonathan Kingston
Tim Taubert
Bryce Van Dyk
Adrian Wielgosik
Markus Stange