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 : dd000a05bfc2da40c586644d33ca4508fa5330f6
When only a part of window is updated we need to clip that drawing.
We use image surface for that as WindowSurfaceX11Image does.
MozReview-Commit-ID: 13znE1ZszB8
--HG--
extra : rebase_source : a236799fa33d73037913df94c0d5e619c5d3c47e
Right now we use the "tab-child-created" notification to attach
GeckoEditableSupport to a PuppetWidget in the child process. However,
"tab-child-created" is not fired for all instances of PuppetWidget
creation, and attaching GeckoEditableSupport at this stage can also
cause race conditions.
This patch makes us listen to "content-document-global-created" instead,
but attach GeckoEditableSupport to the PuppetWidget the same way.
MozReview-Commit-ID: 8IAtzuvlK4K
--HG--
extra : rebase_source : 50e4f05bccd06d301a2c2b1464666e5e1a58b3b2
Right now we coalesce notifyIMEContext calls but only for legacy
reasons. With the current code we don't want to coalesce calls, in order
to be properly notified of blurring and focusing.
MozReview-Commit-ID: 6N2jhyyBKui
--HG--
extra : rebase_source : 0a488a726b834da4f6124092426638f4be368d43
Right now we always notify Java of input blur. However, when input is
rapidly blurred and then focused again, we don't want to generate the
unnecessary blur notification, in order to avoid unwanted effects such
as the keyboard flashing.
MozReview-Commit-ID: AL6aLAHqNpD
--HG--
extra : rebase_source : c0a6a731f95f997a7a8e19eacdb635f99d21ebf5
Some InputContext members are not forwarded through
PBrowser::SetInputContext.
MozReview-Commit-ID: C1bGYq4w8zT
--HG--
extra : rebase_source : 1481f08c7593fe9dceb3b96bbfe480a1c58ecf9d
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
