In the case where an inactive scrollframe's scrollbar gets dragged, the
main thread layerizes the scrollframe and dispatches both a
SetTargetAPZC message and a AsyncDragMetrics message using post-refresh
observers. However, the post-refresh observers are registered such that
the SetTargetAPZC message gets sent first, and APZ will start
processing the drag block immediately upon receipt of that event. This
means that the APZC might not have the correct drag metrics when it
processes those input events. For correct behaviour, we want the
AsyncDragMetrics message to reach APZ first in this scenario, and this
patch accomplishes this by allowing the post-refresh observers to be
registered in the opposite order.
MozReview-Commit-ID: 6LzyYYG1t6F
--HG--
extra : rebase_source : 2e3ebaa4fd776c8ad17e8225d70ec4a18eee67e0
It's based on a solution by Takuro Ashie <ashie@clear-code.com>
MozReview-Commit-ID: FqcdUJQJLdl
--HG--
extra : rebase_source : d4ed4d66439a3693a2f4d5e6a4037ed62969d64f
Currently, TabChild discards eKeyDown and eKeyPress events which are marked as
"repeated" and were dispatched after the latest eKeyDown event comes into the
process. However, keyboard layout utils may generate native key events
as "repeated" even if each native key is important to input proper text.
So, TabChild shouldn't decide if coming keyboard event is skippable only with
mIsRepeat. For solving this issue, this patch adds
mMaybeSkippableInRemoteProcess to WidgetKeyboardEvent and makes
TabChild::SkipRepeatedKeyEvent() check
WidgetKeyboardEvent::CanSkipInRemoteProcess() instead.
On Windows, there are two ways to generate keyboard input messages. One is
using SendMessage() or PostMessage(). The other is SendInput() API. In both
ways, utils can make their input as repeated key messages.
The former case must be safe for this issue since such utils need to set 31st
bit of lParam to 1 explicitly.
On the other hand, in the latter case, the utils probably need to append
KEYEVENTF_KEYUP into KEYBDINPUT::dwFlags. Otherwise, only first call is
treated as non-repeated event.
So, when given message does not came from physical key operation, NativeKey
should set WidgetKeyboardEvent::mMaybeSkippableInRemoteProcess to false
even if WidgetKeyboardEvent::mIsRepeat is true.
MozReview-Commit-ID: 3rinrOjx8Tf
--HG--
extra : rebase_source : 26b6d869260176fc7ef535323b83001bb4b725c2
nsGeoPositionCoords will convert NaNs returned from the location providers to null properties of the JavaScript Coordinates object.
MozReview-Commit-ID: Cmuf2aO0ClD
--HG--
extra : rebase_source : cbccead609ff53a3e5f1bcf7698eba7382220ce5
extra : source : b4ced6e2bab2d17cf642f5850bda5998f635fccb
Refactored StyleComplexColor to support "complex" blending between
background (numeric) color and foreground color (currentColor).
Made explicit the distinction between numeric, currentColor and a
complex blend in Gecko and Stylo.
This is to support SMIL animation, for example, of the form:
<animate from="rgb(10,20,30)" by="currentColor" ... />
MozReview-Commit-ID: IUAK8P07gtm
--HG--
extra : rebase_source : d3648101c6f65479b21e6f02945731cd5bb57663
When runnables are posted to the main thread's event loop, the event
loop notifies any thread observers that this has been done. The app
shell registers itself as just such a runnable, and posts messages to
the native event loop that processing native events needs to be done.
On Windows, this posting takes an extra reference to the app shell, to
keep it alive until the message is processed by the native event loop,
since app shell code needs to be invoked during that processing. The
processing releases this extra reference, so everything stays balanced.
Except that it's possible for messages to be posted to the native event
loop, and then browser shutdown happens. Those messages are not
processed and the associated references taken are not released. This
imbalance means that in debug builds, we appear to be leaking the app
shell, and that leaking results in intermittent oranges.
This intermittent orange has manifested itself in a variety of ways over
the years, depending on how big the app shell itself was (since that
changes the number of bytes leaked) and how many leak-checked things the
app shell was holding on to. This bug is merely the latest
manifestation; the last serious work on analyzing the phenomenon and
fixing it was done in bug 1220517.
The solution proposed in that bug was that we simply stop the extra
reference counting; when the app shell is destroyed normally, we
shouldn't be processing the native event loop any more anyway. So even
if the native event loop is holding (freed) pointers to the app shell,
we'd never execute the callback and perform a use-after-free. Reading
through the code suggests that this *ought* to be the case, but the
potential for shooting ourselves in the foot seems awfully high.
In any event, this is not a problem unique to Windows; we have seen this
same sort of thing happen on OS X. See nsAppShell::ProcessGeckoEvents
in widget/cocoa/nsAppShell.mm.
Here we propose a slightly different solution: we keep track of the
number of native event callbacks we have scheduled, incrementing when we
schedule, and decrementing when we actually run one. When the app shell
is destroyed, we simply set the number of outstanding events to zero,
and we prohibit the callback from accessing the app shell if there are
no outstanding events. This solution is analogous to dropping the extra
reference counting, but avoids potential badness if we do wind up
processing native events after the app shell is destroyed.
Same approach as the other bug, mostly replacing automatically by removing
'using mozilla::Forward;' and then:
s/mozilla::Forward/std::forward/
s/Forward</std::forward</
The only file that required manual fixup was TestTreeTraversal.cpp, which had
a class called TestNodeForward with template parameters :)
MozReview-Commit-ID: A88qFG5AccP
We expose the relevant APIs on textarea and input elements anyway
(chromeonly). The QIs will throw on a non-input or non-textarea element, but
none of these consumers expect that to happen.
This was done automatically replacing:
s/mozilla::Move/std::move/
s/ Move(/ std::move(/
s/(Move(/(std::move(/
Removing the 'using mozilla::Move;' lines.
And then with a few manual fixups, see the bug for the split series..
MozReview-Commit-ID: Jxze3adipUh
Any more specific work that is happening in these methods will have its own
specific category labeling in that specific code. The instances touched in this
patch are more on the outside and don't really know what kind of code is going
to be running inside.
MozReview-Commit-ID: 47NO1DZzkdH
--HG--
extra : rebase_source : 35362bc94068103367f46b23a14cb3831cd86990
Categories are useful to indicate: This much % of time was spent in this category.
The EVENTS category isn't a very good match for this. This category is currently
only set on labels of functions that handle the processing of an event. But
those functions are usually closer to the base of the stack, and the actual CPU
work during the processing of an event is usually in another category closer to
the top of the stack, e.g. in JS if we're running an event handler, or in LAYOUT
if we're hit testing the position of the event.
This changeset removes the EVENTS category and replaces all uses of it with the
OTHER category.
MozReview-Commit-ID: JPm5hQiBkvp
--HG--
extra : rebase_source : 34fb2ca94151403a6d7ffd5a8b840f00a8bb4afb
In the case of a long-tap touch sequence, a new popup window (the
contextmenu) is spawned while the sequence is ongoing. The touch-end of
the sequence ends up getting delivered to the popup window, instead of
the original content window, and that causes the touch-handling
machinery state in the content window to get out of sync with reality.
This patch detects this scenario and redirects the touch events on the
popup window back to the original content window.
MozReview-Commit-ID: L2vvKLlogRA
--HG--
extra : rebase_source : fd4c36c93e45d05155d415f6470e12979b9a675b
If a key combination causes text input, we need to dispatch keypress
events without alt/ctrl/meta modifiers since TextEditor won't handle
keyepress events whose altKey, ctrlKey or metaKey is true as inputting
text.
Currently, TextEventDispatcher sets mCharCode of eKeyPress event from
mKeyValue. Then, when altKey, ctrlKey or metaKey is true, it'll call
WillDispatchKeyboardEvent() and then, TextInputHandler needs to reset
the charCode value from native event information.
However, the problem is, TextInputHandler::InsertText() is called
with control character when control key is pressed and InsertText()
clears the modifier information before sending eKeyPress event to
TextEvenDispatcher so that TextEventDispatcher won't call
WillDispatchKeyboardEvent() even though control key is actually
pressed. Therefore, TextInputHandler cannot adjust charCode value
and modifier flags in some cases such as control + option + 'a'.
This patch makes InsertText() stop clearing the modifiers and
makes WillDispatchKeyboardEvent() do it instead. This procedure
is expected by TextEventDispatcher.
MozReview-Commit-ID: Ig6qgRBeQDh
--HG--
extra : rebase_source : 446e8af0e921946f3409d26ede70446248317673
On macOS, option key is mapped to alt key, and it works like AltGr key on
the other platforms. Since our editor doesn't accept keypress events as
typing printable character if one of altKey, ctrlKey and metaKey of the
events is true, widget for macOS sets those attributes to false when an
editor has focus. On the other hand, if no editor has focus, our widget
does not do this hack so that altKey and ctrlKey values of keypress events
are always same as actual user operation and this is same behavior as the
other browsers. Therefore, we need to keep setting altKey of keypress
events to true if no editor has focus but we need to dispatch keypress
events even on content unless the charCode is 0.
So, only on macOS, WidgetKeyboardEvent::IsInputtingText() does not need
to check altKey state.
MozReview-Commit-ID: 4DMgdOfLqvQ
--HG--
extra : rebase_source : 18db91c0d77c6910a206e6c767e6f3b5cfd1c2ab
Fairly straightforward, just a blanket removal. Haven't heard
anything on dev-platform or fx-data-dev regarding this removal,
so I think it's likely safe to remove on Nightly, and we can
revert if anyone makes a fuss.
As part of removing the HangMonitor, I renamed a few things and
reorganized the namespaces to not depend on a HangMonitor
namespace. Hopefully this doesn't produce too much noise in the
diff, it just seemed appropriate to move everything around
rather than keep dangling vestiges of the old system.
MozReview-Commit-ID: 8C8NFnOP5GU
--HG--
extra : rebase_source : a8840bd26f4b01b756ffa72345ababb625048550
Fairly straightforward, just a blanket removal. Haven't heard
anything on dev-platform or fx-data-dev regarding this removal,
so I think it's likely safe to remove on Nightly, and we can
revert if anyone makes a fuss.
As part of removing the HangMonitor, I renamed a few things and
reorganized the namespaces to not depend on a HangMonitor
namespace. Hopefully this doesn't produce too much noise in the
diff, it just seemed appropriate to move everything around
rather than keep dangling vestiges of the old system.
MozReview-Commit-ID: 8C8NFnOP5GU
--HG--
extra : rebase_source : 59e4a6ced7d14d2a01c0b79e944078ea84cae523
Kartikaya Gupta
Martin Stransky
Joel Maher
Bogdan Tara
Masayuki Nakano
Chris Peterson
Coroiu Cristina
Dan Glastonbury
Ting-Yu Chou
Randall Barker
Cosmin Sabou
Miko Mynttinen
arthur.iakab
Andreea Pavel
Mats Palmgren
Emilio Cobos Álvarez
Boris Zbarsky
Csoregi Natalia
Noemi Erli
Markus Stange
Xidorn Quan
Dorel Luca
Doug Thayer
Brendan Dahl
Tooru Fujisawa