The events being listened for here are mouse events, all of which
go through both the bubble and capture phases. It's not clear to
me why I originally added this listener in the capture phase; it
is more useful in the bubble phase because then it resolves the
promise after the event has triggered listeners registered on the
target element, rather than before.
Note also that prior to the promis-ification of this function, the
callback was called inside a setTimeout(0) wrapper, which would
automatically have deferred the callback to after the event dispatch
was completed. So technically the promis-ification of this function
introduced a functional change because now the promise can get
resolved before the event dispatch is complete, and in particular,
before listeners on the target element get run. This didn't affect
anything in practice because none of the existing callers actually
have such a listener on the target element. The next patch adds
one though, and exposed this behaviour difference when I rebased it
across the promis-ification change..
This patch removes the capture:true listener option, causing the
listener to get registered in the bubble phase.
Differential Revision: https://phabricator.services.mozilla.com/D112500
An apzc could have moved to inside an async zoom container.
In the failing test we did a paint while painting was suppressed, so our display list had exactly one item: a nsDisplaySolidColor. The layer tree still got tagged with metrics and so the apzc was attached. Then the zoom constraints client does it's before first paint update which is triggered when we unsuppress painting. It finds no async zoom container so it does nothing. Then we do a regular paint, with an async zoom container this time. We find the apzc from the previous paint, so we don't update the zoom contraints.
Differential Revision: https://phabricator.services.mozilla.com/D112555
This also fixes a bug where root content xul docs had zoom constraints that allowed them to be zoomed. This would cause a crash because we would ask for a repaint request and it would get routed to APZCCallbackHelper::UpdateRootFrame (because it has the id of the document element), which assumes the existance of a root scroll frame.
Differential Revision: https://phabricator.services.mozilla.com/D112486
Also rename IsAsyncZoomContainer to GetAsyncZoomContainerId, since it returns a maybe this serves both purposes.
We need this for the next patches.
Differential Revision: https://phabricator.services.mozilla.com/D112484
This also fixes a bug where root content xul docs had zoom constraints that allowed them to be zoomed. This would cause a crash because we would ask for a repaint request and it would get routed to APZCCallbackHelper::UpdateRootFrame (because it has the id of the document element), which assumes the existance of a root scroll frame.
Differential Revision: https://phabricator.services.mozilla.com/D112486
Also rename IsAsyncZoomContainer to GetAsyncZoomContainerId, since it returns a maybe this serves both purposes.
We need this for the next patches.
Differential Revision: https://phabricator.services.mozilla.com/D112484
This is not strictly necessary (but a later patch would need to be modified slightly to get the presshellid).
But we can potentially pull zoom constraints from the apzc map, which is presshellid ignoring, so it seems better to have them in-sync, and I couldn't find a reason why zoom constraints needs to be presshellid respecting.
Depends on D112315
Differential Revision: https://phabricator.services.mozilla.com/D112316
This is accomplished by the overscroll transform being part of the visual
component of the root content APZC's async transform.
We were already doing this right in AsyncPanZoomController (as of bug
1699868), but the call sites in AsyncCompositionManager needed to be
updated.
Differential Revision: https://phabricator.services.mozilla.com/D112221
This test fails in automation, but those failures are difficult to reproduce
in local builds. When attempting to reproduce locally, the whole test sometimes
times out. Isolating specific subtests seems to affect the test outcomes as
well. Splitting the test into pieces seems to be the best way to make failures
in this test more actionable.
Differential Revision: https://phabricator.services.mozilla.com/D111167
This change makes us match Chrome's overscroll behavior (i.e. restoring
overscroll state on an axis while scrolling by pan momentum keeps going on the
other axis).
Basic mechanisms to do the behavior are;
a) if there is an on-going overscroll animation on an axis and the overscroll
direction is opposed to the momentum direction, stop the overscroll animation
immediately and keep the momentum scroll (or overscroll and scroll if the
current position is in overscroll gutter).
b) if there is an on-going overscroll animation on an axis and the overscroll
direction is same as the momentum direction, drop the momentum and keep
the animation overscrolling.
c) if there is an on-going overscroll animation on an axis and no overscroll
animation on the other axis and if a pan momentum event overscrolls on
the other axis, start a new overscroll animation on the axis.
With this change there still remains a (relatively) less noticeable issue that
pan momentum scrolling on an axis stops immediately after the other axis
overscroll animation stopped. For example, given that there is a horizontal
overscroll animation and vertical pan momentums keep going, subsequent vertical
pan moments after the horizontal overscroll animation finished will be discarded
since we do set the APZC state to NOTHING in
AsyncPanZoomController::UpdateAnimation(). To fix this issue we need to handle
OVERSCROLL_ANIMATION separately from the others, in the example case, once after
the overscroll animation finished, the state should be MOMENTUMPAN, thus we can
keep consuming momentum events as scroll. That said, the fix will not be easy,
because there are also cumbersome cases where we don't want to keep consuming
the events, one of the cases is b) in the basic mechanisms above, in the case
we do want to discard incoming momentum events after the overscroll animation
finished if the incoming momentum events are in the initial overscroll gutter,
IF the incoming momentum events are in the another edge of the overscroll
gutter, we have to re-initiate a new overscroll animation in the other side
gutter. We will handle these cases in a followup bug (bug 1702949).
Differential Revision: https://phabricator.services.mozilla.com/D110794
This is a prerequisite change to keep momentum scrolls happening on the other
axis where no overscroll animation is running.
Differential Revision: https://phabricator.services.mozilla.com/D110793
By resolving the relevant promises, instead of crashing (and if we
didn't crash we'd leave the window registered as a refresh driver
observer, which would be bad).
I wanted to reject them, since that's what we do when the page has no
pres shell, but that'd make this test fail:
https://searchfox.org/mozilla-central/rev/d8194cbbeaec11962ed67f83aea9984bf38f7c63/dom/base/test/browser_promiseDocumentFlushed.js#165-186
For this, we modify the OneShotPostRefreshObserver API to be more
generic (and rename it OneShotManagedRefreshObserver).
We fix APZ's usage of this API, which was doing something extremely
weird (returning a refcounted object in a UniquePtr). This seems like an
artifact from recent OneShotPostRefreshObserver cleanup.
Differential Revision: https://phabricator.services.mozilla.com/D111851
This test fails in automation, but those failures are difficult to reproduce
in local builds. When attempting to reproduce locally, the whole test sometimes
times out. Isolating specific subtests seems to affect the test outcomes as
well. Splitting the test into pieces seems to be the best way to make failures
in this test more actionable.
Differential Revision: https://phabricator.services.mozilla.com/D111167
This test fails in automation, but those failures are difficult to reproduce
in local builds. When attempting to reproduce locally, the whole test sometimes
times out. Isolating specific subtests seems to affect the test outcomes as
well. Splitting the test into pieces seems to be the best way to make failures
in this test more actionable.
Differential Revision: https://phabricator.services.mozilla.com/D111167
This test fails in automation, but those failures are difficult to reproduce
in local builds. When attempting to reproduce locally, the whole test sometimes
times out. Isolating specific subtests seems to affect the test outcomes as
well. Splitting the test into pieces seems to be the best way to make failures
in this test more actionable.
Differential Revision: https://phabricator.services.mozilla.com/D111167
If we double tap on an element that is narrower than the viewport at maximum we can get into a situation where we zoom on part (say the bottom half) of that element but we could easily fit the entire element.
This happens because the code that calculate the rect to zoom to (CalculateRectToZoomTo) doesn't know about the maximum zoom. So it proceeds as though we will fit the width of the element. Under that assumption we will have to cut off part of the element vertically, so the code centers the rect on the users tap point.
This ends up cutting off part of the element vertically when it is clear that the whole element can fit on screen, which is a pretty ugly result.
This is not my favourite patch. This seemed to make the most sense. Another option I considered was passing the tap point through to AsyncPanZoomController::ZoomToRect but I think this approach came out better: the calculation all happens in one place at one time.
Differential Revision: https://phabricator.services.mozilla.com/D110538
No reason to only wait for the controller, I think we want to wait for the full repaint. Seems to make things less intermittent, the test in bug 1702464 was already using this.
Differential Revision: https://phabricator.services.mozilla.com/D111554
This test fails in automation, but those failures are difficult to reproduce
in local builds. When attempting to reproduce locally, the whole test sometimes
times out. Isolating specific subtests seems to affect the test outcomes as
well. Splitting the test into pieces seems to be the best way to make failures
in this test more actionable.
Differential Revision: https://phabricator.services.mozilla.com/D111167
I'm not sure if this is better overall or not, it's better for the testcase in this bug (a div with a large amount of visible overflow).
This code is a direct port of javascript code, so it only had the option of using getBoundingClientRect.
Differential Revision: https://phabricator.services.mozilla.com/D110534
I'm not sure if this is better overall or not, it's better for the testcase in this bug (a div with a large amount of visible overflow).
This code is a direct port of javascript code, so it only had the option of using getBoundingClientRect.
Differential Revision: https://phabricator.services.mozilla.com/D110534
We already vertically center the rect, but not horizontally. We generally try to zoom to the width of an element already, so the width of the zoom to rect will usually occupy the whole viewport and hence be centered. But if the width of the element is too small so that we can't zoom in so that it fills the viewport it will end up left aligned. This doesn't come up very often on mobile, but happens more so on desktop.
Differential Revision: https://phabricator.services.mozilla.com/D110063
The specific case that motivated this was text areas, but in bug 1700535 we changed those to inline block to match all other input elements and other browsers.
Bug 1539469 changed all inputs to inline-block based on the spec discussion https://github.com/whatwg/html/issues/4082 but textarea's were not part of that.
<img> elements remain as inline though, and we probably do want to zoom to them (and they are replaced), so this change is still desirable.
Differential Revision: https://phabricator.services.mozilla.com/D109574
The code as is doesn't make sense, comparing the height of the unrounded rect to the rounded rect is not a useful thing to do here. To understand we need to look at the history of this code.
Introduced in https://hg.mozilla.org/mozilla-central/rev/e8049b1a59263e10a53527b77d3be636c8b07813 "Implement double-tap-to-zoom content". We see that we are comparing bRect.height to rect.h, bRect is the bounding client rect of the element to zoom to (plus margin), rect is bRect rounded with one important difference: the height of rect is Math.min(bRect.width * viewport.height / viewport.height, bRect.height). This code has a bug in that viewport.height / viewport.height should be viewport.height / viewport.width. This code is intending to shrink the height of bRect so rect has the same aspect ratio as the viewport. So now the comparison of bRect.height and rect.h makes sense: it is checking if we shrunk the bRect vertically to match the aspect ratio. So the code was broken from the initial landing.
Then https://hg.mozilla.org/mozilla-central/rev/83bf684a81e99726c5783a788e360c84651ef925 landed which removed the aspect ratio calculation and made rect just bRect rounded.
And then https://hg.mozilla.org/integration/mozilla-inbound/rev/4b0ef3b98b72 faithfully ports the broken code to C++.
And then https://hg.mozilla.org/mozilla-central/rev/a404231c514a implements the aspect ratio calculation properly without realizing there was buggy code already in the tree attempting to do the same.
Depends on D110535
Differential Revision: https://phabricator.services.mozilla.com/D110536
This test was added by bug 1660932 that zoomToFocusedInput scrolls visible position on multi line control.
As workaround of test failure on GV, I would like to set initial scale to 1.
Differential Revision: https://phabricator.services.mozilla.com/D110509
If the function returns a transform that includes an overscroll transform,
the out-parameter is populated with the APZC which is the source of the overscroll.
This is mostly for convenience, to avoid the caller having to duplicate
the logic for this (which is somewhat nontrivial as the overscroll transform
is part of the visual component of the async transform, which for the root
content APZC is lifted from the APZC's node to the async zoom container node).
Differential Revision: https://phabricator.services.mozilla.com/D110184
This is the portion that applies to fixed content as well, and we do want
the overscroll transform to apply to fixed content.
Differential Revision: https://phabricator.services.mozilla.com/D110183
This patch makes two improvements:
1. The function no longer assumes that the point, disregarding the
overscroll transform, is inside the composition bounds. It now
checks for this as well.
2. A ParentLayerPoint overloaded is added, such that if we already
have the hit-test point available in APZC coordinates, we don't
have to convert it again.
Differential Revision: https://phabricator.services.mozilla.com/D110182
To trigger the failure more reliably, wait for a frame between sending
the synthesized events, so that events and content responses
interleave more.
Also, send some smaller deltas so they fall under the threshold where
a naively computed mLineOrPageDeltaY might be zero.
Differential Revision: https://phabricator.services.mozilla.com/D110008
This way, tests which specifically want to test overscroll can set the
pref explicitly, and other tests need not worry about accidentally
going into overscroll.
Differential Revision: https://phabricator.services.mozilla.com/D109435
The widget for popup window on Mac is nsCocoaWindow which doesn't have
any APZC instances so that nsIWidget::AsyncPanZoomEnabled() always returned
false, we need to delegate the call to the nsChildView.
To be honest, I am quite unsure whether other functions using APZC also need
to be delegated or not, but I haven't noticed any issues now, so we will
fix one by one if there are any other issues.
Unfortunately the mochitest for this issue doesn't work both on Linux and
Windows, but it's presumably an issue in our testing machinery relevant with
nsIDOMWindowUtils.sendNativeMouseScrollEvent, it will not be a problem in the
wild because scrolling by real mouse wheel works fine there.
Differential Revision: https://phabricator.services.mozilla.com/D109572
This allows that code (and in the future, other code that needs
to run for every input type) to be in just one place.
Depends on D109460
Differential Revision: https://phabricator.services.mozilla.com/D109461
The automated tests become orange only in macOS and 32bit Windows builds. It
fails when left mouse button down is synthesized in the autoscroller (a XUL
`<panel>` element). Although I'm not sure why that depends on the platform,
APZ cancels active autoscrolling before dispatching `mousedown` event.
Therefore, `AutoScrollParent` nor `AutoScrollChild` cannot block the following
click event.
Therefore, this patch adds new field into `APZEventResult` and set it to `true`
when APZ runs `autoscroll` but canceled by a mouse input. Then, `nsBaseWidget`
can prevent following click event of `eMouseDown` and `eMouseUp` events as
expected before dispatching them into the DOM tree. (FYI: Preventing click
event of either `eMouseDown` or `eMouseUp` can prevent the following `click`
event, etc.)
Differential Revision: https://phabricator.services.mozilla.com/D107325
Everybody uses the promise-style equivalent so we can just move over
the documentation and drop the function.
Depends on D109248
Differential Revision: https://phabricator.services.mozilla.com/D109249
We can either get here via touch events interpreted as a double tap, or a double tap event sent from the os. The former will have a touch block, the latter will have no input block associated with it.
The crash shows it's possible to get here with another type of current input block.
The other option would be to ignore the double tap if we get here and there is a current input block that is not touch. Not sure if that is better or not.
Differential Revision: https://phabricator.services.mozilla.com/D108716
This test is not actually run in CI (disabled via mochitest.ini), so
this has zero effect. Even if it did run, the call to
synthesizeNativeWheelAndWaitForWheelEvent is not passing in a callback
function; it runs the following rAF line immediately. So calling the
function that "waits for the wheel event" is pointless, we can just
call the version that synthesizes the native wheel input and it is
functionally identical.
Depends on D108441
Differential Revision: https://phabricator.services.mozilla.com/D108442
These tests are too annoying to restructure completely, so I'm just
doing a local inlining of the function here.
Depends on D108438
Differential Revision: https://phabricator.services.mozilla.com/D108439
This restructures the test from a callback-style test into an async/await-style
test that is functionally equivalent.
Depends on D108437
Differential Revision: https://phabricator.services.mozilla.com/D108438
This restructures the test from a callback-style test into an async/await-style
test that is functionally equivalent.
Depends on D108436
Differential Revision: https://phabricator.services.mozilla.com/D108437
This restructures the test from a callback-style test into an async/await-style
test that is functionally equivalent.
Depends on D108435
Differential Revision: https://phabricator.services.mozilla.com/D108436
Creating an event with type NSEventTypeSmartMagnify does not work with either NSEvent mouseEventWithType or NSEvent otherEventWithType (they both hit an assert in the appkit code). So the best we can do is call the same function.
Differential Revision: https://phabricator.services.mozilla.com/D107792
We already have a pref for double tap to zoom with is already enabled by default so it's kind of awkward to add another pref.
Differential Revision: https://phabricator.services.mozilla.com/D107389
Bug 1357785 accidentally omitted the flag on the interface itself. This patch makes thing consistent to prevent potential confusion in feature detection.
Differential Revision: https://phabricator.services.mozilla.com/D107742
The test send two taps, which triggers a double tap zoom if it's enabled, and then the test doesn't get the expected events. So change the test to disable zooming and then enable the meta viewport pref so that we respect it on desktop.
Differential Revision: https://phabricator.services.mozilla.com/D107791
Bug 1357785 accidentally omitted the flag on the interface itself. This patch makes thing consistent to prevent potential confusion in feature detection.
Differential Revision: https://phabricator.services.mozilla.com/D107742
Previous fix of bug 1681211 waited for focus even if all tests were finished.
It caused that sendAsyncMessage may post the cleanup message after the window
is destroyed.
So I shouldn't wait for focus when all tests are finished.
Differential Revision: https://phabricator.services.mozilla.com/D107435
A smooth scroll request is a request to perform scrolling in the future, it does not indicate that the scroll offset has been updated. However we still need to run a few of the things from a scroll offset update.
This seems kind of fragile. We could have more bugs of this type, I didn't look for them or audit the code, but we should.
Differential Revision: https://phabricator.services.mozilla.com/D105280
We do want APZEventResult to have a valid mHandledResult in the case of
nsEventStatus_eConsumeDoDefault.
Note that when we call SetStatusAsConsumeDoDefault() with a InputBlockState,
in ReceiveScrollWheelInput() for example, we need to keep the block alive there,
so each block is now RefPtr-ed instead of a raw pointer in such functions (the
raw pointer is sometimes the active one (mActiveWheelBlock etc.) which will be
discarded in ProcessQueue()).
Differential Revision: https://phabricator.services.mozilla.com/D103417
The functions are supposed to work with both directions, downwards and upwards,
i.e., it returns true even if the dynamic toolbar is completely hidden and the
root APZC's scroll position is at the bottom edge (i.e. it's no longer
scrollable downwards), this is necessary because the toolbar should also be
moved by swipe-up motions in such situations.
Differential Revision: https://phabricator.services.mozilla.com/D103416
Thus, we can easily get more information from ReceiveInputEvent calls by adding
the information into APZEventResult such as overscroll-behavior etc. (instead
of adding more arguments to ReceiveInputEvent)
Differential Revision: https://phabricator.services.mozilla.com/D103414
The incoming aOutputHandledResult is set to `HandledByContent` in
HitTestResult::HandledByRoot() if the target APZC is not the root one, so it's
equivalent with the |!target->IsRootContent()| check in
InputQueue::ReceiveTouchInput() basically.
Differential Revision: https://phabricator.services.mozilla.com/D103412
Conceptually we should only sample APZ on frame build, never on scene
build. When a late scene build occured, this unnecessary sample was
the underlying cause of the non-monotonic sample times as seen in bug
1653796. The fix for bug 1653796 introduced non-vsync-aligned sample
times to work around this, but these lead to inconsistent scroll
deltas during fling animations, appearing as janky scrolling on
Android.
This patch fixes the underling issue, by removing the sample after
scene building. This means we no longer hit the case where sample
times are in the past after a late scene build, allowing us to revert
bug 1653796 to ensure that sample times remain vsync-aligned.
Differential Revision: https://phabricator.services.mozilla.com/D106414
Actually I disable test_group_zoomToFocusedInput.html with fission+xorign.
But I would like to turn on this again.
Although we call window.open after calling window.close for old test window,
new window by window.open don't take focus. This issue is bug 1695135.
It means that the following new window (w) doesn't take focus with fission+
xorign.
```
old_window.close();
let w = window.open("", "_blank");
```
So as workaround, we have to wait for getting focus on parent window after
test window is closed.
Differential Revision: https://phabricator.services.mozilla.com/D106609
We do want APZEventResult to have a valid mHandledResult in the case of
nsEventStatus_eConsumeDoDefault.
Note that when we call SetStatusAsConsumeDoDefault() with a InputBlockState,
in ReceiveScrollWheelInput() for example, we need to keep the block alive there,
so each block is now RefPtr-ed instead of a raw pointer in such functions (the
raw pointer is sometimes the active one (mActiveWheelBlock etc.) which will be
discarded in ProcessQueue()).
Differential Revision: https://phabricator.services.mozilla.com/D103417
The functions are supposed to work with both directions, downwards and upwards,
i.e., it returns true even if the dynamic toolbar is completely hidden and the
root APZC's scroll position is at the bottom edge (i.e. it's no longer
scrollable downwards), this is necessary because the toolbar should also be
moved by swipe-up motions in such situations.
Differential Revision: https://phabricator.services.mozilla.com/D103416
Thus, we can easily get more information from ReceiveInputEvent calls by adding
the information into APZEventResult such as overscroll-behavior etc. (instead
of adding more arguments to ReceiveInputEvent)
Differential Revision: https://phabricator.services.mozilla.com/D103414
The incoming aOutputHandledResult is set to `HandledByContent` in
HitTestResult::HandledByRoot() if the target APZC is not the root one, so it's
equivalent with the |!target->IsRootContent()| check in
InputQueue::ReceiveTouchInput() basically.
Differential Revision: https://phabricator.services.mozilla.com/D103412
For minimizing the previous patch changes, `scale`'s default value for
`screenX/Y` is treated as 1.0. It means that `screenX/Y` are device
pixels by default, but `offsetX/Y` are in CSS pixels by default. This
difference may make developers confused. Therefore, we should align the
default unit of them to `screenPixelsPerCSSPixel`. I.e., their default
unit becomes CSS pixels.
Differential Revision: https://phabricator.services.mozilla.com/D105929
For making the test framework/API change easier, such raw API shouldn't be
used directly. Therefore, this patch makes tests using it directly stop
using it and use `synthesizeNativeMouseEvent` instead.
However, this patch does not fix `browser_touch_event_iframes.js` because
it accesses the API from `ContentTask`. So, `EventUtils.js` isn't available
without larger change.
Note that this patch disables `test_bug596600.xhtml` because as I commented
in it, it's completely broken. It depends on the race of next native event
loop and `waitForTick`, and this patch changes the result of the race.
Differential Revision: https://phabricator.services.mozilla.com/D105765
Currently, it takes a raw native message value, but it makes JS content too
complicated. And on Linux, it cannot synthesize non-primary button events
because GDK has only button press and release messages which dont' include
mouse button information.
For solving these problems, this patch creates a new abstract native message
as `nsIWidget::NativeMouseMessage` and makes each widget converts it to
a platform native message.
Additionally, this patch adds an argument to make it possible its callers
to specify pressing or releasing mouse button with a DOM mouse button value.
Note that the following patch adds new argument to
`synthesizeNativeEventMouse*` for mochitests and which will be tested by
new tests.
Differential Revision: https://phabricator.services.mozilla.com/D105763
Let's make `synthesizeNativeMouseClick*` take an event type, and only when
it's click, it should send native mouse event twice.
Then, we can all them `synthesizeNativeMouseEvent*`.
Differential Revision: https://phabricator.services.mozilla.com/D105759
Surprisingly, they don't take modifiers, and
`nsIWidget::SynthesizeNativeMouseEvent()` which are implementations of
`nsIDOMWindowUtils::SendNativeMouseEvent()` treat given modifier flags
are native's ones, and handle modifiers only on macOS. Therefore, this
patch makes them handle native modifiers of Gecko.
Unfortunately, I'm not so familiar with Android API, and in the short
term, I don't need the support on Android. Therefore, this patch just
adds a TODO comment on Android widget.
Additionally, we don't have a simple way to set modifier only while
posting a mouse input on Windows too. It requires complicated code.
Therefore, I don't add the support for it on Windows too.
Differential Revision: https://phabricator.services.mozilla.com/D105758
Some tests want to specify screen position directly. Therefore, they should
have additional fields in the `Object` param to take offset in screen.
Differential Revision: https://phabricator.services.mozilla.com/D105757
With adding new feild to the `aParam`, `synthesizeNativeMouseClick` can
work as `synthesizenativeMouseClickAtCenter` too. Therefore, we can get
rid of the redundant API.
Additionally, this patch makes `synthesizeNativeMouseClickWithAPZ` can
take the new field for consistency between them.
Differential Revision: https://phabricator.services.mozilla.com/D105756
In these days, API should take an `Object` instead of multiple arguments
since the callers look like using "named" arguments and this allows to
add new optional arguments with changing not all callers.
This patch also changes similar API for APZ aware tests for keeping
consistent style for their users.
Differential Revision: https://phabricator.services.mozilla.com/D105755
We basically use a couple primitives to draw these
(PaintRoundedRectWithRadius, FillRect), so making the code a bit generic
implementing stuff with WebRender seems straight-forward.
I've kept using the fallback codepath for the bits that draw complex
paths like arrows and such, but the rest of the things should work with
this patch.
A thing I'm not too happy about is the scrollbar painting setup (requires a lot
of boilerplate), but modulo template hacks make nsNativeBasicTheme a template
that receives its super class as a parameter or something) it seems hard to do
better.
Differential Revision: https://phabricator.services.mozilla.com/D105931
We basically use a couple primitives to draw these
(PaintRoundedRectWithRadius, FillRect), so making the code a bit generic
implementing stuff with WebRender seems straight-forward.
I've kept using the fallback codepath for the bits that draw complex
paths like arrows and such, but the rest of the things should work with
this patch.
A thing I'm not too happy about is the scrollbar painting setup (requires a lot
of boilerplate), but modulo template hacks make nsNativeBasicTheme a template
that receives its super class as a parameter or something) it seems hard to do
better.
Differential Revision: https://phabricator.services.mozilla.com/D105931
We basically use a couple primitives to draw these
(PaintRoundedRectWithRadius, FillRect), so making the code a bit generic
implementing stuff with WebRender seems straight-forward.
I've kept using the fallback codepath for the bits that draw complex
paths like arrows and such, but the rest of the things should work with
this patch.
A thing I'm not too happy about is the scrollbar painting setup (requires a lot
of boilerplate), but modulo template hacks make nsNativeBasicTheme a template
that receives its super class as a parameter or something) it seems hard to do
better.
Differential Revision: https://phabricator.services.mozilla.com/D105931
imoraru
Timothy Nikkel
Botond Ballo
Kartikaya Gupta
Cosmin Sabou
smolnar
Brad Werth
Hiroyuki Ikezoe
Emilio Cobos Álvarez
Dorel Luca
Alexandru Michis
Noemi Erli
Butkovits Atila
Mark Striemer
Edgar Chen
Markus Stange
Makoto Kato
Bogdan Tara
Masayuki Nakano
alaaemad
Sawyer Bergeron
Sylvestre Ledru
nsmoker
Kagami Sascha Rosylight
Jonathan Kew
Brindusan Cristian
Jamie Nicol
tanweerali
Csoregi Natalia
Andrew Osmond