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
It used to take an object with only 1 property, a function. The way it was
called in the webconsole actor made it harder to follow than it actually need.
We take that as an opportunity to convert the function to a class.
Differential Revision: https://phabricator.services.mozilla.com/D79294
It used to take an object with only 1 property, a function. The way it was
called in the webconsole actor made it harder to follow than it actually need.
We take that as an opportunity to convert the function to a class.
Differential Revision: https://phabricator.services.mozilla.com/D79252
It used to take an object with only 1 property, a function. The way it was
called in the webconsole actor made it harder to follow than it actually need.
We take that as an opportunity to convert the function to a class.
Differential Revision: https://phabricator.services.mozilla.com/D79249
My patch from bug 1599160 changed timing in a way that makes this bug a
perma fail and I'd rather not get it backed out :)
Differential Revision: https://phabricator.services.mozilla.com/D79316
This attribute can only be toggled on top level BrowsingContext.
These are the top level window's, or tab's BrowsingContext.
From DevTools point of view, it should only be toggled by the
Parent Process or Tab target.
Differential Revision: https://phabricator.services.mozilla.com/D78860
Daisuke Akatsuka
Razvan Maries
Logan Smyth
Sebastian Zartner
Nicolas Chevobbe
Jan Odvarko
Nihanth Subramanya
Hubert Boma Manilla
Yura Zenevich
Julian Descottes
Butkovits Atila
Tooru Fujisawa
Dorel Luca
Alexandre Poirot
Narcis Beleuzu
Kriyszig
Emilio Cobos Álvarez
Jason Laster
Stepan Stava