We only want to process the AppEntered/Left message if it actually concerns our currently displayed tab.
MozReview-Commit-ID: EJ8RzRzDNAz
--HG--
extra : rebase_source : 2d05c8131a3b25968b36704647a9041b15599668
Restoring anything other than normal browsing tabs (e.g. custom tabs, web apps) is more involved because those tabs
- don't appear in our normal tabs UI
- are opened in separate activities
- when we're starting up, Android's task switcher might or might not still have available task entries corresponding to such tabs from the last session
Therefore, for now, the session store will simply exclude those kinds of tabs from being saved in the session store data.
Instead of a real restore, if the corresponding tab has been closed or Gecko stopped running, we just recreate the custom tab/web app based on the stored Activity intent data we have available (bug 1352997).
Tab zombification while Gecko is running however remains fully supported, as we continue collecting session history data for all tab types, even if we don't necessarily save it to disk.
Because custom tabs/web apps currently still share a common Gecko browser window with normal tabs, we also have to modify our selected tab tracking logic accordingly, so that selecting one of these special tab types doesn't overwrite the last selected normal browsing tab.
To that effect, we now track the selected tab *ID* in memory and only convert that to a tab index when writing the data to disk. As the ID remains stable while Gecko is running, this makes tracking changes for a sub-group of tabs only easier, as we don't have to watch out for closing tabs of *any* kind affecting the tab index of everything behind them.
Bug 1346008#c3 has some preliminary ideas on how session restoring for custom tabs/web apps could be made to work.
MozReview-Commit-ID: 1q5Jtv0DKrE
--HG--
extra : rebase_source : 150e61f2a205e6bc6ea6cf346de0ba42b1935d13
Closing the currently selected tab will select another tab, which can trigger an activity switch if the tab types differ. We don't want that if we're about to close the activity, as that'll bring that activity into the foreground instead of simply walking back along the activity history stack.
To give an example: Without this patch, closing the last custom tab will select a normal browsing tab, which will trigger an activity switch, so instead of returning to the user's previous activity, pressing back will send us to BrowserApp.
There's one additional catch:
If we change our onDone() behaviour and no longer finish() the SingleTabActivity when exiting (in order to avoid a costly restart of Gecko should the user return to us soon), this means that the activity that has just been exited could be brought back into the foreground via the onResume() codepath.
In that case the mLastActiveGeckoApp-check won't be triggered if no other GeckoApp-based activity was active in the meantime, so we wouldn't reselect/reopen the activity's desired tab, but instead display the tab that was selected when closing the previous tab. Therefore, we track this via an additional flag that is set for this case.
MozReview-Commit-ID: 3jOvBXQUrfo
--HG--
extra : rebase_source : a535fff92c02ef9d711faf6083e9146ed992fc03
Web Apps are single task activities, but Android's task switcher will only ever return the intent that originally created the activity and will never ever update its stored intent for subsequent launches via onNewIntent, so we have to do this ourselves.
Additionally, web apps have some additional logic when being launched via a new intent that checks whether the currently loaded page matches the scope of the web app intent and then resets it if necessary. We now hook up this logic to the new SingleTabActivity wiring.
MozReview-Commit-ID: 9bo4gXbfPNg
--HG--
extra : rebase_source : 3f8cf1e2e96889313ef83ad9ba92b7a36985b82a
This implements the common behaviour for restoring the correct tab when switching to/from custom tab and web app activities. Unlike our normal UI, those activities are basically single tab activities, that is each activity is linked to a certain Gecko tab, with no facilities (bugs aside) for the user to directly load/select a different tab within that activity.
Therefore, here we basically update the selected tab only when the activity is starting up and initially creating its new (or, especially once tab type switching will be implemented, taking over an existing) content tab.
When subsequently restoring, we then check whether the tab is still available. If it is, we select it, if not, we fall back to opening a new tab based on the available intent data.
This also means that we no longer have to finish() the activity on closing so the activity state (finished) matches the tab (closed), which means that we no longer have to prematurely kill Gecko as a side effect of that.
MozReview-Commit-ID: KjFz1qrqWLy
--HG--
extra : rebase_source : 188fd2275083ddb982af806d4660c02caab85bee
The first activity to run triggers Gecko startup and therefore session restore. Since the selected tab stored in the session file is only of interest for BrowserApp, we need to store it somewhere safe if some other activity (e.g. custom tab/web app) starts up first.
This is because currently everything needs to share the same Gecko browser window, so those other activities selecting a tab of their own when starting up will necessarily override session restore's tab selection.
MozReview-Commit-ID: 9GwTDbzgWF9
--HG--
extra : rebase_source : 6ff06fb1e1405201908ade4b04eba54a1a5aa7d5
Currently, we basically take a snapshot of the currently selected tab when pausing an activity and then later re-select that tab ID when switching back from another activity within our application. In practice, this doesn't seem entirely fool-proof, so when switching between our normal UI (BrowserApp) and custom tabs or web apps we can eventually end up with the wrong tab being selected in the wrong activity.
In this part, we'll rip out the current code and replace it by a new implementation for BrowserApp - following parts will then cover custom tabs and web apps.
As BrowserApp is our normal tabbed browsing interface, we can simply track all tab switches for BROWSING-type tabs as they happen, which ensures that our data is always up-to-date.
Because tab IDs remain unique only within the same application session and are reused if we're terminated and then later restart, we need to take additional precautions to make sure we're really selecting the correct tab object - the savedInstanceState can carry even across (OOM-)kills. Therefore we now additionally also store and compare the current per-session UUID to make sure that the tab we're trying to select is really the same one it was when the activity was last running.
For BrowserApp caring about this is less important because on a full startup, the selection behaviour will be overridden by session restore anyway (although we can still hit it if only BrowserApp gets destroyed while Gecko keeps running, or if BrowserApp is launched after some other activity has already loaded Gecko), but it'll be quite relevant for web apps and custom tabs which don't have that benefit.
As it stands, this patch temporarily breaks behaviour around activity restoring for custom tabs/web apps, but tearing the old implementation out in one go was easier and the patch needs to be split somewhere.
MozReview-Commit-ID: I0Tq9XZGvpV
--HG--
extra : rebase_source : a7409f58b8df1f32f74b137513ece1e162605280
That is figuring out whether a homepage has been set (but not caring about the specific page), or else getting the homepage URL with an automatic fallback (to about:home) if no homepage has been set.
MozReview-Commit-ID: D6Uy3A4P4Qc
--HG--
extra : rebase_source : 184240fc79678a2e78d7052635acc4b836fce400
For BrowserApp we want to switch the last selected tab tracking to use tab selection events instead, so we need to register the listener earlier in order to catch the initial selection of the startup tab as well.
MozReview-Commit-ID: F7luIE6oNK
--HG--
extra : rebase_source : d08216a7a73b2f372b2357326e5c9d6de622c4d9
Custom and web app tabs behave as any other externally launched URLs, that is pressing the back button closes not only the activity, but the tab as well when reaching the beginning of session history. Therefore, we should finish the activity in this case (just as the CustomTabsActivity already does), so the next launch runs through the onCreate code path and opens a new tab again.
MozReview-Commit-ID: 14AhWkmb5O7
--HG--
extra : rebase_source : cfed1b6069409efe2444131c41db1ae2e828c43a
Differences to custom tabs:
- We don't have to store the full intent, just storing the manifest path is enough.
- Akin to the LauncherActivity we have to route the request to the correct WebAppActivity instance depending on the manifest path.
We also have to modify the intent handling when GeckoApp is starting up - the intent handling of the GeckoApp + BrowserApp combo requires "nulling" out (by setting it to ACTION_MAIN) the current intent if it's not a fresh intent (e.g. the activity is recreated after having been destroyed or relaunched from the task switcher).
For web apps on the other hand we want to keep the intent around even in those cases, as it contains state we need even later on. Additionally, we want to make use of GeckoApp's startup code for either selecting the tab from the intent or loading a new tab. Therefore we save the launch intent and restore it once GeckoApp's onCreate() has run.
Note that this solution is not entirely correct either, because with this each onCreate() call will open a new tab, even when this is not necessary when only the activity (but not Firefox and Gecko as a whole) had been destroyed. This behaviour will be fixed as part of bug 1352997.
This approach is also a bit different than the one chosen in bug 1351605 for custom tabs, which was independently developed in parallel. Bug 1352997 will unify this, too.
MozReview-Commit-ID: 94uZ3c8CUVD
--HG--
extra : rebase_source : 4997207d048924518870852d40cfc1fed233fab1
This can happen if closing a tab (via the back button) simultaneously also triggered an activity switch (by selecting the parent tab). In that case the tab is closed, but formal selection of the new tab only completes after we've switched activities. At the moment activity switching might trigger an application-background/foreground cycle, which means we could hit the selected tab temporarily being undefined in Gecko.
MozReview-Commit-ID: 6p4cOqj29HX
--HG--
extra : rebase_source : 81db83e79d31cf6398f449bba14a4fb1bdc97810
On tab selection, the Tabs instance now checks whether the type of the tab to be selected matches the currently running activity. If it doesn't, the tab switching is aborted and instead, an intent for the correct activity is sent. When the new activity launches, it finds that the intent also includes a tab ID, which means that instead of opening a new tab we retry the tab selection, which will then succeed now that we're in the correct activity.
Because for custom tabs the launch intent can contain all sorts of customisations, we now have to save the intent when a custom tab is opened for the first time, so that later on, when switching e.g. from BrowserApp back to a custom tab we can use the correct intent to launch the custom tab activity.
MozReview-Commit-ID: KWdkweKBocz
--HG--
extra : rebase_source : 6487f39a697a500d3a3eda505345f72f755bcbb7
These are potentially untrusted external intents, so we should use SafeIntents for interacting with them.
MozReview-Commit-ID: 3nmjg85wbr1
--HG--
extra : rebase_source : 97c54e1dee8fc132aa3bb1d9c42051a4eb330018
Required because later on, we'll need to know if we're in the correct activity for a tab or need to switch activities.
As a follow-up, we can later also hook up our current manual activity tracking from GeckoApplication to this (we most probably won't be able to get rid of the GeckoActivityStatus shenanigans, though).
MozReview-Commit-ID: 5lZrAMsB9Gy
--HG--
extra : rebase_source : 5a8fec92cad15db05063dbb940874615c317c768
-1 is probably not all that mysterious as far as magic numbers go, but still...
MozReview-Commit-ID: zK3P6HeWzK
--HG--
extra : rebase_source : 59530eafb11f68fddb29a53775a394fcd1a08d69
We only want to process the AppEntered/Left message if it actually concerns our currently displayed tab.
MozReview-Commit-ID: EJ8RzRzDNAz
--HG--
extra : rebase_source : 2d05c8131a3b25968b36704647a9041b15599668
Restoring anything other than normal browsing tabs (e.g. custom tabs, web apps) is more involved because those tabs
- don't appear in our normal tabs UI
- are opened in separate activities
- when we're starting up, Android's task switcher might or might not still have available task entries corresponding to such tabs from the last session
Therefore, for now, the session store will simply exclude those kinds of tabs from being saved in the session store data.
Instead of a real restore, if the corresponding tab has been closed or Gecko stopped running, we just recreate the custom tab/web app based on the stored Activity intent data we have available (bug 1352997).
Tab zombification while Gecko is running however remains fully supported, as we continue collecting session history data for all tab types, even if we don't necessarily save it to disk.
Because custom tabs/web apps currently still share a common Gecko browser window with normal tabs, we also have to modify our selected tab tracking logic accordingly, so that selecting one of these special tab types doesn't overwrite the last selected normal browsing tab.
To that effect, we now track the selected tab *ID* in memory and only convert that to a tab index when writing the data to disk. As the ID remains stable while Gecko is running, this makes tracking changes for a sub-group of tabs only easier, as we don't have to watch out for closing tabs of *any* kind affecting the tab index of everything behind them.
Bug 1346008#c3 has some preliminary ideas on how session restoring for custom tabs/web apps could be made to work.
MozReview-Commit-ID: 1q5Jtv0DKrE
--HG--
extra : rebase_source : 150e61f2a205e6bc6ea6cf346de0ba42b1935d13
Similar to some previous commits, we prefer non-throwing constructors
in order to ensure we never lose a reference to an unclosed stream.
InpuStreamReader(..., Charset) is preferred over InputStreamReader(..., String)
since the latter can throw when the String is not a valid Charset.
(In reality we know that our Charset Strings are correct, but the compiler
isn't able to determine that for itself. Moreover, using the preparsed
Charset is more efficient.)
MozReview-Commit-ID: 9z07G3hqPI3
--HG--
extra : rebase_source : 6ed740bf5a1e5296bd2afe5c58b19a43acab0647
The primary issue is that we use a throwing InputStreamReader
constructor. If it throws, then any nested streams will be lost.
We can fix that by using the non-throwing InputStreamReader
constructor (which uses a Charset as the second parameter,
instead of a String which causes an Exception to be thrown
if it can't be parsed)
We also simplify some nested Stream's a little: most of the
Stream constructors don't throw, so there's no harm in not keeping
individual references to those that don't throw - and that
results in less Stream references for us to handle.
MozReview-Commit-ID: 2hyRFGVmGnU
--HG--
extra : rebase_source : 15dd97d28012a017326b01ae8ddc370c7f1ec484
MergeCursor can handle null cursors (and is lightweight), we
don't need to specifically handle each case - which results in simpler
code.
MozReview-Commit-ID: CGwMi9LKYTj
--HG--
extra : rebase_source : 74c0c83ba4e8ea6ca036c24372ee7ff07a1cbc78
On a CLOSED TREE
Style varies across the tree, and this matters as we transition to
Python and moz.build. AppConstants.jsm already uses #ifdef, so this
is consistent with that.
MozReview-Commit-ID: Bal37lqlvjq
--HG--
extra : source : 41d155de1019c0c6c693e2bf46bd1dd7b91d244a
extra : amend_source : 989f6ba2447a2b40d4bc6604241d7986c0d5dd00
nsIFilePicker.displaySpecialDirectory is a string that can be set to TmpD,
Desk, or any other special directory value. The real value of this directory
will be read in the parent process.
We can lower the eslint cyclomatic complexity threshold in some directories without adding eslint suppression comments in any .js source files. We need to specify the complexity rule in accessible/.eslintrc because it doesn't inherit the mozilla/recommended rules. eslint's default complexity threshold is 20.
Also bump the eslint-plugin-mozilla version because we modified the mozilla/recommended rules.
MozReview-Commit-ID: 57T4gAjPH7z
--HG--
extra : rebase_source : 4565abfa722b9459cfb4e006e843da13ed7cffd4
extra : intermediate-source : 658588564c08c9fd5e60633d1457f24087de8570
extra : source : 7e0526e3b943419a80c0cd2fa462cabbf8925eb1
The method Context.getDrawable was introduced in API 21. To be
compatible with Kitkat, should use Resources.getDrawable instead.
MozReview-Commit-ID: 1ZajYWPTVj0
--HG--
extra : rebase_source : d9aa89d3cae5040b861cc6c07f2a2461fab4ce82
This patch replaces the usage of sNextTabParent pointer to store the next
PBrowser parent actor to be used by the next frame loader with the
following information:
* In the case where the content JS has requested a new tab, the ID of the
next TabParent will be stored on the <xul:browser> element.
* In the case where the content JS has requested a new window, the ID of
the next TabParent will be stored on the created nsXULWindow.
This commit adds a robocop test that traverses all the settings
screens except the 'Make default browser' one.
MozReview-Commit-ID: LqWrFL9v877
--HG--
extra : rebase_source : 2e7f5e1887ace438f948b49f6515e1d732ad8aa2
This was just an error that's not obvious on try builds. We were
using local paths ($(DEPTH) expands to ../../../ in
mobile/android/base) and GENERATED_FILES produces targets with
absolute paths.
MozReview-Commit-ID: LDhh6mcgSD6
--HG--
extra : rebase_source : be0cf0c41873871082c640d051ead748746eb78c
Not handling the appropriate configuration changes means that e.g. each rotation destroys and recreates the CustomTabActivity, which'll introduce a slight delay until we eventually repaint the web content.
As for the soft input mode, if we don't specify adjustResize, then the IME might actually simply overlap our window and obscure the end of content if the user has already scrolled down as far as possible.
MozReview-Commit-ID: BzBmIoGbhca
--HG--
extra : rebase_source : 8746621d8fec712e37aac4efdd76da6b0c3b396f
Update tooltool manifests to reference rustc 1.16.0 stable repacks
which include cargo 1.19.0 nightly builds from 2017-04-19 which
support the RUSTC_WRAPPER environment override.
We're shipping with an unstable cargo while this feature makes its
way to release because it is necessary for deploying sccache support
for rust language code in our build and test automation.
MozReview-Commit-ID: Iow2894OPq7
--HG--
extra : rebase_source : f1a8e6cab612714f7b73ca8a14d14cabe9f4aef7
The experiment in Switchboard is "full-bookmark-management", and it's enabled for 100% of the Nightly audience.
MozReview-Commit-ID: EhA0BcouPPn
--HG--
extra : rebase_source : beeddc921a089606d8a752b75c3a0280a1803972
Every single caller of getAppEventDispatcher() and getEventDispatcher()
assumes a non-null return value, so let's make sure we're actually returning
a non-null value. This commit doesn't effectively change runtime behaviour
(any previously NPE crashes will now result in a crash due to IllegalStateException),
however we now at least have an obvious error message in that situation.
In reality, no code should run before onCreate(), so this should realistically
never happen - but we should still check to ensure that is the case.
(This removes 28 infer NULL_DEREFERENCE warnings.)
MozReview-Commit-ID: GhzwKWfkAbD
--HG--
extra : rebase_source : f6b13f590b437ebb63e502f774a70164054ecf7e
Style varies across the tree, and this matters as we transition to
Python and moz.build. AppConstants.jsm already uses #ifdef, so this
is consistent with that.
MozReview-Commit-ID: Bal37lqlvjq
--HG--
extra : rebase_source : 8e4e459a9bdbc3a2cacde728f45e6edecc272e24
That pref isn't set by default, so trying to access it in that case throws a JS error.
MozReview-Commit-ID: 2KIUSztvoXS
--HG--
extra : rebase_source : b2769ba16247db9373c004f152c0e2233fb0652d
* nightly-aurora-id is a copy of nightly
* mobile/android/branding/aurora/ is a copy of nightly with the id and package name changed
MozReview-Commit-ID: 2VT0dHDXEMg
--HG--
extra : rebase_source : 7396a1a7eabb4037fb6936bfc1af10666a677e14
There is a control in menu for reloading or stop-page-loading. Its icon
should be updated per page loading progress.
MozReview-Commit-ID: BNanAQj3xS4
--HG--
extra : rebase_source : 9964c320f3e430583fcdd79034c834af0c115fbc
If change icon via resource id, we should create mIcon as well. And
method `getIcon` should return the drawable which be used currently, but
not generating a new drawable via resource id.
Without this patch, we cannot change icon of a GeckoMenuItem until we
set the icon back. ie.
Drawable icon = menuItem.getIcon();
icon.setLevel(42); // does not work, cause the icon is new instance.
MozReview-Commit-ID: KxW66OgI9po
--HG--
extra : rebase_source : 7b9c1dc13d9b3b214e5dcb3ee366dca7e60f3fe7
Android shows a dialog box when it detects app crashing. OOP decoder needs to hide that from user to resume playback gracefully.
MozReview-Commit-ID: 3cE3GiHAuQk
--HG--
extra : rebase_source : 67bec5dfda1e878fa7dea877ef58d485b4e17944
Add the necessary XPCOM components to handle prompts for GeckoView. The
JS code mostly package the prompts into GeckoView:Prompt events, and send
them to the Java side if in parent process, or to the parent process if
in child process.
Add an event listener for the GeckoView:Prompt event, which JS code will
use to sent over prompt requests and to receive prompt results. Both
global and per-GeckoView listeners are required because we may not know
the origin GeckoView for certain prompts, so some prompts will not have
an associated GeckoView. This is also the reason for having a static
default PromptDelegate in additional to an instance per-GeckoView
PromptDelegate. All prompts without associated GeckoViews are sent
directly to the default PromptDelegate.
Add a PromptDelegate interface that implements possible prompts shown by
a GeckoView application. All prompt methods include a callback parameter
for the implementation to call back to GeckoView with results from the
prompt.
CustomTabsActivity use standard ActionBar, so we can easily use action
mode for text-selection.
MozReview-Commit-ID: CSu0d24Z7dt
--HG--
extra : rebase_source : 9040e515a6208459aa5b0b7470e491c7474fe4ec
To create new interface ActionModePresenter, a presenter could to
operate action-mode.
For pre-marshmallow Android version, we use ActionBar to provide UI
action for text-selection. Therefore BrowserApp will implement this
presenter for text-selection.
MozReview-Commit-ID: GdLB3ke2pYe
--HG--
extra : rebase_source : 5467a7d514810fa846fefcf37e5eb2f55a643c3f
We want to reuse ActionBarTextSelection in more activities, so remove
custom classes from it, to make it easier to interactive with general
Andorid classes.
To achieve that
* Let ActionModeCompat to be a subclass of ActionMode
* Get rid of GeckoMenu
BrowserApp is the only one consumer for ActionModeCompat, and it do
understand the class type. We could move animateIn to it safely. After
doing this, TextSelectionActionModeCallback could become a general
ActionMode.Callback.
MozReview-Commit-ID: 7FTwDTe1JYG
--HG--
extra : rebase_source : cf7cbba40745bbfbd34099f238c904bb4d3c6438
This commit also cleans up extraneous stream closes: these streams
are closed in finally, so we don't need to also clean them up in
the main try block body.
MozReview-Commit-ID: EXxlmmtqvyq
--HG--
extra : amend_source : 72ad8cb816202e8e3f234157bae092cea004d34a
That helps usability in the following scenario:
1) Open more tabs than will fit on screen in the tabs tray (and fill the last
row with tabs if the tabs tray is in a grid mode);
2) Scroll to the bottom;
3) Open one of the last visible tabs, and from that open tab open a new
background tab (e.g. long click on a link in a page and choose "Open in new
tab");
4) Reopen the tabs tray.
With the fix, the new tab will be visible at the bottom of the list, whereas
previously in list mode it was not visible at all, and in grid modes only the
top of the title was visible.
(Bug 1299905 would make this sort of situation more widely applicable.)
This patch also has the side effect of scrolling the selected tab to the top of
the tabs tray on each rotation (previously it was just scrolled into view).
MozReview-Commit-ID: 4MKY7P1Mihk
--HG--
extra : rebase_source : a00776803b199a949ba598805e79a71fde82e2f3
Other events in browser.js are all lower case letter, also change these two to make them consistent.
MozReview-Commit-ID: LkzYUo6OrEA
--HG--
extra : rebase_source : 6853dc40c68c0939d7e318b3a1e88c39495d0648
We could register media control related event after the tab has active media.
But we still need to register "audioFocusChange" in the beginning, because it
affect every tab even the tab has no active media.
MozReview-Commit-ID: ErIBUobnxbg
--HG--
extra : rebase_source : bdc8070f2f2a81f847ebb8e0ec87f6efeb86eb80
Incoming records might be missing the dateAdded field, and so we perform some pre-processing:
- during reconciliation, dateAdded is set to the lowest of (remote lastModified, remote dateAdded, local dateAdded)
- during insertion, if dateAdded is missing it is set to lastModified
Whenever we modify dateAdded for a record during sync, we also bump its lastModified value. This will trigger an
upload of this record, and consequently a re-upload by clients which are able to provide an older dateAdded value.
It is possible that this might cause conflicts on other devices, but the expected likelyhood of that happening is low.
MozReview-Commit-ID: 3tDeXKSBgrO
--HG--
extra : rebase_source : 26cb13838df7a4adb6d4fe3c51f0ecf3fd2eda95
Add the aarch64-linux-android libstd to the android-cross
repackage of the upstream rust 1.16.0 stable builds.
MozReview-Commit-ID: gmZL7QCodQ
--HG--
extra : rebase_source : dc4072c3214188195aa6abda939d550df4e617d9
I'm taking another kick at this. Since glandium's negative review of
older patches a year ago, generate_build_config.py landed (with your
r+, gps). These patches extend that mechanism to generate
AndroidManifest.xml. This sets the stage for that.
This is all in service of Bug 1355625, which will need the
generate_build_config.py extension point to do things that the
preprocessor cannot handle: generating Java code, copying resource
files, and merging resource XML declarations.
MozReview-Commit-ID: AcyC3CBMQl1
--HG--
extra : rebase_source : c379b07de4b9f9b4bfe53e6a0adac13f08a71c73
This solves 2 issues:
- We keep a reference to Tracker (which is implemented by a Service) forever,
which is solved by keeping a WeakReference.
- We kept another reference to the Service by using it as a Context - we can
avoid that by using the ApplicationContext instead.
MozReview-Commit-ID: 6UNSkZx12an
--HG--
extra : rebase_source : bfb50d02246e4377ef23179747987bc82731fd54
Andrzej Hunt
Wes Kocher
Jan Henning
Carsten "Tomcat" Book
Sebastian Hengst
Michael Kaply
Alexandre Poirot
Edouard Oger
Nevin Chen
Nick Alexander
Andrea Marchesini
James Willcox
Randall Barker
Dale Harvey
Mike Conley
Chris Peterson
Iris Hsiao
Julian_Chu
Ehsan Akhgari
Eugen Sawin
brainbreaker
Jing-wei Wu
Ralph Giles
Munro Mengjue Chiang
Tom Klein
Matthew Wein
Sylvestre Ledru
John Lin
Jim Chen
Alastor Wu
Shane Caraveo
Grigory Kruglov