This matches what we do in CompositorOGL.
This avoids having clipping state stored on the render target's DrawTarget.
As a result, we have access to the combined device clip rect in DrawGeometry,
and the video scale fast paths can observe the correct clip even though they
bypass the DrawTarget machinery.
This fixes flickering bugs caused by the video scale fast path in the native
layers configuration, i.e. on macOS only. We probably still have bugs on the
other platforms. It's possible that this bug is less observable on other
platforms due to additional copies of the invalid region, and those copies
ignore the bad content outside the invalid region.
Differential Revision: https://phabricator.services.mozilla.com/D86608
mOpaquenessTintLayer is a sibling layer of mContentCALayer, so the two layers
need the same transform and bounds.
This patch also removes an unnecessary twiddling of the position property.
Differential Revision: https://phabricator.services.mozilla.com/D86610
The registers referenced in this patch and the assembly have been tested to
compile; the code changes have not been tested to actually work.
Differential Revision: https://phabricator.services.mozilla.com/D86612
SpliceableChunkedJSONWriter::WriteFunc was hiding base-class non-virtual JSONWriter::WriteFunc(), which made it less than ideal (for me) to reason with.
Also made a few subclasses final, to help with possible devirtualization.
Differential Revision: https://phabricator.services.mozilla.com/D86505
The main change is removing ProfileJSONWriter.cpp, making ProfileJSONWriter.h point at BaseProfileJSONWriter.h, and exposing `mozilla::baseprofiler::` classes in the top namespace as expected by users of ProfileJSONWriter.h (to minimize changes).
These two headers are now always present in the "mozilla" include directory, independent of MOZ_GECKO_PROFILER settings.
The rest is just needed tweaks to match the above changes.
Differential Revision: https://phabricator.services.mozilla.com/D86504
Because this header will be used across libraries (mozglue and xul), it is simpler and more efficient to make it fully self-contained instead of using MFBT_API.
It may lead to slightly longer build times, but since it's only used inside the profilers, it won't impact other components.
The compiler can better optimize it in context, and decide what to inline.
Differential Revision: https://phabricator.services.mozilla.com/D86503
This change doesn't resolve some of the issues in profiler code that have
x86-64-isms in them, but this is at least a start.
Differential Revision: https://phabricator.services.mozilla.com/D86595
Per UX, the new default location for the indicator upon opening is the the top
of the content viewport of the most recently used browser window.
Differential Revision: https://phabricator.services.mozilla.com/D86080
Uint32 isn't yet supported, because it may return a Double, which is difficult
to represent in CacheIR. Bug 1077305 proposes to unconditionally use Double
for Uint32 Atomics, which will make this easier to implement in CacheIR.
Differential Revision: https://phabricator.services.mozilla.com/D86299
The window opened by the crashtests does not show up in the list
maintained by BrowserWindowTracker, so we never end up with any tabs to
share, causing the test to hang. I don't like to remove a test, but this
was written for the old version of tab sharing which has been completely
removed, and there doesn't seem to be a clear path ahead which would
make this test pass without adding special case code in tab sharing that
would work with crashtests.
Depends on D84593
Differential Revision: https://phabricator.services.mozilla.com/D86564
This avoids a problem where apz side smooth scroll animations end immediately because the inaccuracy of converting to (integer) app units and back wrongly tells us that we have overscroll the non-moving axis if that axis is at the end of its range.
When we do a smooth scroll animation on the apzc side we use AxisPhysicsMSDModel. AxisPhysicsMSDModel is also used on the main thread to do smooth scroll animations. AxisPhysicsMSDModel uses doubles to represent all coordinates. On the main thread we pass in appunits, so the output of AxisPhysicsMSDModel is also in appunits. On the apzc side we follow that to.
A problem comes up when we do a smooth scroll animation in one axis, and the other axis is at the end of its range (and not animating). In the non-moving axis we convert the current scroll position (on the frame metrics) to appunits and pass it into AxisPhysicsMSDModel. Then when it comes time to call DoSample for the first time we ask for the position from AxisPhysicsMSDModel (in appunits) and then convert it to CSSPoint. And then we compare it with the current scroll position (on the frame metrics). Especially when we have zoom, the inaccuracy of this computation is enough for the difference between the CSSPoint for the current position from AxisPhysicsMSDModel and the current scroll offset (on the frame metrics) to be bigger than the epsilon that we use here:
https://searchfox.org/mozilla-central/rev/491612fa0be0f809069ea62c6316bf452cacc816/gfx/layers/apz/src/AsyncPanZoomController.cpp#747
and we determine that we have overscrolled the non-moving axis, and therefore the animation must be over.
Since AxisPhysicsMSDModel already operates purely on doubles if we just avoid converting to (integer) app units we avoid this problem. We could have AxisPhysicsMSDModel operate on float appunits, but that's a little inelegant because there aren't functions for converting to float appunits. We could also just have AxisPhysicsMSDModel operate on CSS pixels. That assumes that the physics calculations of AxisPhysicsMSDModel are scale independent, which I don't know for sure but they seem to be visually the same with CSS pixels.
Differential Revision: https://phabricator.services.mozilla.com/D86481
A lot of tests assume that the screen will be the last thing enumerated.
It is also the "scariest" option, so having it last makes sense.
Differential Revision: https://phabricator.services.mozilla.com/D84593
Now, only when deleting table cell contents, `HandleDeleteSelectionInternal()`
depends on `Selection`. However, this can be moved to `HandleDeleteSelection()`
because recursive callers expects `Selection` is collapsed by its previous job.
Differential Revision: https://phabricator.services.mozilla.com/D86183
This patch moves `EditorBase::ExtendSelectionForDelete()` into `AutoRangeArray`
and make it stop modifying `Selection`.
The method extends anchor-focus range with `nsFrameSelection` and it refers
bidi information in it too. Therefore, it needs to be called before modifying
anchor-focus range of `Selection`. Unfortunately, this makes the code messy,
but for now, we should take this. In the future, we should make the API of
`nsFrameSelection` free from `Selection`.
Differential Revision: https://phabricator.services.mozilla.com/D86182
Peter Van der Beken
Markus Stange
Nathan Froyd
Razvan Maries
Mike Hommey
Matt Woodrow
Gerald Squelart
julianwels
John Lin
Christoph Kerschbaumer
Mike Conley
Moritz Birghan
André Bargull
Miko Mynttinen
Frederik Braun
Jan Varga
Csoregi Natalia
Noemi Erli
Itiel
Emilio Cobos Álvarez
Dan Minor
Timothy Nikkel
Jonathan Kew
Masayuki Nakano