The new names make it clearer that these actions apply to just one thread.
- profiler_sleep_start() --> profiler_thread_sleep()
- profiler_sleep_end() --> profiler_thread_wake()
- profiler_is_sleeping() --> profiler_thread_is_sleeping()
- GeckoProfilerSleepRAII --> GeckoProfilerThreadSleepRAII
- GeckoProfilerWakeRAII --> GeckoProfilerThreadWakeRAII
Currently, we use alias NS_VK_* for WidgetKeyboardEvent::mKeyCode. Similarly, we should create alias enum for nsIDOMKeyEvent::DOM_KEY_LOCATION_*. Then, we can reduce the length and avoid to include nsIDOMKeyEvent in some cpp files.
MozReview-Commit-ID: 5cs4zQ061Lc
--HG--
extra : rebase_source : e6a6edd27718b9e3d4a40b07902d029791876999
There are still a lot of crash due to failing to get following WM_CHAR message. Almost half of them are, we found a WM_CHAR message but it's gone at removing the message from the queue.
Although, we're still not sure what happen actually. It could be possible if somebody hooks PeekMessage() or something. Then, we can assume that the found message isn't necessary for the user because it must be removed by somebody when it became unnecessary or is handled.
This patch mark a new bool flag, mCharMessageHasGone, as true in such case. Then, NativeKey will dispatch keypress events without following char messages and mark the event as consumed.
MozReview-Commit-ID: mporX1sihC
--HG--
extra : rebase_source : a1badc205a99efd803de624d24b69e911f81d308
NativeKey::GetFollowingCharMessage() may remove a char message which is different from previously found message in the queue because hacky keyboard layout or utility can overwrite the wParam when it's removed from the queue.
Now, we should assume that newer message, i.e., actually removed from the queue, is the expected message by the user. See bug 1336028 comment 0 for the actual scenarios which are collected by crash reports.
https://bugzilla.mozilla.org/show_bug.cgi?id=1336028#c0
MozReview-Commit-ID: 9ZgukHH1vfi
--HG--
extra : rebase_source : 15559e62882f97d5062703e2308fa1c22016f340
Currently, NativeKey::GetFollowingCharMessage() tries 5 times to remove found char message from the queue. It was enough when we found this issue at developing Metrofox.
However, this hack is not enough for some odd keyboard layouts because we see some crash reports which gives up to remove a char message from the queue because 5 WM_NULL messages are returned.
For preventing this crash, we should check if there is the message which is trying to remove from the queue when NativeKey receives WM_NULL. Then, when there is no key message in the queue or next key message becomes non-char message,, NativeKey should dispatch consumed keydown event because we can assume that the key operation may have already been handled or canceled. Otherwise, NativeKey should retry to remove the message again (until 50 times!, it's just enough big magic number, there is no concrete reason).
MozReview-Commit-ID: 1c6Y4OoQdrP
--HG--
extra : rebase_source : 2ad588d0513741ff6a58be6f523cf59d8deea151
I think that when PeekMessage(PM_REMOVE) failed to remove a char message but next key message is still a char message, it may be possible that the odd keyboard layout or utility hook only PeekMessage(PM_NOREMOVE) and GetMessage(). If so, we can explain what occurs in this case.
I'm still not sure this fixes the case of bug 1336322 comment 0, but we should try to do this because I don't have better idea.
MozReview-Commit-ID: CxoO24n167t
--HG--
extra : rebase_source : c00b86166a345eec18fa2de74698f6e8859364b8
This patch depends on bug 1336080.
When PeekMessage() fails to remove found char message, NativeKey::GetFollowingCharMessage() tries to check next key message in the queue again. Then, when next key message becomes non-char message, such as WM_KEYDOWN or WM_KEYUP, the char message must be removed by odd keyboard layout or something. Similarly, when next key message is a char message but it's caused by different key, the found char message must be removed by one of them too.
So, in these cases, NativeKey::GetFollowingCharMessage() should treat the key operation is already handled or canceled by the odd keyboard layout or somebody else. Additionally, in the latter case, following char message should be handled as orphan char message(s) as usual.
MozReview-Commit-ID: 8ahs8I0HUQ2
--HG--
extra : rebase_source : 563efc0e65c1d400a32cb0ceec94eb56ad0aa1c5
When NativeKey::GetFollowingCharMessage() tries to remove a char message from the queue, the message might be changed by odd keyboard layout or something. In such case, if the new char message is also caused by same physical key, the char message must be overwritten. Then, we should take the new char message instead.
Note that this patch saves original found char message into kFoundCharMsg and it's logged by each points for indicating if this case has occurred.
MozReview-Commit-ID: HAduq8sfwFt
--HG--
extra : rebase_source : c8980c7fa019fc3e0f249b4506fa572e81f4a1e8
The machinery for suppressing the displayport during live resizes
was using the Observer service. However, in the case of multiple
browser windows, this meant that all the open browser windows would
have their displayport suppressed if *any* of the browser windows
was being resized. This was mostly ok, as the displayport suppression
would be turned off once the resize ended. However, the code to
kick off a repaint with the unsuppressed displayport would only get
triggered on one of the windows (whichever happened to process the
unsuppress message last).
This patch stops using the Observer service for the implementation
machinery, and instead locates the active TabParent of the relevant
nsWindow, and invokes the displayport suppression directly on that.
This fixes the repainting bug and also avoids unnecessarily
broadcasting the suppression/unsuppression notification to windows
that don't neccessarily need it.
MozReview-Commit-ID: LBHOgOW9KUp
When NativeKey crashes by itself, it means that we detect an impossible situation in usual environment. In such case, active 3rd party's keyboard layout or something other utility may hook API and returns odd result to us.
For investigating the cause and deciding what we should do in such cases, we should collect active keyboard layout name via crash reports.
MozReview-Commit-ID: HYRj24GwDHZ
--HG--
extra : rebase_source : 5f01c2a3b36179a61dc00eebd4de6f05596d217b
As of bug 1325299, WINVER is always >= 0x0601 (Windows 7).
MozReview-Commit-ID: Hw5FcEdP0os
--HG--
extra : source : 239400b39f806592a621473ac3a6dd79b238e725
This patch makes sure content processes update their cleartype settings, as well as making sure Moz2D's idea of the ClearType settings are in sync with those of Thebes. If the two differ this can cause graphical glitches.
MozReview-Commit-ID: 94arUnBWoUy
--HG--
extra : rebase_source : d74b702fc63c019ce1c30bdc741ea3ed6da457cd
This patch adds a new non-DOM event type, "mousetouchdrag". The name is horrible, I
know. The "mouse" comes from the fact that it's a WidgetMouseEvent, and the
"touchdrag" comes from the fact that this event is fired at the start of a touch
gesture for drag-and-drop. Right now this event is only fired from the Windows
widget code, when we receive a touch-source doubleclick event from the OS. This
event is sent to us from the OS when it detects the sequence "touchstart, touchend,
touchstart" within certain time/distance constraints. Eventually we may detect
similar gestures for other platforms in the APZ GestureEventListener and dispatch
the "mousetouchdrag" event for those as well.
The only effect of this event is that it begins tracking a drag gesture in the
EventStateManager. Subsequent touchmove events can begin the actual drag-and-drop
operation by calling ::DoDragDrop. See the discussion in bug 1147335 for some
important caveats about DoDragDrop and how it only works with left-mouse-button
events (real or synthetic).
MozReview-Commit-ID: bGyOk6dRoJ
This patch changes it from |NS_IMETHOD| to |virtual nsresult| because some
callsites are checked and some aren't.
--HG--
extra : rebase_source : dd98266bce0a7583863908b6f04729a6e403b721
This patch changes it from |NS_IMETHOD| to |virtual nsresult| because some call
sites are checked and others aren't.
--HG--
extra : rebase_source : 6723b9db709d1506dd394b1e85572309c1c2e2cf
This patch changes one from |NS_IMETHOD| to |virtual nsresult| and the other to
|virtual void|.
--HG--
extra : rebase_source : 55af71c01dc75d6bf7c63191e9cfabc9f5368ffa
This patch changes it from |NS_IMETHOD| to |virtual void|. The return value was
only checked in one low-value assertion and one other place where the check had
no useful effect (in nsCocoaWindow::HideWindowChrome()).
--HG--
extra : rebase_source : f6671e9e0e10ee18fb32f8b1c83f1e64c3d97e67
This patch changes it from |NS_IMETHOD| to |virtual void|. The return value was
only checked in one low-value assertion so I decided it wasn't needed.
--HG--
extra : rebase_source : 3523d9a086cf98c40d237d777f5dd471af0d7465
I did my best to remove as much stuff as possible in this patch. The starting
point was to remove all the IsVistaOrLater() and IsWin7OrLater() calls, but I
also grepped for various strings and found some other removable stuff that way.
I may have still missed some things.
Notable things done by this patch.
- It removes numerous blocklist entries.
- It removes CanComputeVirtualKeyCodeFromScanCode(), because it's always true
now.
- It removes ShowXP{Folder,File}Picker(), even though these were available as
fallbacks on Vista+. The "when platform is built without the longhorn SDK"
condition in the comment above nsFilePicker::ShowXPFolderPicker() sounds like
it won't ever happen any more.
- It removes the config.trim_on_minimize preference. This requires adding a
bool sHaveInitializedPrefs variable; previously the lack of pref
initialization was indicated by the tri-state sTrimOnMinimize variable having
the value 2.
Notable things *not* done by this patch.
- ClearThemeRegion() still exists. The comment suggests that it is XP/Vista
only, but the code suggests otherwise. jimm thinks the comment is wrong.
- The comment in WinWakeLockListener::Callback() suggests that the StartTimer()
call is no longer needed to block the screen saver. I'm uncertain about this
and so I think it's best left to a follow-up.
--HG--
extra : rebase_source : f46645907d237423fd6115ab1b4725b023a0dce3
The machinery for suppressing the displayport during live resizes
was using the Observer service. However, in the case of multiple
browser windows, this meant that all the open browser windows would
have their displayport suppressed if *any* of the browser windows
was being resized. This was mostly ok, as the displayport suppression
would be turned off once the resize ended. However, the code to
kick off a repaint with the unsuppressed displayport would only get
triggered on one of the windows (whichever happened to process the
unsuppress message last).
This patch stops using the Observer service for the implementation
machinery, and instead locates the active TabParent of the relevant
nsWindow, and invokes the displayport suppression directly on that.
This fixes the repainting bug and also avoids unnecessarily
broadcasting the suppression/unsuppression notification to windows
that don't neccessarily need it.
MozReview-Commit-ID: LBHOgOW9KUp
--HG--
extra : rebase_source : 9e57054b22c58f5fcf815dfb3074a7201102fb4d
This patch makes sure content processes update their cleartype settings, as well as making sure Moz2D's idea of the ClearType settings are in sync with those of Thebes. If the two differ this can cause graphical glitches.
MozReview-Commit-ID: 94arUnBWoUy
--HG--
extra : rebase_source : d74b702fc63c019ce1c30bdc741ea3ed6da457cd
This patch changes it from |NS_IMETHOD| to |virtual void| because every
implementation of these functions always returns |NS_OK|.
--HG--
extra : rebase_source : 07ee29c514bf35b97d7195c53bb5b9220d1ef961
This patch changes them from |NS_IMETHOD| to |virtual void| because every
implementation of these functions always returns |NS_OK|.
--HG--
extra : rebase_source : 6207df5a46aeb6b8aaa0f697447a51bc6a6dc366
This patch does the following.
- Removes the return value, because none of the call sites check it.
- Removes the empty implementations from the android nsIWidget instance,
because it can use the nsBaseWidget one.
--HG--
extra : rebase_source : 0791d3cb05907d6b41879549b52f3a33018abf45
This patch removes its return value, because none of the call sites check it
except for one non-vital assertion.
--HG--
extra : rebase_source : 3471c4e22394b8a05c6708d0f8469686ffad9814
This patch does the following.
- Removes the return value, because none of the call sites check it.
- Removes the empty implementations from several nsIWidget instances, because
they can use the nsBaseWidget one.
--HG--
extra : rebase_source : a1a04193bc3940f1468c7c235f6d6e0341d0f1c2
Specifically: OnDefaultButtonLoaded, AttachNativeKeyEvent, BeginMoveDrag,
BeginResizeDrag, GetAttention. These are all fallible functions whose result is
always checked.
The patch also moves some trivial function definitions from nsBaseWidget.cpp to
nsBaseWidget.h, and removes the android BeginResizeDrag() because it can
use the nsBaseWidget one.
--HG--
extra : rebase_source : ef32a41b547bcbc21f7df0043f683307470b136e
When mWidget was already destroyed, anybody shouldn't dispatch WidgetEvent on it. Therefore, NativeKey::InitKeyEvent() has MOZ_CRASH() for detecting such dangerous bug and some users hit it.
Each message handler of NativeKey should check if mWidget has already gone.
Ideally, nsWindow shouldn't create NativeKey and try to handle the message with it. However, using NativeKey's message handlers can put some information to the log. Therefore, this patch doesn't touch nsWindow.
MozReview-Commit-ID: 4k5VfaKHPgG
--HG--
extra : rebase_source : 4269847fbdf5daa66244ce924ddc54feb5c6cd01
This completes the migration of code from the github branch to the graphics
project repo. At this point all webrender-related code should be disabled
unless --enable-webrender is provided in the mozconfig.
MozReview-Commit-ID: Dea8rxM6UPL
After click events with button 2 or 3 are fired, fire auxclick, a new
event intended to represent a non-primary mouse click. Because this
event, based on the design examples and blink's implementation, is
intended to be used with content listeners, always dispatch on content
listeners--not just those that force all events to be dispatched (i.e.
document/window). This diverges from the behavior of our click events
from non-primary buttons.
Eventually, we hope this will replace click events for non-primary
buttons. For now, leave those events for compatibility reasons.
Additionally, add handling of this new event, where necessary.
MozReview-Commit-ID: 8osozM4h6Ya
--HG--
extra : rebase_source : 558261dd0d0b9241efa84ca168c50455850af03a
We will use the new type for the generated IPDL message handler
prototype to make sure correct error handling method is called.
MozReview-Commit-ID: AzVbApxFGZ0
Add the set of plugin process PIDs to PluginProcessParent and, when attempting to reparent plugin windows in the chrome process, validate that those windows originated with the plugin process (by checking the window's PID against the set in the PluginProcessParent).
When the first time user clicks download panel popup to hide the drop marker popup, Windows fires WA_ACTIVATE with wParam includes WA_CLICKACTIVATE to the download panel. In that case the popupWindow is the drop marker. We shouldn't roll up popups by handling WA_ACTIVATE since we'll handle the rollup behavior with WM_LBUTTONDOWN message.
MozReview-Commit-ID: 43jCgdBjjUN
--HG--
extra : rebase_source : 371de468252e7716e2ffe30520939650f76a4222
When we jump to fullscreen, the OS sends a WM_MOUSELEAVE, which we turn into a eMouseExitFromWidget. The eMouseEnterIntoWidget was previously only sent when the mouse moved into the widget, which required the mouse to move. When entering fullscreen, we want the eMouseEnterIntoWidget to happen right away.
Currently, KeyboardLayout doesn't support chained dead keys because probably, the initial developer didn't expect there are such keyboard layout. Additionally, if we'd try to handle them with KeyboardLayout, it'd need to create too big and too complicated table at loading such keyboard layout. It's really nightmare. Therefore, this patch takes different approach.
Currently, when WM_(SYS)KEYDOWN is received, KeyboardLayout (and NativeKey) respects following WM_(SYS)CHAR. Similarly, this patch makes KeyboardLayout respect WM_(SYS)DEADCHAR when it handles dead key. If WM_(SYS)KEYDOWN is followed by WM_DEADCHAR, that means that the key press is in a dead key sequence and not finishing the existing dead key sequence. Therefore, when WM_(SYS)KEYDOWN is followed by WM_(SYS)DEADCHAR, KeyboardLayout activates dead key sequence.
For supporting dead key chain, this patch makes KeyboardLayout::mActiveDeadKey and KeyboardLayout::mDeadKeyShiftState arrays. When dead keydown message is received, KeyboardLayout appends an item to each of them. (I.e., when the array is not empty, it's in a dead key sequence.)
When WM_(SYS)KEYUP is received, KeyboardLayout checks if it's in mActiveDeadKey. If it's included in the array, it initializes NativeKey as a dead keyup event.
Otherwise, when non-printable key (probably) is received in a dead key sequence, KeyboardLayout doesn't handle it as a part of the dead key sequence. For example, a modifier key may be pressed for next key. (Even if the keyboard layout maps text input to a non-printable key, we can ignore them because such key's KeyboardEvent.key value should be decided only with the virtual keyboard.)
MozReview-Commit-ID: 9n8B0YYuKCO
--HG--
extra : rebase_source : d18ca896829274d35cc8b7744c5e1645a9e78784
This is the first step in using these functions without having a
LayerManagerComposite at all.
MozReview-Commit-ID: 2zkuB7Ox4Ut
--HG--
extra : rebase_source : b23988275f5851a2fd30bd3e8a9931107a224c66
When using the InjectTouchInput API on Windows, the API requires that the caller
keep providing input frames (by calling the API function) at least every 100ms.
If the caller fails to do so, Windows can return an ERROR_TIMEOUT and throw
away the touch sequence. In some tests, it is hard for us to make this guarantee,
because we need to wait for other events between the touchdown and touchup. For
these tests, we can use the widget-level touch injection code that we have as
a fallback for the OS-level touch injection code. The widget-level touch
injection is less representative of real-world usage but allows us to bypass
the timeout problem.
MozReview-Commit-ID: EoVUSZmERUw
--HG--
extra : rebase_source : 4f7ca1a1e6da4479d51526e8f132f5cb23fceb49
When PC supports table mode, TextInputFramme.dll is loaded and it can be used for TIP.
When creating new TextStore object, selection might be nothing yet on e10s. At this time, GetSelection will return E_FAIL since selection data isn't received yet. If GetSelection returns error during SetFocus, TextInputFrame.dll will crash.
So we set temporary selection to avoid crash.
MozReview-Commit-ID: HyVSwvhXGJh
--HG--
extra : rebase_source : 9e4838ffc5c8d8cf0e67685c6c1da09ecba6c7a9
extra : amend_source : dda79c9380ee34c82a611fc6a6691cbe63aec63c
Add the set of plugin process PIDs to PluginProcessParent and, when attempting to reparent plugin windows in the chrome process, validate that those windows originated with the plugin process (by checking the window's PID against the set in the PluginProcessParent).
--HG--
extra : rebase_source : f12fabb958d64def6f57ebbbccc39f8ef47ad9f4
Since aUri is nullptr, Firefox will crash on shutdown.
MozReview-Commit-ID: E5ENWsjK7Px
--HG--
extra : rebase_source : d52a301ec0d313f303a98f1d463f9f1120ea44c8
This converts |nsITransferable.flavorsTransferableCanExport| and
|nsITransferable.flavorsTransferableCanImport| to return a |nsIArray|.
|nsIFormatConverter.getInputDataFlavors| and
|nsIFormatConverter.getOutputDataFlavors| are updated as well.
Similarly, NativeKey is a stack class and mFollowingCharMsgs which stores following char messages of WM_(SYS)KEYDOWN should be AutoTArray for preventing to use heap at handling inputs with usual keyboard layout.
5 is enough size for handling usual keyboard layout because we support only 5 or less characters per dead key sequence.
MozReview-Commit-ID: IphcIOmPW0C
--HG--
extra : rebase_source : 74ce6f9fef73df4b9bbccbbdd713470ff7357889
Fortunately, UniCharsAndModifiers instances are only in stack. Therefore, we can make it a stack class and use nsAutoString and AutoTArray for not using heap at handling inputs from usual keyboard layouts.
MozReview-Commit-ID: 9ZPbdjGst64
--HG--
extra : rebase_source : 06a21c20575747591c6bf1a55dff7e6e38884333
Now, we have an security issue. mCommittedCharsAndModifiers may be initialized with multiple WM_(SYS)CHAR messages. However, if it's generated by odd (or malicious) middleware, mCommittedCharsAndModifiers may be overflown because it has only fixed array. For fixing this issue, first, we should hide the members for making the users not depend on the design of UniCharsAndModifiers.
This patch changes UniCharsAndModifiers to a class and hiding mChars and adding |CharAt() const|.
MozReview-Commit-ID: 5EjrIhmCdE4
--HG--
extra : rebase_source : a3dc68998f5f177582addd8587c4da86b2d17b3b
This patch creates NativeKey::DispatchKeyPressEventsWithRetrievedCharMessages() for dispatching eKeyPress event with mCommittedCharsAndModifiers when it stores following printable WM_(SYS)CHAR messages.
Using loop for dispatching eKeyPress event for every WM_(SYS)CHAR message is wrong because WidgetKeyboardEvent::mKeyValue is initialized with mCommittedCharsAndModifiers and it causes TextEventDispatcher dispatching multiple eKeyPress events at every call of MaybeDispatchKeypressEvents(). Therefore, if mKeyValue is "^^", eKeyPress event is dispatched 4 times --for the first message, eKeyPress events are fired for each "^" and for the second message, eKeyPress events are fired again for each "^"--. Therefore, when it handles WM_(SYS)KEYDOWN and it causes inputting one or more printable characters, it's the easiest way not to use HandleCharMessage().
The new method calls TextEventDispatcher::MaybeDispatchKeypressEvents() only once and it requests to call the callback method with new argument of MaybeDispatchKeypressEvents() when it needs to dispatch 2 or more eKeyPress events. Then, NativeKey::WillDispatchKeyboardEvent() can set each eKeyPress event to raw information of the message and proper modifier state.
With this change, we can dispatch multiple eKeyPress events with retrieved WM_(SYS)CHAR message information rather than retrieved information from active keyboard layout. Therefore, NeedsToHandleWithoutFollowingCharMessages() doesn't return true even when mCommittedCharsAndModifiers stores two or more characters.
FYI: there is a bug in test_keycodes.xul. That is, Alt+'A' of Greek keyboard layout should cause WM_SYSCHAR with a corresponding Greek character but ASCII characters are specified. Therefore, this patch includes the fix of these bugs
MozReview-Commit-ID: JVm7ZJVug0O
--HG--
extra : rebase_source : 414ecbe2c01c53f294d1346414b1a289aa0abfe8
First, mCommittedCharsAndModifiers should be initialized with following char messages because the messages could be different from the information of current keyboard layout.
So, this patch guarantees that mCommittedCharsAndModifiers are same as the user expected when there is one or more WM_CHAR or WM_SYSCHAR messages.
MozReview-Commit-ID: I5Ack0xccoL
--HG--
extra : rebase_source : e4c7af75fd200f30ec52b53dc05f49ae8887c6f0
This is a simple mistake and blocks following patchs' automated tests.
For example, when Alt+Shift+foo doesn't cause text, this returns false even though it should return true.
MozReview-Commit-ID: 91L33vZhouT
--HG--
extra : rebase_source : be7d4e7ad670c1b03e6497c1c313c187ece80c1c
Now, NativeKey::HandleCharMessage() has almost same code, one is for dispatching eKeyPress event for non-printable keys or printable keys when one of Alt or Ctrl key is pressed, the other is for printable keys when Alt or Ctrl key is pressed.
The difference of them is, the former block removes Alt state and Ctrl state for handling AltGr key. When AltGr key is pressed, both Alt and Ctrl state are true. However, EditorBase treas keypress events whose altKey or ctrlKey is true as non-printable key event. Therefore, we need to set these modifier state to false when AltGr key is pressed and the key causes some text.
Note that as far as we know, when a key press with AltGr doesn't cause any characters, WM_CHAR isn't generated. Therefore, we don't need to check with complicated logic if the key event is actually inputting a character.
MozReview-Commit-ID: BRNWfICvkSm
--HG--
extra : rebase_source : 3b8a2aaeb4c53be1567f7a8d17dfef1af90406dd
Current shortcut key handling is really difference from what we did before struggling with "key hell". Therefore, remaining hacks for charCode in NativeKey::HandleCharMessage() are not necessary because they are for old code.
MozReview-Commit-ID: 3hvsBOiJ6VV
--HG--
extra : rebase_source : 7387fc89930f9b15d5d01612eb4a7a5726924bcd
This patch makes NativeKey::HandleCharMessage() stop dispatching eKeyPress event when the message is inputting a control character. NativeKey::HandleCharMessage() runs following cases:
1. WM_KEYDOWN followed by a WM_CHAR message whose wParam is not a control character causes inputting printable characters.
2. WM_CHAR message is received without WM_KEYDOWN message.
So, when HandleCharMessage() is called for a control character, it's unusual case. E.g., another application sends only WM_CHAR message with a control character.
On the other hand, Gecko is the only browser which dispatches "keypress" event even if pressed printable key doesn't cause inputting any characters. And such "keypress" event is used for shortcut key handling and some default action handling. So, even if we stop dispatching eKeyPress event from HandleCharMessage(), it shouldn't affect most users.
Note that this patch does NOT change the behavior when the user inputs a control character with usual keyboard layout such as Ctrl+A of en-US keyboard layout because DispatchKeyPressEventsWithoutCharMessage() dispatches eKeyPress event in such cases.
This patch also adds a lot of tests with Ctrl or Alt state for detecting regressions.
MozReview-Commit-ID: KUNqTp7RDSc
--HG--
extra : rebase_source : f91e37b0b82a8e8a95444a08f6d3101f14fadc50
Currently, Enter and Backspace keys are handled without following WM_(SYS)CHAR message. However, older code needs hack for them for avoiding conflict with Ctrl+J vs. Ctrl+Enter, etc.
So, we can get rid of them now. And when a keydown causes inputting a control character, NativeKey should handle it with keyboard layout (i.e., without following char message(s)).
MozReview-Commit-ID: 6bVuK0BzFbx
--HG--
extra : rebase_source : 08ff45c1990ef8f3ed7703c69b2dc22e5f1dd6f5
Currently, NativeKey::HandleCharMessage() is only a public method and it takes any char message. However, when it's called outside of NativeKey, it should work only with NativeKey::mMsg.
Therefore, we should make current HandleCharMessage() a private method and create new overload method which doesn't take MSG as an argument.
MozReview-Commit-ID: LowV2FUmR3U
--HG--
extra : rebase_source : 271c61515752cf1ea56cf12c4f7ef6f1a90c9cac
NativeKey shouldn't include characters which are provided by WM_SYSCHAR message or WM_DEADCHAR message into mCommittedCharsAndModifiers.
MozReview-Commit-ID: Ax1BmO5wTy0
--HG--
extra : rebase_source : 5d7d1735a783213f7c6a47cca0cadb1d4c5104c0
For consistency with IsPrintableCharMessage(), IsFollowedByNonControlCharMessage() should be renamed to IsFollowedByPrintableCharMessage().
MozReview-Commit-ID: CBJFPO4FZej
--HG--
extra : rebase_source : f5d677743be35a3bb5fca35e7658e907aa46dbcb
Currently, NativeKey::IsFollowedByNonControlCharMessage() returns true only when the first char message is a printable char message. Although, I don't know actual cases coming printable WM_CHAR message after non-printable char message, i.e.,
1. WM_SYSCHAR or WM_DEADCHAR
2. WM_CHAR for a printable character
or
1. WM_CHAR with a non-printable character (a control character)
2. WM_CHAR with a printable character
, we should make it return true because when one or more characters are being inputted, we should ignore non-printable char messages and handle printable char messages in the path handling text input.
MozReview-Commit-ID: 1v7v5mCRFCP
--HG--
extra : rebase_source : f82f7b77376450168bad34be031164ecf7338621
Currently, NativeKey::IsPrintableCharMessage() returns true if given message is WM_CHAR or WM_SYSCHAR. However, WM_SYSCHAR never causes inputting any character and even if WM_CHAR has a control character (i.e., non-printable character), it returns true.
MozReview-Commit-ID: IoU5F06WImz
--HG--
extra : rebase_source : c48f424f3d2960e6e9ceaa6d2fb09952ca634c3f
When key combination is reserved by the system, web apps shouldn't be able to consume the key events. In such case, we've decided that we never expose the key events in web contents (including chrome contents). Therefore, NativeKey stops dispatching keyboard events only for Alt+Space.
However, new code of the fix of bug 1300003 always consumes WM_SYSCHAR which follows WM_SYSKEYDOWN of Alt+Space. This is the cause of bug 1305943.
For fixing this bug, NativeKey should have a helper method, IsReservedBySystem(), and when it returns true, it should do nothing when Handle*Message() is called and should not consume following WM_SYSCHAR messages at handling WM_*KEYDOWN.
Unfortunately, it's impossible to test this regression because nsDOMWindowUtils::SendNativeKeyEvent() may call nsIWidget::SynthesizeNativeKeyEvent() asynchronously. See <https://dxr.mozilla.org/mozilla-central/source/dom/base/nsDOMWindowUtils.cpp#1105-1108>. Therefore, it cannot return if it's consumed.
MozReview-Commit-ID: 9ABh2rYNkFs
--HG--
extra : rebase_source : 7416e45babccce3af795dc523f46dc00fdddc6c7
We usually declare class members with following order:
1. public members
2. private members
3. friends
However, current KeyboardLayout is declared with completely opposite order. Let's use usual order for preventing mistakes.
MozReview-Commit-ID: LwOcEUbJzes
--HG--
extra : rebase_source : 828b5d14f1b38f46e4ae5244d15de68c4db6785c
Currently, checking if it's in dead key sequence directly refers mActiveDeadKey. However, this isn't clear for most developers. So, let's create a helper method, IsInDeadKeySequence(), and wrap the nonintuitive check.
MozReview-Commit-ID: 7qTer9R8Gfs
--HG--
extra : rebase_source : 6ecb20cc3f5e28cfcf41fb33df8603785288bdda
For preventing wrapping long lines, old KeyboardLayout::InitNativeKey() uses two variables |virtualKey| and |isKeyDown| which are never modified. However, they may be not clear for some developers where they came from. Additionally, preceding patches reduced a lot of users of them and indent level. Therefore, even if we remove these variables, we don't need additional line breaks in most cases. So, removing them is better for easier to understand.
MozReview-Commit-ID: 680bYVINPAE
--HG--
extra : rebase_source : 15f4398072ccfe659fc6d2ae95a3f13261efa5af
This patch creates KeyboardLayout::MaybeInitNativeKeyAsDeadKey() for wrapping dead key handling code in KeyboardLayout::InitNativeKey().
This makes InitNativeKey() code simpler. Now, any developers must be able to understand what InitNativeKey() does easier than before fixing this bug.
MozReview-Commit-ID: C59ESUXeTxU
--HG--
extra : rebase_source : c840a0544470ec4081e80c11e050d4dfedef4cad
There is DeactivateDeadKeyState() but not ActivateDeadKeyState(). There should be both of them and hides the dead key state management into them.
MozReview-Commit-ID: JvAPE5f2HVy
--HG--
extra : rebase_source : d7027a1a6b75c6859e79d651d3e9b0136cc09891
VirtualKey::GetCompositeChar() needs index of virtual keycode which may make around the caller messy. So, KeyboardLayout::GetCompositeChar() should wrap it and KeyboardLayout::MaybeInitNativeKeyWithCompositeChar() should use it.
MozReview-Commit-ID: 8KLTJpCFZ8u
--HG--
extra : rebase_source : fd13c009330fd485c8cba30f469fc645b560c623
Similar to VirtualKey::GetUniChars(), VirtualKey::GetNativeUniChars() needs key index. So, it should be wrapped by a new helper method, KeyboardLayout::GetNativeUniCharsAndModifiers(), and KeyboardEvent::InitNativeKey() should use this instead of accessing its member's GetNativeUniChars().
MozReview-Commit-ID: 7M9OlNF698Y
--HG--
extra : rebase_source : e19a5c99014a8f0a0ed7cc3a86fe0c4ee10cebb5
When InitNativeKey() retrieves UniCharsAndModifiers for a key, it needs key index for the given virtual keycode. Therefore, wrapping the code with GetUniCharsAndModifiers() makes InitNativeKey() code simpler since each call specifies the virtual keycode to the method instead of key index.
MozReview-Commit-ID: Azy8chXexaz
--HG--
extra : rebase_source : 98da43e7f542037f952206cd3db731f6cbb097e7
This patch gets rid of |shiftState| from KeyboardLayout::InitNativeKey() and make each caller clearer. This must make other developers understand what modifier state is used at each call.
MozReview-Commit-ID: 6zydP1jkffv
--HG--
extra : rebase_source : ea1d5f49ea02812aa632bdbad871688879f2b401
KeyboardLayout::InitNativeKey() is very messy because it handles a lot of cases without helper methods.
It's important to make it simpler implementation for preventing regressions caused by some patches which are written with misunderstanding. So, let's rewrite the method with helper method.
First, this patch make InitNativeKey() use IsDeadKey() instead of referring the table because calling IsDeadKey() is easier to understand.
MozReview-Commit-ID: DtN9qoh7Gz7
--HG--
extra : rebase_source : 8e769c1c88bfe646940491c111de609dbf53eeec
TSFTextStore shouldn't append any ranges to dispatch empty composition event since empty clause information may make TextComposition confused. Additionally, it doesn't need to append caret range because CompositionTransaction always sets caret at start of composition when the composition string is empty.
MozReview-Commit-ID: Iu8IWwEOxaf
--HG--
extra : rebase_source : 70b56c6d4caee309615170aee70f28d8c3eb7d92
When NativeKey tries to remove a char message from the queue, another NativeKey instance might be created due to odd API hook or something. In such case, the old instance should handle the received message and the new instance should do nothing for keeping the order of message handling.
This patch makes:
* NativeKey::GetFollowingCharMsg() store removing char message to mRemovingMsg before calling PeekMessage() with PM_REMOVE.
* NativeKey::InitWithChar() set the old instance's mReceivedMsg to the received char message and do nothing even if HandleCharMessage() is called later.
* NativeKey::GetFollowingCharMsg() return received char message if mReceivedMsg is set during a call of PeekMessage().
MozReview-Commit-ID: KXYW0GgC9AY
--HG--
extra : rebase_source : 08472dec28e93450cd04a367843c1511cb812a9c
For detecting nested creation of NativeKey instances, NativeKey should manage the latest instance with sLastestInstance for the other instances and previous instance with mLastInstance.
MozReview-Commit-ID: BFZ0cr1640S
--HG--
extra : rebase_source : e2439a21f5984c6246283924c2013038c734ae2a
For logging message, we should have better log text generator for MSG.
Then, we can improve the note of crash reports which is appended in NativeKey::GetFollowingCharMessage().
MozReview-Commit-ID: 4sbZJaWFH2o
--HG--
extra : rebase_source : bbc3101a78e4e2aa8b5eb0f68cd6f3605ba924f6
Currently, NativeKey::DispatchPluginEventsAndDiscardsCharMessages() calls nsWindowBase::DispatchPluginEvent() and nsWindowBase::DispatchPluginEvent() does nothing when windowless plugin doesn't have focus. However, this is unclear when other developers read the code of DispatchPluginEventsAndDiscardsCharMessages() and it causes unnecessary virtual calls. So, it should try to dispatch plugin events only when a windowless plugin has focus.
For making the check safer, nsWindowBase should expose the method to check it as ShouldDispatchPluginEvent(). Unfortunately, we cannot mark this method as const due to PluginHasFocus() needs to be not const method, though. Then, for loops in DispatchPluginEventsAndDiscardsCharMessages() should check it at each try.
This change helps to log the behavior (working on bug 1297013) without noise.
Additionally, this patch renames the method to MaybeDispatchPluginEventsForRemovedCharMessages() because it doesn't remove any char messages anymore.
MozReview-Commit-ID: F14Lcx47M6U
--HG--
extra : rebase_source : 64b6da75590c99299f75358023844762198136d6
NativeKey removes odd WM_CHAR messages which are caused by ATOK or WXG if the user tries to do "Kakutei-Undo" (meaning "undo the last commit") after dispatching eKeyDown event.
However, NativeKey should remove them from the queue first because there are some problems:
* If focus is moved during dispatching an eKeyDown event, we'll fail to remove the messages from the queue.
* If dispatching eKeyDown advance native event loop due to entering to a modal loop or dosing synchronous XHR, the message pattern is broken before removing the odd messages from the queue.
After removing the odd char messages, NativeKey should store them with mRemovedOddCharMsgs because NativeKey needs to dispatch them to focused windowless plugin.
Note that this patch also fixes a bug of the loop to remove the odd WM_CHAR messages. Old code removes only one WM_CHAR messages, but we need to remove all WM_CHAR messages before WM_KEYUP. This must be a regression.
MozReview-Commit-ID: I60bcIx2SFS
--HG--
extra : rebase_source : 19d0e70d9f39e6d0476c62def5e0a2dc1e0ab444
NativeKey is now removing and storing following char messages when it's created for a keydown message. Therefore, IsFollowedByNonControlCharMessage() just refers the stored messages and it's enough fast. So, we can get rid of mIsFollowedByNonControlCharMessage.
MozReview-Commit-ID: 542A2sHNXeC
--HG--
extra : rebase_source : e748c9855c3cf2d45609f94f9ccc8d43d29dc447
GetFollowingCharMessage() is now called only when removing following char message. Therefore, it does not need to have the optional argument indicating if removing the found message.
MozReview-Commit-ID: 7P39wyfSC1
--HG--
extra : rebase_source : a38bb961df1bc03adc21295bc39e4e9c16e864f2
While dispatching an event, focused widget may be changed. In such case, NativeKey shouldn't continue to dispatch remaining events (eKeyPress events) for preventing to dispatch to input text in unexpected website.
MozReview-Commit-ID: 7geuqks0LQK
--HG--
extra : rebase_source : 3e6c82e1eb0e27115fe93b1a3b4a155914fd06f7
In some cases, we may receive following char message of WM_*KEYDOWN *during* dispatching an eKeyDown event. In such case, NativeKey shouldn't dispatch eKeyPress event twice (one is caused by receiving WM_*CHAR message, the other is caused by post dispatching eKeyDown event code).
This patch makes NativeKey consume following WM_*CHAR messages before dispatching eKeyDown. Therefore, the former case will never occur.
For doing that, NativeKey stores following WM_*CHAR messages in mFollowingCharMsgs and uses it when it needs to dispatch eKeyPress events for each WM_*CHAR message.
MozReview-Commit-ID: 6QNvlwVVlTz
--HG--
extra : rebase_source : c33b5a1ac503326d51ef78f4f8a09c9a63df7871
For safety, NativeKey::GetScanCodeWithExtendedFlag() returns without extended flag on WinXP and WinServer2003 because ::MapVirtualKeyEx() API doesn't support extend key conversion.
However, extended scan code is available even on them when lParam has 0x1000000 especially when it computes KeyboardEvent.code value. Therefore, it should return with 0xE000 for extended keys on any versions of Windows.
Note that NativeKey::ComputeVirtualKeyCodeFromScanCodeEx() wraps ::MapVirtualKeyEx() API. It checks if the API is not available for the result of NativeKey::GetScanCodeWithExtendedFlag(). So, returning extended scan code from NativeKey::GetScanCodeWithExtendedFlag() is safe.
MozReview-Commit-ID: D2RrHxPI9ET
--HG--
extra : rebase_source : 51f277e8331eb7ad109c3227ac1fe73f6de48105
On Windows, some keys are called "extended key". Their scan code include 0xE000. For example, Enter key in standard position is 0x001C but Numpad's Enter key is 0xE01C. Unfortunately, both of them cause same virtual keycode value, VK_RETURN. Therefore, currently, nsIDOMWindowUtils.sendNativeKey() can synthesize only one native key event of them (only non-extended key's event). Additionally, MapVirtualKeyEx() API with MAPVK_VK_TO_VSC (even with MAPVK_VK_TO_VSC_EX) don't return extended scancode value as expected.
For solving these issues, we should include scan code value to the virtual keycode value at calling sendNativeKey().
Fortunately, virtual keycode value on Windows is 0 ~ 255 (0x00 ~ 0xFF) but aNativeKeyCode of sendNativeKey() is int32_t. So, we can use upper 16 bit for specifying scan code.
This patch explicitly specifies scan code value at defining WIN_VK_* in NativeKeyCodes.js. Additionally, this patch duplicates native virtual keycode definition for Home, End, Insert, Delete, PageUp, PageDown, ArrowUp, ArrowLeft, ArrowDown, ArrowRight and Enter as WIN_VK_* and WIN_VK_NUMPAD_*. This makes automated tests can specify both positions' keys explicitly.
Finally, this patch adds some tests to test_keycodes.xul for testing KeyboardEvent.code value of those keys in both positions.
MozReview-Commit-ID: 8n1rQ71dilg
--HG--
extra : rebase_source : 8215e56ba1ed9fc54c04eb7ca037b12c3ced5c1b
Ctrl+Backspace causes WM_CHAR for control character DELETE. However, NativeKey::IsControlChar() doesn't treat it as a control character. Therefore, NativeKey treats Backspace key as a printable character.
MozReview-Commit-ID: 29V45CNp8kW
--HG--
extra : rebase_source : 6656d884addf8b49dfa7c12d0b2c8d0543493c4f
On some keyboard layouts, a key sequence, a dead key -> another dead key, may produce a composite character instead of two base characters for each key. For example, with "Russian - Mnemonic" keyboard layout on Win 8 or later, both 's' and 'c' are dead keys but key sequence, 's' -> 'c', produces a Unicode character.
For solving this issue, this patch fixes 2 bugs:
First, KeyboardLayout::GetDeadKeyCombinations() doesn't add dead key entry if 2nd key is a dead key (::ToUnicodeEx() returns -1). In such case, it should add a dead key entry with the first character which is produced when only the 2nd key is pressed (the character is called as "base character" and used for index of the dead key table).
Next, KeyboardLayout::InitNativeKey() should check if 2nd dead key press produces a composite character. If it's produced, it should initialize given NativeKey with the composite character. Otherwise, it should initialize with base characters of each key. This patch does it with KeyboardLayout::MaybeInitNativeKeyWithCompositeChar().
Finally, we should add automated test for this. However, unfortunately, it's not available on Win7 and our infra is still using Win7 for running automated tests. Therefore, this patch doesn't include new automated tests.
MozReview-Commit-ID: G1DrfkHKNcK
--HG--
extra : rebase_source : 6ff4278d594a26a0908464b1e603a0a7ee2b3b38
It's difficult to understand what data is created by KeyboardLayout::LoadLayout(). So, for understanding what data is created, let's add logging code into it.
MozReview-Commit-ID: CelxyVpGn5f
--HG--
extra : rebase_source : fd8f15a42c4c2b4c1f1079184060c6e5f796ac5a
Based on crash reports, and issue was fixed in later drivers.
Also blocking 15.x up to 15.301.2301.1002.
MozReview-Commit-ID: F4kJta8JH1K
--HG--
extra : rebase_source : 5f69443b72cfefde052f70e27d8cf98128b3b913
There are 2 bugs and this patch fixes them once.
First, NativeKey::WillDispatchKeyboardEvent() is used to setting alternative charCode values for every eKeyPress event. However, for supporting "reserved" shortcut keys, now, it sets alternative charCode values to eKeyDown too. However, they are really different. eKeyPress events are fired for every character to be inputted by a key press sequence. On the other hand, eKeyDown event is fired only once for a key sequence. Therefore, now, NativeKey::WillDispatchKeyboardEvent() needs to set alternative charCode values for all characters inputted by the key sequence to eKeyDown event.
The other is not a new bug. NativeKey::WillDispatchKeyboardEvent() sets the last eKeyPress event's special alternative charCode values, such as unshifted Latin character, shifted Latin character and some character which can be computed from virtual keycode. This is performed when given index is the last index of the longest input string of the key. However, the value includes different shift key state. I.e., when different shift key causes longer text input, NativeKey::WillDispatchKeyboardEvent() won't set the special alternative charCode values to any eKeyPress events. For example, when Ctrl+T is pressed with Arabic keyboard layout, its unshifted input string length is 1 but shifted input string length is 2. Then, eKeyPress event is fired only once, but NativeKey::WillDispatchKeyboardEvent() waits second eKeyPress event.
Therefore, this patch makes the method append alternative charCodes for all remaining characters and detect the last event correctly with mCommittedCharsAndModifiers (it's used for KeyboardEvent.key value of eKeyDown event and the count of eKeyPress events is same as the value's length).
MozReview-Commit-ID: 6adUnmi5KYy
--HG--
extra : rebase_source : 8c04a3a155f2fcb9a5a8b3e9e0a176c678dc6265
When investigating bug 1075194, I found that we don't check return value of DocumentPropertiesW. So we sould use correct type and add log for this API.
MozReview-Commit-ID: Ck3VwMq9OpQ
--HG--
extra : amend_source : a0da15b578055b7612ce96b44cac2cd69607fa51
This patch prevents the Windows widget code from dispatching the contextmenu
event if APZ is handling touch input. Instead, the APZ code processes the
raw touch input, and will fire a contextmenu event when the user lifts their
finger after a long-press action, in keeping with the Windows platform
convention. Doing it this way also allows us to respect web conventions where
the web content can prevent the contextmenu event from firing by calling
preventDefault on the touchstart event; this was not possible when dispatching
the contextmenu event directly from the widget code.
This also makes long-pressing on browser chrome components work properly, as
it just shifts the point in time that the contextmenu event is fired without
changing any of the code that triggers the XUL popup. However, some changes
were needed to have the widget code ignore the synthetic mouse events that
the Windows platform sends us, because those would otherwise immediately
dismiss the contextmenu popup after it appeared.
MozReview-Commit-ID: 9HFZLC6xUAi
--HG--
extra : rebase_source : aea932d9f95454c585bcdf962d151c946b5c6ec2
The new test failure is caused by a bug of the test API, KeyboardLayout::SysnthesizeNativeKeyEvent(). It doesn't generate WM_SYSKEY* messages nor WM_SYS*CHAR messages when Alt key is pressed. Therefore, the new path in the previous code works unexpectedly with automated tests.
This patch makes KeyboardLayout::SysnthesizeNativeKeyEvent() WM_SYS* message aware. When Alt key is pressed (but Ctrl key is not pressed) and the Alt key + something doesn't cause text input, the API generates WM_SYS* messages as expected.
MozReview-Commit-ID: FLbe4SYEZLf
--HG--
extra : rebase_source : 054147997eddfb01dbad63afc07e0b4f59a60257
Some keyboard utilities for Windows can change non-printable keys to printable keys. Therefore, if a keydown message is followed by one or more char message whose wParam isn't a control character, NativeKey should treat it as a printable key's event.
MozReview-Commit-ID: HoFbz5Zafeh
--HG--
extra : rebase_source : 9001c58cb082a93946e1b4c445dfe71f15d08997
This patch does the following.
- Removes the return value, because none of the call sites check it.
- Removes the empty implementations from several nsIWidget instances, because
they can use the nsBaseWidget one.
--HG--
extra : rebase_source : 1c42bb32a662f2659c934a245ecd0025045120a5
This patch does the following.
- Removes the return value, because none of the call sites check it.
- Puts an empty implementation into nsBaseWidget.
- Removes the empty implementations from several nsIWidget instances, because
they can use the nsBaseWidget one.
--HG--
extra : rebase_source : 2a94a47f1e7fe986d1efc3854c72968a3e28e365
This patch does the following.
- Removes the return value, because none of the call sites check it.
- Removes the empty implementations from several nsIWidget instances, because
they can use the nsBaseWidget one.
--HG--
extra : rebase_source : 82733f682c9e254e20354cc6908955a1e7485ee7
This patch does the following.
- Removes the return value, because none of the call sites check it.
- Puts an empty implementation into nsBaseWidget.
- Removes the empty implementations from several nsIWidget instances, because
they can use the nsBaseWidget one.
--HG--
extra : rebase_source : ccf64aaa9364d096e1f060ef77be7e8455b11e1f
This patch does the following.
- Removes the return value, because none of the call sites check it.
- Puts an empty implementation into nsBaseWidget.
- Removes the empty implementations from several nsIWidget instances, because
they can use the nsBaseWidget one.
--HG--
extra : rebase_source : e98b7f9970a920c39e941bb531dfc098125913d1
KeyboardEvent::InitNativeKey() should initialize NativeKey if it's created for handling an orphan WM_CHAR message, however, if it the charCode isn't a printable character such as 0x0D for Enter key, it shouldn't refer it because focused editor shouldn't handle keyboard event as inputting the non-printable character.
MozReview-Commit-ID: FwTdGqhPEld
--HG--
extra : rebase_source : 69da91ad47e64199c8ff6c120522eb7e153122cd
The patch is generated from following command:
rgrep -l unused.h|xargs sed -i -e s,mozilla/unused.h,mozilla/Unused.h,
MozReview-Commit-ID: AtLcWApZfES
--HG--
rename : mfbt/unused.h => mfbt/Unused.h
Nicholas Nethercote
David Major
Daniel Holbert
Emanuel Hoogeveen
Wes Kocher
Kartikaya Gupta
Carsten "Tomcat" Book
Ryan Hunt
Masayuki Nakano
Masatoshi Kimura
Aaron Klotz
Milan Sreckovic
Mike Conley
Makoto Kato
Tracy Walker
Chris Peterson
Benjamin Smedberg
Bill McCloskey
Phil Ringnalda
Jonathan Watt
Bas Schouten
Neil Deakin
Ryan VanderMeulen
Jean-Luc Bonnafoux
Jonathan Kew
Sebastian Hengst
Cervantes Yu
Stone Shih
Ting-Yu Chou
Morris Tseng
Markus Stange
Xidorn Quan
Mozilla Graphics Team
Andrew McCreight
Nathan Froyd
Kevin Wern
Kan-Ru Chen
Bob Owen
David Parks
Ahmed (Gentz) El Gendy
David Anderson
Dão Gottwald
Eric Rahm
Edwin Flores
Nicolas Silva
George Wright
Thomas Wisniewski
Gerald Squelart
Chih-Yi Leu
Ho-Pang Hsu
Ethan Lin
Olli Pettay
Sotaro Ikeda