It would be convenient to get nsPresContext from nsIDocument.
MozReview-Commit-ID: Ei6V3UE8XGr
--HG--
extra : rebase_source : 8d2a917eb62cf341e4e1810451fd01c01dbc3bad
These conditions are rare and do indicate a problem which breaks accessibility.
However, we aren't getting any closer to diagnosing these as a result of these crashes, so they cause user pain without any gain to us.
MozReview-Commit-ID: D9U4et3Bg7d
--HG--
extra : rebase_source : a81263a0ef97a8ed87129d15ef30ded3005e740c
These conditions are rare and do indicate a problem which breaks accessibility.
However, we aren't getting any closer to diagnosing these as a result of these crashes, so they cause user pain without any gain to us.
MozReview-Commit-ID: D9U4et3Bg7d
--HG--
extra : rebase_source : a81263a0ef97a8ed87129d15ef30ded3005e740c
nsIDOMWindowUtils::sendKeyEvent() is already replaced with nsITextInputProcessor
for making callers set any attributes of KeyboardEvent and guaranteeing
consistency behavior with keyboard events caused by native key events. E.g.,
whether keypress event should be dispatched or not is automatically decided.
nsIFrameLoader::sendCrossProcessKeyEvent() is similart to
nsIDOMWindowUtils::sendKeyEvent() but it dispatches keyboard events in
child process directly. Currently, nsITextInputProcessor doesn't have this
feature but nobody wants/uses this feature. So, for removing actual
implementation of nsIDOMWindowUtils::sendKeyEvent(), i.e.,
nsContentUtils::SendKeyEvent(), which is shared by both
nsDOMWindowUtils::SendKeyEvent() and nsFrameLoader::SendCrossProcessKeyEvent(),
we should remove this unused API too. (FYI: it's implemented for old Fennec,
by bug 553149.)
MozReview-Commit-ID: 9n0UVo8Me8k
--HG--
extra : rebase_source : e9b117f5b9afec76e63d57ab8cd86dafb5873789
Modifiers of shortcut keys may be same as modifier of content access keys.
When focus is in the main process, such eKeyPress event is sent to remote
content first. Then, and if it's not handled in the remote content,
eAccessKeyNotFound is dispatched into the DOM tree in the main process.
However, nsXBLWindowKeyHandler doesn't handle it as eKeyPress event. So,
it causes that shortcut keys whose modifier conflicts with content access key
won't be handled.
This patch just makes nsXBLWindowKeyHandler treat eAccessKeyNotFound as
eKeyPress event even though other shortcut keys which are handled by JS
won't be executed. Perhaps, we should stop using eAccessKeyNotFound but
it's too risky change for now.
MozReview-Commit-ID: IJltg5gwBc5
--HG--
extra : rebase_source : f456eade18cd4fefd2eab6e06f5b00156ac8ad59
This assumption also mirrors how non-remote browsers have their docShells active by default.
In order to do this, I also have to increase the initial epoch's for the TabParent and TabChild,
as if a RenderLayers has been called. Originally, since the epochs initted at 0, and the epochs
stored by the [Layer|WebRender]TransactionParent were also initted at 0, we'd hit this branch:
https://searchfox.org/mozilla-central/rev/c633ffa4c4611f202ca11270dcddb7b29edddff8/gfx/layers/ipc/LayerTransactionParent.cpp#703
and then we'd never alert the TabParent about the layer upload.
MozReview-Commit-ID: 6PP1eCnisYK
--HG--
extra : rebase_source : 4ca9f692635e3a3a1ec8e626d0db24f2e512ec9a
extra : source : b9b2895b11a32f3da0f4c8fe364bf3bdfc7defb6
This is necessary because sometimes the async tab switcher will instantiate when
there already exists some background tabs that are rendering via print preview. When
that happens, it's important for the state to be set correctly for them so that we
don't accidentally treat them as still loading, and wait (forever) for them to report
having finished loading.
MozReview-Commit-ID: 2dwo5WlXlgJ
--HG--
extra : rebase_source : 4b1e2fb945f1dc4591c56f836a1caa9adeea9eb4
extra : source : 53bb2bc2b67673572dafc3093280fa72973b3d32
Originally, setting the active state on the DocShell for remote browsers also did the
work of making the TabChild render its layers and upload them to the compositor.
This patch adds a new renderLayers method to nsITabParent which allows more fine-grained
control - we can now, for example, cause layers to be rendered and uploaded without
activating the DocShell.
Note that if one activates or deactivates the DocShell, we'll still do the work of
attempting to render / clear the layers if it hasn't already been done.
MozReview-Commit-ID: KkLaMDTzfHi
--HG--
extra : rebase_source : 6c53729ae4b07c67d9e3de99c12e1165a85ffaac
extra : source : 261be8ec05542a9e50c0ca03a59a8a44997269b7
This assumption also mirrors how non-remote browsers have their docShells active by default.
In order to do this, I also have to increase the initial epoch's for the TabParent and TabChild,
as if a RenderLayers has been called. Originally, since the epochs initted at 0, and the epochs
stored by the [Layer|WebRender]TransactionParent were also initted at 0, we'd hit this branch:
https://searchfox.org/mozilla-central/rev/c633ffa4c4611f202ca11270dcddb7b29edddff8/gfx/layers/ipc/LayerTransactionParent.cpp#703
and then we'd never alert the TabParent about the layer upload.
MozReview-Commit-ID: 6PP1eCnisYK
--HG--
extra : rebase_source : da736415d6b60208fa54bc25fe449cc261e856d8
This is necessary because sometimes the async tab switcher will instantiate when
there already exists some background tabs that are rendering via print preview. When
that happens, it's important for the state to be set correctly for them so that we
don't accidentally treat them as still loading, and wait (forever) for them to report
having finished loading.
MozReview-Commit-ID: 2dwo5WlXlgJ
--HG--
extra : rebase_source : 7d3def56bf6ba12bb6110b60bb3d79329bfc0abd
Originally, setting the active state on the DocShell for remote browsers also did the
work of making the TabChild render its layers and upload them to the compositor.
This patch adds a new renderLayers method to nsITabParent which allows more fine-grained
control - we can now, for example, cause layers to be rendered and uploaded without
activating the DocShell.
Note that if one activates or deactivates the DocShell, we'll still do the work of
attempting to render / clear the layers if it hasn't already been done.
MozReview-Commit-ID: KkLaMDTzfHi
--HG--
extra : rebase_source : 2d00dc71c584a41650696a412b6249aee3a505fe
After landing bug 1353060, TabParent::GetWidget()'s behaviour is changed. We
should use GetDocWidget for IME.
MozReview-Commit-ID: 5DpYjzQDHlD
--HG--
extra : rebase_source : f1b827a0d6fe88549ead6a7a68b8bd2fbcaf5487
Out of process support for Web extension creates another XUL widget for it.
We should calculate correct offset for Web Extension's remote widget.
MozReview-Commit-ID: AaALzLeKLsM
--HG--
extra : rebase_source : da3562d6ec6b93b99d12b0cac4d80d8b91e286fd
It's easy to mess up the scoping so that (a) the label is pushed and then
immediately popped, and/or (b) the string doesn't live long enough. It's also
easy to do a utf16-to-utf8 conversion unnecessarily when the profiler is
inactive. This patch splits that macro into three new ones that are harder to
mess up.
- AUTO_PROFILER_LABEL_DYNAMIC_CSTR: same as current.
- AUTO_PROFILER_LABEL_DYNAMIC_NSCSTRING: for nsCStrings.
- AUTO_PROFILER_LABEL_DYNAMIC_LOSSY_NSSTRING: for nsStrings.
--HG--
extra : rebase_source : 3e2bbec4737b696e1c86579ae54be4cb3186c100
The two happening at the same time can lead to the APZ autoscroll being
cancelled due to APZ receiving a main-thread scroll offset update.
To achieve this:
- The content process assumes APZ is handling the autoscroll until
told otherwise.
- If the parent process knows APZ won't handle an autoscroll, it
tells the content process via its response to the Autoscroll:Start
message. This covers all cases where APZ doesn't handle the
autoscroll, except the case where APZCTreeManager itself rejects
the autoscroll and it lives in the compositor process rather than
the parent process.
- If APZCTreeManager rejects an autoscroll and it lives in the
compositor process, it sends an 'autoscroll-rejected-by-apz' message
to the content process.
MozReview-Commit-ID: L62v4COai6W
--HG--
extra : rebase_source : bc4c6417e77461634263defb88e67ed5036c454e
When sending keyboard events from TabParent to its remote process, TabParent
may give higher priority to them than composition events and selectionset event.
Therefore, the event order between keyboard events and composition events (and
selection set event) may be broken. Keyboard events which should cause
inputting some characters are ignored if keyboard events are fired before
compositionend event accidentally.
This patch gives same priority to composition events and selectionset event
as keyboard event for avoiding breaking the event order.
MozReview-Commit-ID: 53jubwuHVvw
--HG--
extra : rebase_source : ddba2cce5980a354a47ded68e69ef973c00dac4b
Because UBSan complains about casting -1:
> runtime error: load of value 4294967295, which is not a valid value for type 'nsCursor'
--HG--
extra : rebase_source : 037a96700228ea0d427afa7c25c40490c701cdc4
Telemetry and some performance profiles show that Msg_NotifyIMEFocus can take
a few seconds to complete, and jank the browser. With bug 1217700, it removes
the necessity of sync Msg_NotifyIMEFocus, so in this patch we make this async
for performance improvement.
MozReview-Commit-ID: 15eUwMJ2Q7H
--HG--
extra : rebase_source : b463e6e881ca5ebec00d0f76e29ca103059b3ddd
Android now supports telling an IME that it shouldn't store user-entered content into it's dictionary/language model/etc. and we want to automatically enable this in private browsing.
As the code that handles input on Android doesn't have any notion of tabs (and therefore of the difference between normal and private tabs), the best way to get that info across is to retrieve it directly within the IMEStateManager from the corresponding document and store it in the inputContext, which is then passed to Java for Fennec to handle.
Implementing this within Gecko also has the benefit that this part of the code can be used by other platforms as well should they want to support similar features in the future.
MozReview-Commit-ID: DsxjC4Ma7DR
--HG--
extra : rebase_source : f0940cb40170ab32cf5a172d07a61d083427be8a
The messages are routed through nsITabParent, nsIWidget, and IAPZCTreeManager
(the latter possibly remoted via PAPZCTreeManager if out-of-process compositing
is used).
MozReview-Commit-ID: 1zXzLa1fqpG
--HG--
extra : rebase_source : c482816ecbaec0a889d817851ee15be186b2a49c
Currently, access key is handled in EventStateManager::PreHandleEvent() with eKeyPress event, i.e., before dispatching it into the DOM tree, if the access key is registered in EventStateManager. So, the main process does not check if the preceding eKeyDown event is consumed in focused remote process.
When preceding eKeyDown event is consumed in the main process, eKeyPress event won't be dispatched by widget. However, if remote process has focus, it's impossible widget to stop dispatching eKeyPress event because preceding eKeyDown event hasn't been handled in the focused remote process yet. Therefore, main process needs to post eKeyPress event to check if preceding eKeyDown event was consumed. When eKeyPress event is marked as "waiting reply from remote process", TabChild sends it back to the main process only when preceding eKeyDown event wasn't consumed. So, only when eKeyPress event is back to the main process, main process should handle accesskey with it.
This patch makes EventStateManager::PreHandleEvent() check if a remote target has focus before handling accesskey. If a remote process has accesskey and there is an accesskey matching with eKeyPress event, it marks the event as "waiting reply from remote content" and stop propagation in the process.
Finally, when eKeyPress event is sent back to TabParent, TabParent::RecvReplyKeyEvent() calls EventStateManager::HandleAccessKey() before dispatching the reply event into the DOM tree.
MozReview-Commit-ID: KsOkakaIVzb
--HG--
extra : rebase_source : 7e0c6966a1bde085e34d45bca4b0166b9fc2f3f1
EventStateManager checks if every keypress event's modifiers match with access key modifiers which are in prefs. Moving related methods of this to WidgetKeyboardEvent makes EventStateManager simpler and we can hide the NS_MODIFIER_* constants (they may make developers confused between Modifiers of WidgetInputEvent) into WidgetEventImpl.cpp.
MozReview-Commit-ID: 23NUQ51lJ1M
--HG--
extra : rebase_source : 341f3764ef62575577572d8b349159e2d5512b26
The current code is wrong in several ways when transforms are applied, but
even if it were correct, it would give the wrong behavior. See comment in
patch for more details.
MozReview-Commit-ID: 3RaPuvENnWa
--HG--
extra : rebase_source : 25aab67e56f157bdfa500aa7cf029c6ebe90e12a
extra : absorb_source : 4da2fd9f11e008b7b70b86b184ade673a68e6978
On-screen coordinates for points in remote frameloads are calculated relative
to the screen origin of the top-level window, while event coordinates are
calculated relative to the nearest widget. Since popups have their own widgets
separate from the top-level window, their native client offsets have no
particular relation to the origin of the top-level window, and we need to
manually calculate them relative to the origin of the top-level widget
instead.
MozReview-Commit-ID: EDyEyu37XuY
--HG--
extra : rebase_source : 5d3f7a3fb9518d7a0cf149b8c2f579805d75eb3b
extra : absorb_source : f48ee4b131ff67ae686d12f81ed2ad19b934e81e
IME should receive notifications and requests only from proper process. E.g., IME shouldn't commit composition by a request which came from previous focused process.
This patch makes that IMEStateManager::NotifyIME() takes pointer to TabParent optionally. If the request or notification came from remote process, it should be non-nullptr. Then, this makes it ignore notifications and requests from unexpected process.
Note that this patch also touches some gfx headers because they use |ipc::| but compiler is confused at the ambiguousness between |mozilla::ipc::| and |mozilla::dom::ipc::|.
Finally, this patch changes the NS_ASSERTION in IMEHandler::OnDestroyWindow() to MOZ_ASSERT because the orange caused by the NS_ASSERTION was not realized since there was already an intermittent orange bug caused by different NS_ASSERTION.
MozReview-Commit-ID: 9CgKXQRJWmN
--HG--
extra : source : f3b5711908870c5e0e852a399a07e0ae721a12f1
Currently, it's not been managed yet that whether an event is posted to at least one remote process. So, for managing the state, BaseEventFlags should have a new bool flag and WidgetEvent and BaseEventFlags should have helper methods for it.
Additionally, this fixes a bug of nsGUIEventIPC.h. In a lot of ParamTraits, static_cast<Foo> is used for using base class's ParamTraits. However, it causes creating temporary instance with copy constructor. Therefore, WidgetEvent::MarkAsPostedToRemoteProcess() call in ParamTraits<mozilla::WidgetEvent>::Write() didn't work as expected.
MozReview-Commit-ID: DdafsbVfrya
--HG--
extra : rebase_source : 94205f3a7b36455c3c9f607c35866be033e627c1
Currently, we have 2 bool flags (and optional 2 bool flags with related purpose) for managing propagation state between parent process and remote process. However, it's really complicated. Actually, setting these flags and referring the flags is usually follow explanation.
So, for making simpler, WidgetEvent and BaseEventFlags should have some utility methods for making them as self documented code.
This patch moves WidgetKeyboardEvent::mIsReserved to BaseEventFlags::mIsReservedByChrome. That allows us to manage the cross process event propagation state in same place.
MozReview-Commit-ID: IXEDQJ4GpAZ
--HG--
extra : rebase_source : 5b63ac4f1d15e40e8bfc88423e336de28caa8ab6
The problem is, only when requesting IME to commit or cancel composition is handled synchronously, TabParent does not send the dispatched eCompositionCommit(AsIs) event to the remote process. Therefore, TabParent (and ContentCacheInParent) never receives the message from the remote process.
This patch makes TabChild notifies TabParent of eCompositionCommitRequestHandled special event message after TabChild dispatches eCompositionCommit into the DOM tree. Then, ContentCacheInParent should decrease mPendingCompositionCount and mPendingEventsNeedingAck as usual composition event messages.
MozReview-Commit-ID: 7ec5HPiE687
--HG--
extra : rebase_source : a9366abf6f8feec2d6ac639fd37f5b5c6ddd9586
TextComposition in the main process is destroyed when the main process sends eCompositionCommit(AsIs) to focused remote process. Therefore, ContentCacheInParent::mCompositionPendingCount is never 2 or more now.
It may cause ContentCacheInParent::Assign() setting older composition's start offset to current composition's start offset in the main process.
For making uplift the following patch easier, the wrong patch should be backed out first.
MozReview-Commit-ID: IHWc7qZBQtc
--HG--
extra : rebase_source : d3936fa82ed670217b711d15bbb0201a8741501b
This patch makes the following changes to the macros.
- Removes PROFILER_LABEL_FUNC. It's only suitable for use in functions outside
classes, due to PROFILER_FUNCTION_NAME not getting class names, and it was
mostly misused.
- Removes PROFILER_FUNCTION_NAME. It's no longer used, and __func__ is
universally available now anyway.
- Combines the first two string literal arguments of PROFILER_LABEL and
PROFILER_LABEL_DYNAMIC into a single argument. There was no good reason for
them to be separate, and it forced a '::' in the label, which isn't always
appropriate. Also, the meaning of the "name_space" argument was interpreted
in an interesting variety of ways.
- Adds an "AUTO_" prefix to PROFILER_LABEL and PROFILER_LABEL_DYNAMIC, to make
it clearer they construct RAII objects rather than just being function calls.
(I myself have screwed up the scoping because of this in the past.)
- Fills in the 'js::ProfileEntry::Category::' qualifier within the macro, so
the caller doesn't need to. This makes a *lot* more of the uses fit onto a
single line.
The patch also makes the following changes to the macro uses (beyond those
required by the changes described above).
- Fixes a bunch of labels that had gotten out of sync with the name of the
class and/or function that encloses them.
- Removes a useless PROFILER_LABEL use within a trivial scope in
EventStateManager::DispatchMouseOrPointerEvent(). It clearly wasn't serving
any useful purpose. It also serves as extra evidence that the AUTO_ prefix is
a good idea.
- Tweaks DecodePool::SyncRunIf{Preferred,Possible} so that the labelling is
done within them, instead of at their callsites, because that's a more
standard way of doing things.
--HG--
extra : rebase_source : 318d1bc6fc1425a94aacbf489dd46e4f83211de4
ContentCacheInParent::mPendingCompositionCount is now managed with composition events which TabParent received. However, TextComposition doesn't dispatch composition events after coming request to commit active composition. Therefore, composition is committed forcibly in a remote process over 255 times, the main process crashes.
It's the safest way to use TextComposition to manage ContentCacheInParent::mPendingCompositionCount.
MozReview-Commit-ID: DEhzYcK1zcW
--HG--
extra : rebase_source : a47891b1d620bbe4e380e73134ec6da5d21f4ea9
This event is no longer necessary, since checking nsITabParent.hasPresented is enough to know
if we need to blank out the tab or not.
MozReview-Commit-ID: 445XMqhorxC
--HG--
extra : rebase_source : 1a05de827502c409d979a621471978b08ce39fb2
Changes:
- remove code addressed by reviewer
- remove PContent.ipdl, PBrowser.ipdl, and ProcessPriorityManager code
that relates only to removed AudioChannelService methods
- correct test case listening to event from removed code
- remove useless test case files
MozReview-Commit-ID: I96nR8zTXJt
--HG--
extra : rebase_source : 127876c672744811c025ca55839ff2e8a06b1fce
PBrowser::RequestNativeKeyBindings() is used only when somebody tries to
execute native key bindings for synthesized keyboard events. Therefore, it
doesn't need to retrieve edit commands for all editor types. Instead, it
should take the editor type and just return the edit commands for it.
MozReview-Commit-ID: HF4Gz99SBQP
--HG--
extra : rebase_source : e332d2ef5ae36949a9a362d8f95c5d427c9812e7
Now, nsIWidget::ExecuteNativeKeyBinding() isn't used by anybody for executing
edit commands. Instead, they need array of edit commands for the key
combination. So, the method should be renamed to GetEditCommands() and just
return edit commands as an array.
MozReview-Commit-ID: 4G0B1lJ8Lbe
--HG--
extra : rebase_source : 4a5829281d59677c773950c34d91a1cd8074d243
When eKeyPress event is dispatched from TabParent to a remote process, it
should store edit command for all editor types. Then, copied
WidgetKeyboardEvent in the remote process doesn't need to request the edit
commands when its ExecuteEditCommands() is called.
Note that this patch also changes a automated test, browser_bug1316330.js,
that uses nsIDOMWindowUtils.dispatchDOMEventViaPresShell() to dispatch
repeated keyboard events in the tab. However, it should use synthesizeKey()
to emulate everything of native keyboard events and the API can dispatch
repeated keyboard events too. (And the test has a bug. It tries to wait 0.5
sec when every keydown or keypress event. However, it fails since startTime
is never initialized. This patch fixes this bug too.)
MozReview-Commit-ID: IYhyxqH3Ch8
--HG--
extra : rebase_source : 0db911e8e6ea7fc537bda76f4cc0f8952cc13dd2
Currently, we only correctly support remote layer trees for frameloaders that
use the same layer manager as their document. Since we need to be able to host
remote <browser> content in popup widgets for remote WebExtensions, we need to
tie the frameloaders to the layer manager of their host element, rather than
the root layer manager for the document.
MozReview-Commit-ID: 4RCsamFBiQw
Currently, we only correctly support remote layer trees for frameloaders that
use the same layer manager as their document. Since we need to be able to host
remote <browser> content in popup widgets for remote WebExtensions, we need to
tie the frameloaders to the layer manager of their host element, rather than
the root layer manager for the document.
MozReview-Commit-ID: 4RCsamFBiQw
--HG--
extra : rebase_source : 86bca4ae1c012ff1bb84a9ad796be311cfe580f6
extra : histedit_source : 19577d69430adc8cb38c195f13db2c6de6605c4c
This will return true if any of the frames loaded in the associated
TabChild have set at least one onbeforeunload event handler. If those
handlers are all removed, or all of the documents with onbeforeunload
event handlers are unloaded, this becomes false again.
Note that subframes that are sandboxed without the allow-modals
permission will not affect the hasBeforeUnload attribute, since
those iframes should never cause the beforeunload confirmation
dialog to display.
MozReview-Commit-ID: 8b0gBYWwMDn
--HG--
extra : rebase_source : 69f3b692d6e73f6277e6982aad02bcd1ebdd8acf
Remove sync protocol AllocateTabId. Instead we generate tabId in
each process with nsContentUtils::GenerateTabId, and register
RemoteFrameInfo in parent process. If the tab id was generated from
a content process, it's sent parent through either PBrowserConstructor
or PContent::CreateChildProcess.
MozReview-Commit-ID: D3W2fK9eCNH
--HG--
extra : rebase_source : 1913f8f586537be1c82a70a19cc8c6351671d0df
IMEContentObserver may need to change notifications to send when TextInputProcessor begins input transaction. In current design, IMEContentObserver needs to retrieve IMENotificationRequests at every change. However, if nsIWidget returns a reference to its IMENotificationRequests, IMEContentObserver can call it only once.
For that purpose, this patch changes nsIWidget::GetIMENotificationRequests() to nsIWidget::IMENotificationRequestsRef() and make it return |const IMENotificationRequests&|. However, if the lifetime of the instance of IMENotificationRequest is shorter than the widget instance's, it's dangerous. Therefore, it always returns TextEventDispatcher::mIMENotificationRequests. TextEventDispatcher's lifetime is longer than the widget. Therefore, this guarantees the lifetime.
On the other hand, widget needs to update TextEventDispatcher::mIMENotificationRequests before calls of nsIWidget::IMENotificationRequestsRef(). Therefore, this patch makes TextEventDispatcher update proper IMENotificationRequests when it gets focus or starts new input transaction and clear mIMENotificationRequests when it loses focus.
Note that TextEventDispatcher gets proper requests both from native text event dispatcher listener (typically, implemented by native IME handler class) and TextInputProcessor when TextInputProcessor has input transaction because even if TextInputProcessor overrides native IME, native IME still needs to know the content changes since they may get new input transaction after that.
However, there may not be native IME handler in content process. If it runs in Android, PuppetWidget may have native IME handler because widget directly handles IME in e10s mode for Android. Otherwise, native IME handler is in its parent process. So, if TextInputHandler has input transaction in content process, PuppetWidget needs to behave as native event handler. Therefore, this patch makes PuppetWidget inherit TextEventDispatcherListener and implements PuppetWidget::IMENotificationRequestsRef().
MozReview-Commit-ID: 2SW3moONTOX
--HG--
extra : rebase_source : d2634ada6c33dbf7a966fadb68608411ee24bfab
Our caller is C++ code, and the implementations are all also written in C++,
so there is no reason to go through SpiderMonkey here. This patch also makes
nsILoadContext builtinclass to ensure that the implementation is always native.
This piggybacks the sync message on the pre-existing
EnsureLayersConnected sync message pathway to the compositor.
MozReview-Commit-ID: DfYTlJrr3Gu
--HG--
extra : rebase_source : c2bd29e655db65e3016a79bf3f6068ffb1c8b7c7
Sebastian Hengst
Peter Van der Beken
Emilio Cobos Álvarez
Boris Zbarsky
Hiroyuki Ikezoe
Dorel Luca
Milan Sreckovic
Jeff Muizelaar
James Teh
Andreea Pavel
Masayuki Nakano
Tooru Fujisawa
Coroiu Cristina
Nika Layzell
Mike Conley
Makoto Kato
Chris Peterson
Nicholas Nethercote
Botond Ballo
Chung-Sheng Fu
Aaron Klotz
Yura Zenevich
Stone Shih
Henry Chang
Christoph Kerschbaumer
Jan Henning
Kris Maglione
Carsten "Tomcat" Book
Ryan VanderMeulen
Kris Maglione
Samael Wang
Michael Layzell
Bill McCloskey
Wes Kocher
Andrea Marchesini
Eden Chuang
Ehsan Akhgari
btian
Stephen A Pohl
Kartikaya Gupta
Valentin Gosu