Normally we wouldn't need to send any notifications if the actor was
already destroyed, but it can be a VersionChangeOp which needs to
notify its parent operation (OpenDatabaseOp) about the failure.
So SendFailureResult needs to be called even when the actor was
destroyed. Normal operations redundantly check if the actor was
destroyed in SendSuccessResult and SendFailureResult, therefore it's
ok to call it in all cases here.
We were missing error checks at two points. In one case an error return
is meaningful; in another case it is not, as the problem should have
been guarded against at a higher level by emitting far jump islands soon
enough during pasteup of compiled code.
* Simplify the dispatch-to-content region
Simplify the dispatch-to-content region in nsDisplayLayerEventRegions::AddFrame() and AddInactiveScrollPort() if it starts to get large.
* tabs to spaces
- This modifies `loadOneTab` and `addTab` to accept an opener
- This code was adapted from Basilisk's copy of tabbrowser.xml without the refactored code changes (which is a lot more involved as it divides addTab's functions into multiple functions)
This fixes flickering/bars/stripes showing up during quickly-updating
operations on Intel hardware when using XRENDER.
For more information, refer to the code comment.
See #1061
A note about the Scalar Replacement Changes: The M{Load,Store}Unboxed*
instructions in theory could be used to manipulate and analyze typed
arrays. However, TypedArrays should already be excluded from eligibility
because of the potential for cross-thread sharing in a SharedArrayBuffer
world, and so the only support in Scalar Replacement here is for Unboxed
Objects, meaning it can all be removed.
targetFrame is modified during the intersection computation loop, so
it's not the viewport you want if there are scrollframes around.
This bug triggers when IntersectionObservers are used on frames that
wrap.
Follow-up for #249.
Mozilla tried to enable XRENDER support with backends other than Cairo
in 286348:e13aaaaf1962 /
https://hg.mozilla.org/mozilla-central/rev/e13aaaaf1962 - at least until
they decided to completely remove XRENDER support.
The change looked innocent enough, but actually turned out to do exactly
the opposite: it forcefully enabled image offscreen surfaces with GTK2
when it was previously disabled (since
gfxPrefs::UseImageOffscreenSurfaces() will always return true) and, by
extension, disabled the XRENDER-based functionality by creating a
non-Xlib surface.
Interestingly, a previously enabled double buffering check was also
disabled by this, but since the comment for this was diverging with the
code, that behavior just sounds like yet another bug.
Instead of disabling image offscreen surfaces (at least when using the
GTK2 backend), let's force the creation of Xlib-based image surfaces
when XRENDER support is enabled. This will let UXP use the more
common/modern code paths, but also make scrolling much faster again. Too
fast scrolling may induce tearing (if not smoothed), but on the other
hand performs much better in remote computing contexts.
As an added benefit, GTK3-based builds should roughly behave the same
way. Further tests with the GTK3-backend enabled will be required in the
future.
