`PresShell::EventHandler::HandleEventInternal()` may handle `Escape` key before
dispatching it in some cases. This requires too many lines for somebody who
investigate the method for the other events. Therefore, this patch moves it
into the new method.
Additionally, this patch creates `WidgetKeyboardEvent::CanTreatAsUserInput()`
and `WidgetKeyboardEvent::ShouldInteractionTimeRecorded()` because we should
manage similar checks in one place (we already have
`WidgetKeyboardEvent::CanUserGestureActivateTarget()`). Finally, their
conditions are not enough for what the comment wants to do there since they do
not check some modifier keys. Therefore, this patch makes them check all
possible modifier keys too.
Differential Revision: https://phabricator.services.mozilla.com/D21340
--HG--
extra : moz-landing-system : lando
The first switch statement of `PresShell::EventHandler::HandleEventInternal()`
has 2 jobs:
- Prepare something for specific event type.
- Record the preparation time of some types of events to telemetry.
This intermixed code is not easy to understand and somebody may add new
preparation after recording them. So, even though the preparation time
becomes worse a couple of nanoseconds, we should split those jobs.
The patch moves the latter job into the new method.
Differential Revision: https://phabricator.services.mozilla.com/D21339
--HG--
extra : moz-landing-system : lando
Oddly, there are two trusted eMouseMove preparation code in
`PresShell::EventHandler::HandleEventInternal()`. One is in the `switch`
statement which is used only when `aEvent` is trusted. The other is after
`TouchManager::PreHandleEvent()` is called and after
`AutoHandlingUserInputStatePusher` is created. However, both of them do
nothing if the event is `eMouseMove`. Therefore, we can move the latter
into the former.
Differential Revision: https://phabricator.services.mozilla.com/D21338
--HG--
extra : moz-landing-system : lando
I wrote this patch by first removing UNIFIED_ from layout/style/moz.build, and
then rebuilding, and then addressing build errors one by one.
Nearly all of the build errors were for using the "Document" type without a
proper namespace, and I've addressed this by sprinkling "using namespace"
declarations in the affected .cpp files (and removing a few now-unnecessary
dom:: prefixes on types in those files).
The only other errors were for WorkletGlobalScope.h which needed an #include to
provide the type "DOMHighResTimeStamp", and nsHTMLStyleSheet.h which needed a
forward-declaration for the type "mozilla::dom::Document".
Differential Revision: https://phabricator.services.mozilla.com/D22767
--HG--
extra : moz-landing-system : lando
Actually the function will fail on Android since on xpcshell tests we don't
initialize AndroidBridge so that we can't query the corresponding system
settings.
Differential Revision: https://phabricator.services.mozilla.com/D22270
--HG--
extra : moz-landing-system : lando
You can mess up stuff pretty badly if that happens, and we want to do this
anyway for the shared UA sheet stuff, so...
Differential Revision: https://phabricator.services.mozilla.com/D22554
--HG--
extra : moz-landing-system : lando
These were rendering as blank with container scrolling, and their failure with
containerless scrolling is caused by an unrelated viewport bug, tracked in
bug 1527511.
Differential Revision: https://phabricator.services.mozilla.com/D19681
--HG--
extra : moz-landing-system : lando
Manual testing shows expected rendering of the pages in question. The tests
do not reproduce locally and are tricky to debug on Try. Moreover, most
other reftests in this directory are already marked as failing or random
on Android.
For these reasons, I don't want these failures to block the rollout of
containerless scrolling. Bug 1084564 tracks re-enabling them.
Differential Revision: https://phabricator.services.mozilla.com/D19679
--HG--
extra : moz-landing-system : lando
The Timestamp implementation on Windows seems to be based off of two system APIs: GetTickCount64 and QueryPerformanceCounter. QPC seems to be preferred over GTC, unless a "failure" in QPC is detected.
There is code in the Timestamp implementation to detect if QPC "fails" be comparing elapsed time of QPC to elapsed time of GTC.
Through logging on try server I observed the following in different failures:
1) the QPC failure detection kicks in a lot and disables use of QPC
2) the QPC of the vsync timestamp was in the future compared to the QPC of TimeStamp::Now().
3) the QPC of TimeStamp::Now() was missing (presumably because it was disabled) and the GTC of the vsync timestamp was in the future compared to the GTC of TimeStamp::Now()
4) the vsync timestamp printf of raw GTC and QPC values matched at the source (SoftwareDisplay::NotifyVsync) and in the refresh driver, so the vsync timestamp wasn't getting messed up.
I guess we could spend more time on the error detection in our Windows TimeStamp code, but this failure is only happening on 32-bit machines.
Here's a patch to disable the assertions on 32-bit Windows. Depends how important we think this assertion is relative to the work to investigate more.
Differential Revision: https://phabricator.services.mozilla.com/D22453
--HG--
extra : moz-landing-system : lando
The only fishy bit is the animation stuff. In particular, there are two places
where we just mint the revert behavior:
* When serializing web-animations keyframes (the custom properties stuff in
declaration_block.rs). That codepath is already not sound and I wanted to
get rid of it in bug 1501530, but what do I know.
* When getting an animation value from a property declaration. At that point
we no longer have the CSS rules that apply to the element to compute the
right revert value handy. It'd also use the wrong style anyway, I think,
given the way StyleBuilder::for_animation works.
We _could_ probably get them out of somewhere, but it seems like a whole lot
of code reinventing the wheel which is probably not useful, and that Blink
and WebKit just cannot implement either since they don't have a rule tree,
so it just doesn't seem worth the churn.
The custom properties code looks a bit different in order to minimize hash
lookups in the common case. FWIW, `revert` for custom properties doesn't seem
very useful either, but oh well.
Differential Revision: https://phabricator.services.mozilla.com/D21877
--HG--
extra : moz-landing-system : lando
`PresShell::EventHandler::HandleEventInternal()` needs to accumulate event
handling time per each event type. The handling start time needs to be
recorded before sending EventStateManager. Therefore, this patch makes the
helper class which is a stack class, records current time at construction
and calls `Telemetry::AccumulateTimeDelta()` at destruction automatically.
Differential Revision: https://phabricator.services.mozilla.com/D21335
--HG--
extra : moz-landing-system : lando
We always pass the same set of types so it seems simpler to just look it up
within the function itself.
Differential Revision: https://phabricator.services.mozilla.com/D22444
--HG--
extra : moz-landing-system : lando
If `aEvent` requires frame but there is no event target,
`PresShell::EventHandler::HandleEventInternal()` just records the response
time. So, we can reduce one indent level in the big method.
Note that I'm not sure recording the response time in such case because
the *good* values may make the average and median better. But this is
out of scope of bug 1466208.
Differential Revision: https://phabricator.services.mozilla.com/D21336
--HG--
extra : moz-landing-system : lando
This was introduced in bug 726817 for B2G stuff and there is no call site of
SetClampScrollPosition now and the only one entry point to call the function
was nsIFrameLoader.clampScrollPosition which was removed in
https://hg.mozilla.org/mozilla-central/rev/cd9aace7bb96 .
ScrollFrameHelper::ShouldClampScrollPosition() had always returned true in both
cases of root and non-root scrollable frames. (In the case of non-root
scrollable, nsFrameLoader.mClampScrollPosition is initially set to true and
nobody changes the value)
Differential Revision: https://phabricator.services.mozilla.com/D22026
--HG--
extra : moz-landing-system : lando
`PresShell::EventHandler::HandleEventInternal()` recodes event handling
response performance with telemetry after it dispatches the event. We can move
it into new method simply.
Differential Revision: https://phabricator.services.mozilla.com/D21334
--HG--
extra : moz-landing-system : lando
The existing linear gradient shader is quite slow, especially
on very large gradients on integrated GPUs.
The vast majority of gradients in real content are very simple
(typically < 4 stops, no angle, no repeat). For these, we can
run a fast path to persist a small gradient in the texture cache
and draw the gradient via the image shader.
This is _much_ faster than the catch-all gradient shader, and also
results in better batching while drawing the main scene.
In future, we can expand the fast path to handle more cases, such
as angled gradients. For now, it takes a conservative approach,
but still seems to hit the fast path on most real content.
Differential Revision: https://phabricator.services.mozilla.com/D22445
--HG--
extra : moz-landing-system : lando
Calling getComputedStyle on an element outside of the document always returns
the empty string since bug 1511138, so we were incorrectly thinking that the
initial font-family was serif when it was not.
I chose a <meta> element instead of a <div> because they're undisplayed and they
don't cause the <body> of the document to start (though I _think_ that only
happens from the parser).
In any case I'm pretty surprised this didn't cause issues in other tests...
Differential Revision: https://phabricator.services.mozilla.com/D22604
--HG--
extra : moz-landing-system : lando
If `Shift` state of `eContextMenu` event is active, we make it not fired on
web content. Additionally, if it's not time to open context menu, we shouldn't
dispatch it into the DOM. The new method prepare and check them.
Differential Revision: https://phabricator.services.mozilla.com/D21337
--HG--
extra : moz-landing-system : lando