Make the WebAssembly baseline compiler address incoming stack arguments from the frame pointer instead of from the stack pointer.
We have a plan to allow interstitial trampoline frames to be inserted between callers and callees, but only for cross-instance calls. This will mean offset to incoming stack arguments from SP is no longer a constant. The design has us instead address stack arguments from the frame pointer, as adding an interstitial trampoline frame won't modify the frame pointer.
The followup patch will do the same for the Ion compiler.
Differential Revision: https://phabricator.services.mozilla.com/D72298
The place where it's done right now is just unsound. It modifies
attributes during frame construction and it causes assertions to fire
with lazy frame-construction enabled.
Differential Revision: https://phabricator.services.mozilla.com/D74029
Since AnimationState::UpdateState now depends on a specific frame of the animation being in the surface cache we need to call UpdateState whenever we add a new frame.
Depends on D73583
Differential Revision: https://phabricator.services.mozilla.com/D73584
It takes a frame count argument but probably never gets a value we haven't already seen in a NotifyProgress call, so this doesn't fix anything as far as I know.
Depends on D73564
Differential Revision: https://phabricator.services.mozilla.com/D73583
The img.decode promise for animated images that aren't in the document might not resolve in common cases. Specifically for animated images that have been decoded and then discarded, so that mCompositedFrameInvalid is true.
mCompositedFrameInvalid is cleared by either:
1) the image is fully decoded and NotifyDecodeComplete is called.
2) RequestRefresh is able to advance to the current frame.
We don't call RequestRefresh on animated images that aren't in the document and we only decode a certain number of frames ahead of the current frame (even for fully retained animation buffers), so neither of these will happen with long enough animated images.
So we need to make sure that mCompositedFrameInvalid eventually gets cleared any time a decode is requested (which the FrameAnimator gets notified about via GetCompositedFrame). We do that be calling UpdateState in GetCompositedFrame whenever mCompositedFrameInvalid is true and the image is in the surface cache.
This runs into a second problem: UpdateState uses |mIsCurrentlyDecoded = aResult.Surface().IsFullyDecoded()| to determine when to clear mCompositedFrameInvalid. As mentioned above, we don't fully decode animated images. Further, for animated images that are large enough we use a discarding animation buffer that never keeps around all the frames and so IsFullyDecoded always returns false. So we replace that with a check that we can seek to the current animated frame index.
Differential Revision: https://phabricator.services.mozilla.com/D73564
Similar to the IonBuilder optimization but a lot simpler because we don't have
to worry about TI invariants. Once WarpBuilder is enabled by default we could do
the same thing in Baseline.
Differential Revision: https://phabricator.services.mozilla.com/D74025
This patch will do :
- update the comment to describe its usage and where it should be used
- remove out-of-date comment
The advantage of doing so :
- help future reader to easily understand its usage
Differential Revision: https://phabricator.services.mozilla.com/D72940
This patch will do :
- rename `PlaybackController` to `ContentPlaybackController`
The advantage of doing so :
- explicitly mention this class is only used in the content, to help its readbility
Differential Revision: https://phabricator.services.mozilla.com/D72939
This patch will do :
- rename `MediaActionHandler` to `ContentMediaActionHandler`
The advantage of doing so :
- explicitly mention this class is only used in the content, to help its readbility
Differential Revision: https://phabricator.services.mozilla.com/D72938
I guess that this crash may occur in these conditions:
1. It pointed end of a node, but the node has fewer children at redo.
2. The storing point has already been reset by cycle collector.
So, anyway, the check should be tested only when the point stores a
child node.
This adds WPT tests for related situation. Although "insertLineBreak" of
Blink and WebKit behave odd when selection is collapsed between 2 elements.
Differential Revision: https://phabricator.services.mozilla.com/D73416
The APZ was keeping a raw pointer to the controller thread. This was a dangerous exercise.
This was okay on desktop, as the controller thread was the main thread and would have outlived everything else. On Android however it's the UI thread and it could get deleted before we received a last input event.
So we use a strong pointer instead to prevent the thread from being deleted and as such, we now needs to explicitly clear it on shutdown.
This requires the various methods in APZThreadUtils to be made thread-safe so that the controller thread can be shutdown mid-air.
Differential Revision: https://phabricator.services.mozilla.com/D73830
RemoteContentController::PostDelayedTask must be called on the controller thread; and all the 3 implementations are doing is dispatching the task on the current MessageLoop.
The naming and that the method was pure virtual made it a bit confusing as it gave the impression we would dispatch the task on the controller's internal thread, which wasn't the case.
So we make a generic implementation and assert to the documented use.
Differential Revision: https://phabricator.services.mozilla.com/D73828
MessagePool brings no benefit over the traditional nsIThread.
Additonally, replace some incorrect use of RefPtr for xpcom objects.
Differential Revision: https://phabricator.services.mozilla.com/D73827
CompositorBridgeParent::ScheduleTask was always called from the compositor thread ; so make it explicit that we are dispatching the task to the compositor thread.
We inline the method instead.
Differential Revision: https://phabricator.services.mozilla.com/D73824
already_AddRefed destructor assert that it's nullptr.
DelayedDispatch check that the value passed isn't 0 and return an error code, leaving the already_AddRefed untouched.
Differential Revision: https://phabricator.services.mozilla.com/D73821
In-process iframes get a DocAccessibleChild, even though they're not top level in their process.
However, the parent IAccessible on DocAccessibleChild (sent from the parent process) is only relevant for the top level.
Previously, we used the parent IAccessible on the DocAccessibleChild for *all* documents, resulting in accParent returning null for in-process iframe documents.
Instead, we need to use the base implementation in this case.
Differential Revision: https://phabricator.services.mozilla.com/D74180
This gets rid for the need of a number of local packages (mostly related
to Gtk+3). One exception is that we now need a 32-bits version of the
xz-utils package, some -dev package depends on it, and that dependency
can't be fulfilled in the 32-bits image because we already have the
64-bits backport installed, which conflicts with it (we need both
32-bits and 64-bits package to be at the same version when installed).
The system binutils fails to link clang-7 for some reason, so we now use
our toolchain binutils instead, like we already do for newer versions of
clang.
The debian-packages docker image now needs an explicit installation of
git, because it's not pulled in via the recommends of some other
package.
For some reason, snapshot.debian.org doesn't contain the jessie-backports
archive at the same location as others, and only has a few snapshots of
the archive.
Differential Revision: https://phabricator.services.mozilla.com/D73784
Dmitry Bezhetskov
Dorel Luca
Joel Maher
Simon Giesecke
Florian Quèze
prathiksha
Marco Bonardo
Philipp Zech
Emilio Cobos Álvarez
Sebastian Hengst
Timothy Nikkel
Valentin Gosu
Jan de Mooij
Christoph Kerschbaumer
alwu
Ian Moody
Masayuki Nakano
Jean-Yves Avenard
James Teh
Mark Hammond
Mike Hommey
Ryan Kelly
Cosmin Sabou
Daisuke Akatsuka