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
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
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
The limitation to expressions starting with a slash was lifted in order to allow searching via other possible XPath expressions like `id("foo")` or `(//div)[2]`.
Differential Revision: https://phabricator.services.mozilla.com/D80963
This is done by getting the value of the `devtools.testing.enableServerWatcherSupport`
preference on the WatcherActor, and using its result to enable the traits or not.
On the browser_resources_* test that have both legacy and server listener, we
run the tests twice, without and with the pref to have some decent coverage.
Differential Revision: https://phabricator.services.mozilla.com/D79983
This removes the unpopulated _resourceWatchers attributes from
the browsing context, and instead uses a new function on the
Resource module (`unwatchAllTargetResources`)
Differential Revision: https://phabricator.services.mozilla.com/D80834
This class isn't used anymore, and it's safe to remove it.
We take this as an opportunity to remove Pool#cleanup and
Pool#isEmpty, which each only had one callsite.
Some comments are updated to not mention ActorPool.
Differential Revision: https://phabricator.services.mozilla.com/D80602
Remove pools and make target actors manage themselves.
devtools/server/tests/browser/browser_navigateEvents.js was modified
since the targetActor can't be retrieved with `searchAllConnectionsForActor`
anymore.
Differential Revision: https://phabricator.services.mozilla.com/D67510
Depends on D80059
removeActorPool is only called from one spot, which always passes the second optional argument as true.
Differential Revision: https://phabricator.services.mozilla.com/D80060
This is done by getting the value of the `devtools.testing.enableServerWatcherSupport`
preference on the WatcherActor, and using its result to enable the traits or not.
On the browser_resources_* test that have both legacy and server listener, we
run the tests twice, without and with the pref to have some decent coverage.
Differential Revision: https://phabricator.services.mozilla.com/D79983
This patch removes the browsingContextID getter in favor of creating a property
on the instance in the constructor.
The getter was an attempt to handle the fact that we can have multiple browsing
context over time, but it wasn't working that well, so we'll tackle that as
part of Bug 1625027.
Differential Revision: https://phabricator.services.mozilla.com/D80151
This is done by getting the value of the `devtools.testing.enableServerWatcherSupport`
preference on the WatcherActor, and using its result to enable the traits or not.
On the browser_resources_* test that have both legacy and server listener, we
run the tests twice, without and with the pref to have some decent coverage.
Differential Revision: https://phabricator.services.mozilla.com/D79983
In order to handle parentProcessTargetActor in the WatcherActor, we modify
TargetActorRegistry.getTargetActor to return the parent process target when
the passed browsing context id is null.
The comment explaining why we need to call getTargetActor in
WatcherActor#watchResources is modified to better summarize the situation.
We also take this as an opportunity to handle those targets in unwatchResources.
Differential Revision: https://phabricator.services.mozilla.com/D79424
Added browser test for CompatibilityActor to check consistency and
correctness.
Thse test include:
* Test for no issue
* Test for simple issue
* Test for invalid CSS rule
* Test for aliases
* Test for browser specific issues
* Test for multiple issues for same element
Differential Revision: https://phabricator.services.mozilla.com/D78956
This patch adds a `CompatibilityActor` that calls the MDNCompatibility
library from the devtool server.
This patch exposes `_declarations` from the `StyleRuleActor` and the
a new function `formDeclaration` responsible for populating the
declarations property.
As a check for correctness, the patch replaces the `pageStyle.getApplied`
call in the Compatibility Panel on the client with `compatibility.getNodeCssIssues`
fetching the array of compatibility issues directly and removing the
dependency on MDNCompatibility library for client side computation of
compatibility issues.
Differential Revision: https://phabricator.services.mozilla.com/D77060
The 'asyncStack' flag on JS execution contexts is used as a general switch
to enable async stack capture across all locations in SpiderMonkey, but
this causes problems because it can at times be too much of a performance
burden to general and track all of these stacks.
Since the introduction of this option, we have only enabled it on Nightly
and DevEdition for non-mobile builds, which has left a lot of users unable
to take advantage of this data while debugging.
This patch enables async stack traces across all of Firefox, but introduces
a new pref to toggle the scope of the actual expensive part of async stacks,
which is _capturing_ them and keeping them alive in memory. The new pref
limits the capturing of async stack traces to only debuggees, unless an
explicit pref is flipped to capture async traces for all cases.
This means that while async stacks are technically enabled, and code could
manually capture a stack and pass it back to SpiderMonkey and see that stack
reflected in later captured stacks, SpiderMonkey itself and related async
DOM APIs, among others, will not capture stacks or pass them to SpiderMonkey,
so there should be no general change in performance by enabling the broader
feature itself, unless the user is actively debugging the page.
One effect of this patch is that if you have the debugger open and then close
it, objects that have async stacks associated with them will retain those
stacks and they will continue to show up in stack traces, no _new_ stacks
will be captured. jorendorff and I have decided that this is okay because
the expectation that the debugger fully revert every possible effect that it
could have on a page is a nice goal but not a strict requirement.
Differential Revision: https://phabricator.services.mozilla.com/D68503
