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
The test is a permafail without any of those changes on all my windows machine so I've been unable to diagnostic what could happen.
According to :kats, the test was never rewritten to use the new APZ. Disabling on the platform where there's high intermittent failure (about 70%)
Differential Revision: https://phabricator.services.mozilla.com/D74391
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
Depends on D73779
Reusing the same tab descriptors across process switches means that calling
getTarget on the tab descriptor must create a new target and not return the old one.
The caching mechanism on descriptor fronts relies on the fact that the TargetFront is still alive.
When TargetFront.actorID is null, the cache is invalidated and we fetch a new target.
However the current target switching mechanism relies on an event fired very early in the target
destruction sequence. This means that when we will call getTarget, the old target might still be
alive.
We also start waiting for an event in RDMs target switching, which was not waiting for anything so far
Differential Revision: https://phabricator.services.mozilla.com/D73780
Depends on D73778
Flipping this boolean can create race conditions.
We set it to false and then wait for the "close" event fired by the target front
After that, in parallel:
- the target will finish initializing fronts (async)
-> then we check shouldCloseClient
- the new target will be created (for target switching scenarios)
-> then we flip back shouldCloseClient
We have no guarantee that we will check shouldCloseClient before it is flipped back to true.
Furthermore, this target is being destroyed, there is no reason to flip the boolean.
So removing this code seems like the best option.
Differential Revision: https://phabricator.services.mozilla.com/D73779
Depends on D73777
The filter is a special argument of TabDescriptor::getTarget that is
closely linked to local-tab. It can only be set by rootFront getTab.
However if we reuse the same tab descriptor for several targets, we need
to make sure to consistently create LocalTabTargetFronts if we are debugging
a local tab.
Usually the tab descriptor target is created via getTab and cached, but under
some circumstances, we can attempt to call getTarget on a tab descriptor from
another codepath first (eg reparent remote frame).
The localTab becomes a property of the TabDescriptorFront, and getTarget takes
no argument, which is consistent with other target descriptors.
Differential Revision: https://phabricator.services.mozilla.com/D73778
Depends on D73700
The TabDescriptorActor/Front is never destroyed, but we used to clean the map entry on TabRemotenessChange.
Removing this cleanup allows to reuse tab descriptors after a navigation.
Differential Revision: https://phabricator.services.mozilla.com/D73701
With full color management enabled in bug 455077, generated
screenshots will not be saved as sRGB when the display has
a different ICC profile. As long as bug 1615395 hasn't been
fixed, force screenshots to be saved as sRGB.
Differential Revision: https://phabricator.services.mozilla.com/D74007
Depends on D62624
With the previous implementation, an uninitialized document could be returned as a root node.
Here we try to be more explicit and wait for a correct root node. However in some cases a document can remain uninitialized and will never transition to any other state.
If the document is uninitialized but is not currently loading, we should consider it as a valid root node.
Differential Revision: https://phabricator.services.mozilla.com/D62625
Depends on D62623
`new-root` is no longer a mutation, but an event emitted by the `walker` actor.
Tests watching for mutations should be updated accordingly. They also need to call watchRootNode explicitly.
Differential Revision: https://phabricator.services.mozilla.com/D62624
The refactoring consists of:
- moving tests into dedicated directories for given test type
(browser, mochitest, xpcshell)
- replacing add_test with addTest in browser tests to share common setup code
- adding a way to synchronously load scripts in all test types by providing a
path relative to the top level directory
- adding a way to explicitely run a mochitest inside a worker context
(loadWorkerScript)
- removing the need to declare testGenerator in tests
- removing the need to set some common preferences in individual tests
- sharing common functions for:
- system context (system.js)
- content context (content.js)
- browser tests (browser.js)
- mochitest tests (mochitest.js)
- xpcshell tests (xpcshell.js)
- nested content test inside a browser test (nestedtest.js)
- buffer/view/blob/file (file.js)
Differential Revision: https://phabricator.services.mozilla.com/D73149
This changeset covers the new, severity-based triage process
Fix linting errors
Fix links and language
Fix headings and broken link
Add missing newline to labels.rst
Differential Revision: https://phabricator.services.mozilla.com/D73999