Depends on D81343
All the client side consumers for the event have been removed.
Since we don't support forward compatibility, we can simply remove the event.
Differential Revision: https://phabricator.services.mozilla.com/D81344
Depends on D81341
Moving forward, we do not plan to support the old service worker implementation anymore.
The only reason why we needed to update ServiceWorker UI dynamically was for the old implementation.
With the new implementation, there cannot be any change after the application starts so we don't need to react to events.
Differential Revision: https://phabricator.services.mozilla.com/D81342
When switching from a dedicated addon toolbox to an about:devtools-toolbox tab, we did a minimal migration for the browser_aboutdebugging_addons_debug_* tests.
They used to inject a "toolbox test script" in the process of the addon toolbox. But we could have updated them with regular test APIs, async/await patterns etc.
Doing the migration now in preparation for adding calls to waitForRequestsToSettle in the next changeset.
Differential Revision: https://phabricator.services.mozilla.com/D82362
This patch does the following cleanup:
* Arrange actions in alphabetical order
* Arrange reducers in alphabetical order
* Arrange imports in alphabetical order
* Arrange functions in alphabetical order
This keeps it consistent with the code style in the compatiblity directory
Depends on D81443
Differential Revision: https://phabricator.services.mozilla.com/D82057
The tests cover the following test cases:
* Dynamic addition of inline style
* Dynamic change of classlist - addition and removal of class
* Inline style change via the rule-view
* Dynamic addition of nodes with issues
* Dynamic addition of nodes whose children have issues
* Dynamic removal of node with issue
* Dynamic removal of node whose children have issue
Differential Revision: https://phabricator.services.mozilla.com/D81443
Currently the Compatibility Panel doesn't react to dynamic DOM
node addition and removal which poses a problem for websites that
depend on client side rendering using the modern framework and
render contents based on dynamic API calls. The updation fails
when switching between routes on a single page application.
In this patch, we use inspector's `markupmutation` event to listen
to `childList` and `customElementDefined` events which cover these
DOM mutations.
Whenever we find a node being added or removed, we compute compatibility
issues for the newly added nodes and remove references to the removed
nodes in the compatibility panel.
Differential Revision: https://phabricator.services.mozilla.com/D80170
Compatibility panel doesn't react to programmatic attribute changes
caused as a result of JavaScript execution.
This patch uses inspector's `markupmutation` event to listen to
markup mutations and react to attribute changes dynamically.
Whenever a node undergoes a programmatic inline attribute change
that is not monitored by Resource Watcher currently, the issues
linked to the node is revaluated and updated.
Differential Revision: https://phabricator.services.mozilla.com/D79333
Functions to create object actors are put in helper files so they
can be used by other consumers than the console messages watcher.
Differential Revision: https://phabricator.services.mozilla.com/D81490
Depends on D81677
We recently introduced a modification to updateWorkers in order to swallow errors after destroy.
Since I am suggesting to add a helper to take care of a similar issue in Toolbox::highlight I think we could also apply it here.
Differential Revision: https://phabricator.services.mozilla.com/D81679
We very often have to introduce a pattern in our async methods in order to "swallow"
async errors if a panel was destroyed, if the toolbox was destroyed etc...
This is not an issue in a regular usage of the toolbox, but it can lead to many intermittent failures.
One solution could be to always wait for all requests to be completed before shutting down tests.
Another approach is to have an easy way of swallowing errors when a certain condition is true.
The helper added here will run the provided method in a try catch, and will only bubble up errors if the provided check fails.
Differential Revision: https://phabricator.services.mozilla.com/D81675
The failure only occurs locally when I use an attached target for the test_panel_live_reload mochitest.
And it only happens if we perform the `extension.upgrade` call during the test.
Most of the time it seems linked to a "frameUpdated" event fired when the webextension is being updated.
But even after commenting out the event, the test remains intermittent (albeit with a much lower frequency)
A first option would be to expose a new API on the webextension descriptor front in order to create
detached targets.
But it seems that isolating the live_reload test in a dedicated file also fixes the intermittent.
It makes the fix a bit obscure, and it probably means we won't look into the issue much furhter but
I would prefer to avoid test-only APIs in the codebase.
Differential Revision: https://phabricator.services.mozilla.com/D81322
We take this opportunity to remove Pool.get as well,
which was doing exactly the same thing as Pool.actor
This highlighted a couple issues in Reps:
- LongString were relying on the isGrip function, which was only checking that
the actor property was truthy. So it was matching LongStringFront which had
the actor method. This is modified by using the isLongString helper instead.
- The Object rep was building all the reps for the object properties, even in
TINY mode, where the result was only used to check the length. In the Accessibility
panel, it can happen that an plain object containing front properties is passed
to Rep. It was fine before because this was short-circuited by the Accessor rep
which was only checking the truthiness of a `get` property. With `get` being
removed, the default Rep was used, which is Object, and we were hitting a
recursion loop, as some of the properties of fronts are cycle references.
There should be a fix in the Accessibility panel to _not_ pass fronts, but we
also "fix" it from here by simply not building sub-properties for the object
when we're in TINY mode.
Differential Revision: https://phabricator.services.mozilla.com/D81971
Added nodes of type DOCUMENT_NODE to the excluded types for deletion.
In order to test the context menu options for document nodes a new helper function getFrameDocument() got introduced that returns the document node of an iFrame.
Differential Revision: https://phabricator.services.mozilla.com/D81241
The profiler can be "paused", which stops sampling, and since bug 1578329 stops markers as well.
Some test suites use pausing between tests (to better differentiate the tests, to keep the profiler ready to run, and to lower the amount of recorded data). But this causes problems with some tracing markers, as their matching ends have not been recorded (e.g., an end marker is missing), which show up as very loooong markers.
To solve this, we need to be able to pause sampling only, but keep recording markers.
But we still need to be able to pause the whole profiler, in particular before capturing, to avoid recording anything around that time.
This big patch is mostly mechanical changes: Wherever there are "Pause" and "Unpause/Resume" profiler functions, we add matching "PauseSampling" and "UnpauseSampling/ResumeSampling" functions that only impact the periodic sampling loop; And existing "Pause/Unpause/Resume" imply pausing sampling as well.
Exceptions and extra work:
- nsIProfiler (the JS API) already had `Pause/ResumeSampling()`, which misleadingly paused everything! Now they do the right thing, and we have `Pause/Resume()` as well.
- All tests using `Pause/ResumeSampling()` now use `Pause/Resume()`, except for Talos tests that only pause sampling between tests; Added some extra `Pause()` calls to pause everything before capturing profiles.
- GeckoJavaSampler doesn't handle pausing/resuming everything, this should be done in a follow-up bug.
- Sampling-only pauses are not streamed into JSON. If needed, we should follow-up, with potential work on the front-end to deal with these.
Differential Revision: https://phabricator.services.mozilla.com/D81492
The constructor signature was wrong, as protocol.js calls it with a targetFront
instead of the expected "form".
The self-management isn't making much sense, and there's no need for this front
to be different than others.
test_framebindings-07.js, which was directly instantiating EnvironmentFronts is
modified to not do this anymore.
This allow us remove the getBindings method from the front, as it was only used
from this test.
Differential Revision: https://phabricator.services.mozilla.com/D81838
We might be able to move even more code from LocalTabTarget to TargetList,
but here is the minimal modification, which allows to update the target,
without requiring a Toolbox.
Differential Revision: https://phabricator.services.mozilla.com/D80161
We don't have to and shouldn't unregister and re-register the Watcher actor listeners
in case of top level target switching. As, Watcher actor is independant from the top level target
and we might loose some events by doing so. One main goal of Watcher actor was about that.
Being independant from the lifecycle of the top level target.
Differential Revision: https://phabricator.services.mozilla.com/D80160
In a near future, target switching should be notified by the watcher actor,
via a target-available-form event.
So that all the logic around target switching should rather be into this RDP event listener.
Differential Revision: https://phabricator.services.mozilla.com/D80159
Target switching should be implemented differently.
I think switchToTarget may have been introduce before TargetList?
But top level target switching should be handled via onTargetAvailable.
It happens when onTargetAvailable is called with a targetFront with isTopLevel=true,
and isTargetSwitching argument is true.
Differential Revision: https://phabricator.services.mozilla.com/D80158
This is a brand new (and first) DAMP talos test for accessibility panel. "accessibility.cold-open" is similar to other cold open tests such as inspector one. It opens accessibility panel, waits for its UI to render and then closes the toolbox.
Differential Revision: https://phabricator.services.mozilla.com/D80512
I spent some time looking into this, and the Linux runs when opening up the
popup and the private browser are not working consistently. The popupshown
and popuphidden events are not firing consistently. It's probably good enough
to just disable this test on Linux, as it's mainly a UI test, and it works
on the other platforms.
Differential Revision: https://phabricator.services.mozilla.com/D81602
Some intermittents were caused by the failure to ensure the popup was closed.
This patch creates a new API that explicitly ensures that the popup is actually
closed in the patch.
It also adds a listener to the popupshown and popuphidden events dispatched by
the XUL elements to ensure that we're not just relying on a single requestAnimationFrame
tick.
Differential Revision: https://phabricator.services.mozilla.com/D79332
Makes `sourceId` available in the `resource.message` object for log points from 'resourceWatcher' to better address sources than only by `fileName`.
Differential Revision: https://phabricator.services.mozilla.com/D80642
Async stacks can provide valuable information when chasing intermittents.
But by default they are only enabled in debuggees, to avoid performance overhead.
Forcing javascript.options.asyncstack_capture_debuggee_only to false before running any
DevTools mochitest will ensure async stacks are available for all locations.
Differential Revision: https://phabricator.services.mozilla.com/D81694