Most of the client side imports from the MDNCompatibility library
is to access the MDNCompatibility.ISSUE_TYPE property.
This patch moves the property into devtools/shared/constants.js
from where it can be accessed on both the client and server side.
Differential Revision: https://phabricator.services.mozilla.com/D86519
The callee getter returned |undefined| for certain functions because it's
hard to recover the callee consistently for all environments (and we can't
return the internal canonical function). See also bug 1414684.
This patch fixes that by exposing the script instead of the callee. Devtools is
only interested in the displayName and parameterNames properties and those are
also available on scripts (the previous patch adds Script.parameterNames).
Differential Revision: https://phabricator.services.mozilla.com/D89701
Depends on D86162
The resource watcher already guarantees that listeners are only called once, caches resources etc.
Consequently, the client side logic currently implemented in the WalkerFront is redundant and should be removed.
Differential Revision: https://phabricator.services.mozilla.com/D86163
Depends on D85598
This test relies on mutations which are no longer emitted for most navigations and which will no longer be emitted at all with the next patches.
It has been disabled for 9 months and should be removed.
Differential Revision: https://phabricator.services.mozilla.com/D85599
Depends on D85597
newRoot mutations are no longer emitted by any server we support, we can remove the corresponding client code.
Differential Revision: https://phabricator.services.mozilla.com/D85598
_ref is renamed to _getOrCreateNodeActor to better reflect the purpose of the method.
_refMap is renamed to _nodeActorsMap
The test helper inspector-helpers was also directly querying _refMap.
This has been replaced by a call to the public API getNode.
Differential Revision: https://phabricator.services.mozilla.com/D84972
There's two issues being fixed here - the first is that no-unused-vars now reports against the last instance of the unused variable. The second is no-dupe-else-if is now on by default.
Depends on D84816
Differential Revision: https://phabricator.services.mozilla.com/D84818
Note: Until private fields are enabled by default, this test case will take the
early return. However, I have tested locally that it fails without the fix, and
passes with the fix.
Differential Revision: https://phabricator.services.mozilla.com/D82786
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
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 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
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
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
The lack of specificity for script intro type has lead the debugger to need
to make use of 'source.introductionType' and 'source.element' in order to
determine whether a given script was injected, or inline or fetched, which
is entirely unnecessary of the loader itself clearly tells us what type
of script we are working with. It also allows us to cleanly handle the case
of XUL, which previously was "scriptElement" but has no ".element" passed
in, so we were unable to know whether a given source was inline or not.
Differential Revision: https://phabricator.services.mozilla.com/D78435
According to SVG Accessibility API Mappings, an SVG element which has title or desc element must be exposed.
https://w3c.github.io/svg-aam/#include_elements
Previously, we didn't expose <g> elements at all even if they had a title/desc, and we unconditionally exposed some other SVG elements even when they didn't.
This removes the Dev Tools A11y Panel code which explicitly allowed unlabelled descendants of role="img" <svg> elements, since we don't create descendants if they don't have a label now anyway.
The associated tests had to be tweaked as well, since now we don't create unlabelled descendants.
Original patch by Takeshi Kurosawa.
Differential Revision: https://phabricator.services.mozilla.com/D77763
This prevents showing e.g. ::cue pseudo-elements for elements that are
not videos, and such.
This is useful on its own, but it's going to be even more useful because
I'm making some rules in the UA sheets less specific in the blocking
bugs.
For example, after my patches, the number of expected rules in
test_styles-applied was 24 (instead of 9 with this patch). That's just
too much noise.
Differential Revision: https://phabricator.services.mozilla.com/D76308
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
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
The previous changeset removed all the usages of listRemoteFrames from
the frontend code. We can start removing this method from the actor codebase,
and keep backward compat code in the client.
Differential Revision: https://phabricator.services.mozilla.com/D65522
Now that the BrowsingContextTarget are created by the watcher,
we should redirect existing code in the frontend which was using
`RootFront.getBrowsingContextDescriptor` in order to directly fetch the target from the watcher.
We don't really need descriptors for additional targets.
I think that descriptors are mostly useful for the top level target and for about:debugging, to describe a target without debugging it yet.
This patch is a bit complex because we can't fetch the "parent BrowsingContext ID" from actors/browsing-context.js:form().
browsingContext.parent and browsingContext.embedderWindowGlobal are both null from the content process.
I have not found any way/API to get the parent browsing context ID from the content process, i.e. the ID of browser.xhtml from a tab content process.
So, I end up with this helper method on Watcher actor to get the parent ID on-demand.
We could also inject the parent ID into the browsingContextTarget's form in WindowGlobalWatcher._createTarget,
but that sounds very hacky and hard to follow.
Note that this patch address the issue of duplicated targets.
WatcherFront.getBrowsingContextTarget ensures fetching the ParentProcessTarget for browser.xhtml
instead of recreating a duplicated FrameDescriptor and BrowsingContextTarget for this document, as we do in the existing codebase.
Differential Revision: https://phabricator.services.mozilla.com/D62465
* Introduce a new actor "Watcher", which might in the future allow listening to anything.
Here, it only implements listening for additional remote frame's WindowGlobal
and notify about the WindowGlobalTargetActor's.
* Also, very important part here is that it instantiates the BrowsingContextTargetActor much earlier. Before anything from the page is executed.
It requires to instantiate the actor directly from the content processes, whereas before, we were doing it from a frontend request, after a notification sent from the parent process to the frontend.
* Last but not least, make the TargetList use this new watcher actor in order to
notify the frontend about the dynamically added remote frames.
Differential Revision: https://phabricator.services.mozilla.com/D63317
Depends on D70071
After changes in D70071, the `CSSProperties` object is retrieved from the `CSSPropertiesFront`. The `initCssProperties()` method is no longer required. It is only used in tests.
This patch removes the leftover callsites for `initCssProperties()` from tests and the method implementation itself.
Differential Revision: https://phabricator.services.mozilla.com/D71560
Depends on D69544
Since selected is read on the descriptor form, there is no need to include it in the listTabs response.
Differential Revision: https://phabricator.services.mozilla.com/D69545
--HG--
extra : moz-landing-system : lando
Depends on D68599
This changeset moves devtools-client.js and constants.js to devtools/client and removes devtools/shared/client
Differential Revision: https://phabricator.services.mozilla.com/D68600
--HG--
rename : devtools/shared/client/constants.js => devtools/client/constants.js
rename : devtools/shared/client/devtools-client.js => devtools/client/devtools-client.js
extra : moz-landing-system : lando
Depends on D67603
This patch is an automated string replace of shared/fronts/ to client/fronts/ in devtools.
Differential Revision: https://phabricator.services.mozilla.com/D67604
--HG--
extra : moz-landing-system : lando
Depends on D67603
This patch is an automated string replace of shared/fronts/ to client/fronts/ in devtools.
Differential Revision: https://phabricator.services.mozilla.com/D67604
--HG--
extra : moz-landing-system : lando
I made some changes in preparation for removing nsIScriptError.flags in favor
of nsIConsoleMessage.logLevel.
Differential Revision: https://phabricator.services.mozilla.com/D66878
--HG--
extra : moz-landing-system : lando
All the actors using ActorPool now use Pool instead.
A few changes were needed since the API are a bit different:
- addActor(x) was changed to manage(x)
- removeActor(x) was changed to x.destroy() (which removes x from the Pool)
- x.registeredPool was changed into x.parent() (registeredPool was the Pool x was in)
- conn.addActorPool calls were removed as it's already done in the Pool _poolMap getter
- conn.removeActorPool(x) calls were turned into x.destroy , as the former is called
from Pool#destroy.
Also, some actors were overriding Actor#initialize without calling
Actor.prototype.initialize.call, which mean they didn't have a `conn`
property.
Differential Revision: https://phabricator.services.mozilla.com/D66780
--HG--
extra : moz-landing-system : lando
I am not sure if you are okay with reviewing all those test changes.
Sadly it's not that easy to search through our huge JavaScript code
base for some generic name like 'isStrict'.
Differential Revision: https://phabricator.services.mozilla.com/D66573
--HG--
extra : moz-landing-system : lando
CLOSED TREE
Backed out changeset d33b655d9fab (bug 963933)
Backed out changeset ed3f61f1c32c (bug 963933)
--HG--
extra : rebase_source : 4cf04bc52117beaf023151fb14601cd8cb3df35b
The transition-timing-function is now applied to the effect as opposed to the
individual keyframes.
Depends on D64523
Differential Revision: https://phabricator.services.mozilla.com/D64914
--HG--
extra : moz-landing-system : lando
Since the thread actor caches the object actors
it creates, if an object had multiple properties
referencing the same object, we would create
multiple fronts for the same object actor, which
would confuse protocol.js.
The fix consist in checking if a front already exists
before creating a new one.
A test is added for the debugger to ensure this
works as expected and we don't regress.
Differential Revision: https://phabricator.services.mozilla.com/D63907
--HG--
extra : moz-landing-system : lando