When keyboard apz is disabled, we don't need to calculate focus targets and
we don't need to update focus state. It should be harmless even if it's done,
but I think it's good to not add something on this critical path that doesn't
do anything.
This commit also disable keyboard map generation in this case too for similar
reasoning. This has the side effect that you can't turn on keyboard apz without
doing a restart.
MozReview-Commit-ID: LxmofT2g7qs
--HG--
extra : rebase_source : 719d29efd80498b824fee03a5be1c1fd05c83074
extra : histedit_source : 7ad71a19782fc6dd203207afbdc7a73a936b3e04
Focus can change at any moment in a document. This causes non-determinism and
correctness problems for doing keyboard apz scrolling. To get around this, we
will maintain deterministic behavior for focus changes initiated by input events
and see if we can get away with more non-determinism for things like `setTimeout`
In order to do this, we disable async keyboard scrolling when an input event is
processed that could have a event listener. We then attach a sequence number to
that input event and dispatch it to content. In content, we record the highest
sequence number that we have processed from an event, and send that on each focus
update. Using this, we can determine in APZ if we have a current focus target or
if we are still waiting for an input event to be processed and focus to be
reconfirmed.
MozReview-Commit-ID: CWcu8YEFQz4
--HG--
extra : rebase_source : 8c54a619bd4f5ee892f0cc8768a10f3e1e4e0b59
extra : histedit_source : 601ca293a028787883841adc6b40e62c0cc829e5
This commit modifies PresShell and nsDisplayList to send a FocusTarget update on
every layer transaction. Ideally we would like to send updates as often as possible,
but this seems like it works well. This can be iterated on later, if necessary.
MozReview-Commit-ID: 8PFqIOhzH77
--HG--
extra : rebase_source : 1e2c3b5620f5d7e6e789848da57b2486c3d74f14
This commit begins the work needed for tracking focus by creating two new classes,
FocusTarget and FocusState. FocusState is created and used by APZCTreeManager to
track the global focus information, while FocusTarget is created per layer tree and
sent to APZ with local focus information. Between the two we are able to figure out
what the correct scrollable layer is to use in response to a keyboard scroll.
See the comment in `FocusState.h` for more details on the architecture and things
needed in future patches to complete this.
MozReview-Commit-ID: F75VZv3i9U2
--HG--
extra : rebase_source : 3d04bced8e13a9884f0c1b320bad8ba2205d7011
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
This patch reduces the differences between builds where the profiler is enabled
and those where the profiler is disabled. It does this by removing numerous
MOZ_GECKO_PROFILER checks.
These changes have the following consequences.
- Various functions and classes are now defined in all builds, and so can be
used unconditionally: profiler_add_marker(), profiler_set_js_context(),
profiler_clear_js_context(), profiler_get_pseudo_stack(), AutoProfilerLabel.
(They are effectively no-ops in non-profiler builds, of course.)
- The no-op versions of PROFILER_* are now gone. The remaining versions are
almost no-ops when the profiler isn't built.
--HG--
extra : rebase_source : 8fb5e8757600210c2f77865694d25162f0b7698a
It appears that neither Chrome, Safari or Edge support this feature,
and it's causing web-compat issues for us, e.g. bug 1373417.
MozReview-Commit-ID: AP5LMgL6QmR
This patch does the following renamings, which increase consistency.
- GeckoProfilerInitRAII -> AutoProfilerInit
- GeckoProfilerThread{Sleep,Wake}RAII -> AutoProfilerThread{Sleep,Wake}
- GeckoProfilerTracingRAII -> AutoProfilerTracing
- AutoProfilerRegister -> AutoProfilerRegisterThread
- ProfilerStackFrameRAII -> AutoProfilerLabel
- nsJSUtils::mProfilerRAII -> nsJSUtils::mAutoProfilerLabel
Plus a few other minor ones (e.g. local variables).
The patch also add MOZ_GUARD_OBJECT macros to all the profiler RAII classes
that lack them, and does some minor whitespace reformatting.
--HG--
extra : rebase_source : 47e298fdd6f6b4af70e3357ec0b7b0580c0d0f50
Delete the NS_WARNING because it's not needed once this bug is fixed.
MozReview-Commit-ID: Ht3ayjSvYW8
--HG--
extra : rebase_source : 457f011ac64fcd511ec2f15ea2b8ce24a88b0d84
As I've said before, as module owner I prefer that MOZ_ASSERT_IF not be
used in the module because I consider it to be unreadable. However, a
few uses have crept in, and this patch removes them.
I consider it to be unreadable because the name looks like a name that
uses smalltalk-ish naming conventions, i.e., with a part of the name
corresponding to each parameter, in order. However, the parameters are
in the order opposite the name.
This was written primarily with the vim commands:
:%s/MOZ_ASSERT_IF(\([^,]*\),/MOZ_ASSERT(!\1 ||/
:wn
followed by manual cleanup for indentation and removal of !!.
MozReview-Commit-ID: G6rLbOn7k8d
I plan to use it for now to force a full document restyle when a standalone rule
changes or something like that.
In practice, we can do better sometimes, and we may just want to propagate to
the StyleSet all the style change notifications in order to have access to the
rule that changed and all that...
But for now this seemed easier than adding other four or five functions to
StyleSetHandle.
MozReview-Commit-ID: 2BEIliGu4mO
--HG--
extra : rebase_source : 386a1b9fe5ffc5fefbf20678068573ea195043f0
I plan to use it for now to force a full document restyle when a standalone rule
changes or something like that.
In practice, we can do better sometimes, and we may just want to propagate to
the StyleSet all the style change notifications in order to have access to the
rule that changed and all that...
But for now this seemed easier than adding other four or five functions to
StyleSetHandle.
MozReview-Commit-ID: 2BEIliGu4mO
--HG--
extra : rebase_source : 926f8442fbd17c7ffa7f72b6b4a515a28b9aa18b
The ignore-root-scroll-frame flag is generally needed on Fennec, or possibly
other zoom-enabled platforms, when we have them. It allows hit-testing things
outside the main thread's notion of what is visible, because that might occur
when the user zooms out.
For largely historical reasons, we are passing this flag around in other scenarios,
such as when doing hit-tests for touch events, because in the past touch events
and zooming only happened on Fennec, so it didn't matter. Now that we have
touch events enabled on other platforms, such as Windows, we need to make the
distinction clearer.
MozReview-Commit-ID: BlHjtjFYgzv
--HG--
extra : rebase_source : cbfeab4666b5556ba0b38f3abdf666d63945b9a1
The difference is that PostRestyleEventForCSSRuleChanges sets
mRestyleForCSSRuleChanges true. In a subsequent patch,
we propagate a new TraversalRestyleBehavior flag to servo side
if mRestyleForCSSRuleChanges is true.
MozReview-Commit-ID: IKsBbm09uT9
--HG--
extra : rebase_source : 5014c0a978f98e81543ec7766d2daa415317069c
We need to request an animation-only restyle to force flush all throttled
animations on main thread when we handle an event with coordinates
(e.g. mouse event).
MozReview-Commit-ID: KkjeQVsLgTl
--HG--
extra : rebase_source : 314408062e719e9f52df9a6726e2f3dad817bbef
This patch aims to speed up the lookup and storage of DisplayItemData objects, by removing a level of indirection and preventing the previously required hashtable lookup in order to access these. Instead it stores an array of pointers on each frame that allows direct access to the DisplayItemData object by dereferencing the frame. Since most frames get either 1 or 2 DisplayItemData objects attached to them a specialized class is used that is of minimal size (2 * sizeof(void)) and that performs well for sizes 1 or 2.
MozReview-Commit-ID: HONKAmpk5H8
There are situations where events may be handled out-of-order. Allow
coalescing to happen backwards in time as well as forwards to cover them.
MozReview-Commit-ID: 3k7vNFxE1cz
--HG--
extra : rebase_source : 636a3671536747cf62cb410836b4c5a2275bbb49
