The issue was that the getHighlighter request for the about:printpreview
target never settled. It appears that the document always stays in an
unitialized readyState, which was causing trouble.
Instead of relying only on readyState, we now call isDocumentReady, which
also checks if the document is loading.
Differential Revision: https://phabricator.services.mozilla.com/D87756
The issue was that the getHighlighter request for the about:printpreview
target never settled. It appears that the document always stays in an
unitialized readyState, which was causing trouble.
Instead of relying only on readyState, we now call isDocumentReady, which
also checks if the document is loading.
Differential Revision: https://phabricator.services.mozilla.com/D87756
It has some properties which make it footgunny, especially in the face of
Fission. Callers should use WindowGlobalChild.innerWindowId instead.
Differential Revision: https://phabricator.services.mozilla.com/D82801
We already had a function that was returning a resourceType dictionnary for
a given watcher or target actor, on which we were then checking the targetType
to return the appropriate dictionnary.
It feels appropriate to have a dedicated function to get the dictionnary from
the targetType only, so we can call it from other places instead of repeating
the same instructions.
Differential Revision: https://phabricator.services.mozilla.com/D86979
Depends on D85599
The WalkerActor is currently responsible for watching navigations and exposes them to the client.
However, this is communicated to the client differently depending on what kind of frame navigates.
If the top frame of the target navigates, this will be exposed via the watchRootNode API (onDestroyed/onAvailable callbacks will be triggered)
If an inner frame navigates, mutations will be emitted: "frameLoad"/"documentUnload" + a fake "childList" mutation.
On the client side, we have to handle both very similarly which leads to some duplication.
Also "frameLoad"/"documentUnload" are one of the last "immediateMutations" which usually means they should not have been mutations in the first place.
The goal here is to use the watchRootNode API for all frames.
Differential Revision: https://phabricator.services.mozilla.com/D84973
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
Previously CompatibilityActor could only compute the compatiblity
issues taking node actor. However with the implementation of
inline compatibility warning, it becomes necessary to compute
compatiblity issue from the CSS declaration block. This patch
exposes a getCssDeclarationBlockIssues and add browser dataset
fetch within the actor for inline warnings.
Differential Revision: https://phabricator.services.mozilla.com/D81472
Not having the window property anymore, we have to change the `window` getter
in WebConsoleActor to retrieve `workerGlobal`. And since the getter name wasn't
reflecting what it was holding (it can be a window, a worker global or a sandbox),
we rename it to `global` (and `evalWindow` to `evalGlobal`).
We remove the `globalDebugObject` getter on the thread actor that wasn't used
anywhere in the code.
Differential Revision: https://phabricator.services.mozilla.com/D86035
The `watchResources` function [1] takes as a first parameter either a watcher
actor or a target actor, that is used to manage the created resources (e.g. the
object actors of console messages). In order to be able to manage actors, it
needs to extend the `Pool` class (which is the case for Actor).
In the worker cases, things are a bit different, since we create a DevToolServer
which only have a WebConsole and a Thread actor. Those actors usually take a target
actor as a parent, but in the Worker thread we simply have an object implementing
the properties and methods it needs.
This will be this target actor mock that we're going to pass to `watchResources`,
and in order to be able to do that, it needs to be able to manage actors.
In regard of all this, this patch makes the target actor mock an actual Actor,
witout spec, on which we then put the existing methods and properties.
[1] https://searchfox.org/mozilla-central/rev/0e309417bdc73be33fc93f6bd7a0d4063d2c6e51/devtools/server/actors/resources/index.js#66
Differential Revision: https://phabricator.services.mozilla.com/D85814
* removing simulations for protanomaly, deuteranomaly and tritanomaly
* updating (fixing) the color matrices for protanopia, deuteranopia and tritanopia
* adding a matrix to simulate achromatopsia
Co-authored-by: Matthew Petroff <mozilla@mpetroff.net>
Differential Revision: https://phabricator.services.mozilla.com/D85508
Depends on D75157
A thread actor attach error shows up as
Protocol error (unknownError): error occurred while processing 'attach':
[object Object] from: server0.conn145.content-process36/workerTarget5/thread1
[object Object] is a legacy {error, message} object thrown by the thread actor
Differential Revision: https://phabricator.services.mozilla.com/D83507
If we don't, content processes may have outdated data and create a target actor
for a watcher that no longer watch for targets.
Differential Revision: https://phabricator.services.mozilla.com/D82798
-moz-inert CSS property reflects inert subtrees concept and can be used to implement HTML:dialog element and HTML:inert attribute
Differential Revision: https://phabricator.services.mozilla.com/D81701
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
This is the only meaningful callsite for actorHasMethod.
This method has many bugs and we want to replace it with traits
Differential Revision: https://phabricator.services.mozilla.com/D84689
This patch is a mixed bag of fixes:
- don't log an error when the string couldn't be analyzed, as it can occur
frequently when the console input isn't valid, and it clutters the browser
console
- never return a `null` matchProp. Default to empty string, so consumer code
can always assume it's a string
- don't call trim on a property if it's not a string (it can be an integer at
this point).
Differential Revision: https://phabricator.services.mozilla.com/D84779
We do not expose it nor ever style it. Just use the parent style all the
time. This avoids problematic style resolution calls during reflow.
Differential Revision: https://phabricator.services.mozilla.com/D84358
It has some properties which make it footgunny, especially in the face of
Fission. Callers should use WindowGlobalChild.innerWindowId instead.
Differential Revision: https://phabricator.services.mozilla.com/D82801
The problem has 2 folds.
The first one is that the shutdown function on DevToolsExtensionPageContextParent
wasn't called, which means the target was never destroyed. This is fixed by
overriding unload in DevToolsExtensionPageContextParent instead of shutdown, so
the function gets called and the target destroyed.
The second issue was that a single webextension could create 2 targets, and since
we only keep track of a single target, we would miss one. This is fixed by putting
the call to watchTargets in getCurrentDevTools in a promise, so subsequent calls
that might occur before the resulting promise isn't resolved don't end up calling
watchTargets a second time.
Differential Revision: https://phabricator.services.mozilla.com/D83935
It has some properties which make it footgunny, especially in the face of
Fission. Callers should use WindowGlobalChild.innerWindowId instead.
Differential Revision: https://phabricator.services.mozilla.com/D82801
This is quite similar to the error messages watcher, except that we call
ensureCSSErrorReportingEnabled after retrieving the cached messages.
Resource no longer includes `errorMessageName` and `isPromiseRejection` as it
makes little sense for the CSS warning.
The existing resource test is updated to run with and without the server support.
Differential Revision: https://phabricator.services.mozilla.com/D83047
I've not got Windows to test the fix specifically.
This should stop from throwing an Error if the WeakMap does not contain
any data for the channel.
It should just return `null`
Differential Revision: https://phabricator.services.mozilla.com/D83840
Uses of `-moz-appearance: none` are changed to `appearance: none`.
Uses of other values that are simply reverting the appearance back to
its default are changed to `appearance: auto`.
Uses of values in UA sheets that are defining the inherent appearance of
widgets are changed to:
appearance: auto;
-moz-default-appearance: <value>;
since those values are either no longer supported on (-moz-)appearance,
or are still supported but only in some limited form.
There are some uses of `-moz-appearance: textfield` on <input
type=number> elements that are renamed to `appearance: textfield`.
Differential Revision: https://phabricator.services.mozilla.com/D83430
This removes the calculation method coordinatesRelativeToScreen in favor of
using the event-supplied screen coordinates. Those coordinates are scaled to
device coordinates to meet expectations of the sendNative methods.
Differential Revision: https://phabricator.services.mozilla.com/D74161
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 reply was never used, and due to other changes in this bug, was causing
ignored exceptions to be thrown occasionally when a query was sent immediately
before unregistering the actor.
Differential Revision: https://phabricator.services.mozilla.com/D82615
This allows to better support navigating to a new BrowsingContext within the same Tab.
Overall, framework codebase is tracking a Browser Element and should use browserId.
Targets may end up being specific to one BrowsingContext/WindowGlobal,
so they may rather use browsingContextID.
Differential Revision: https://phabricator.services.mozilla.com/D81862
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
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
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
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
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
We were getting duplicated nsIScriptError in the Browser Toolbox console and the Browser Console
when the multiprocess pref is enabled, because error from content processes are forwarded to
the main process.
The previous patch of this queue added a isForwardedFromContentProcess flag to nsIScriptError,
that we use in this patch to _not_ handle forwarded messages in multiprocess browser console
and browser toolbox console.
Differential Revision: https://phabricator.services.mozilla.com/D78231
We were getting duplicated nsIScriptError in the Browser Toolbox console and the Browser Console
when the multiprocess pref is enabled, because error from content processes are forwarded to
the main process.
The previous patch of this queue added a isForwardedFromContentProcess flag to nsIScriptError,
that we use in this patch to _not_ handle forwarded messages in multiprocess browser console
and browser toolbox console.
Differential Revision: https://phabricator.services.mozilla.com/D78231
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
OuterWindow ID is deprecated in a Fission world and we should rather use Browsing Context ID.
The outer window ID will change when navigating to another origin, loaded in a distinct process,
whereas Browsing Context ID will stay the same.
Differential Revision: https://phabricator.services.mozilla.com/D78253
Before this patch, we were not trying to cleanup anything when the process
was known to be in process of destruction. We assumed that everything would
be cleaned up anyway.
But mochitest is actually asserting that nothing is leaked on process shutdown,
and we are easily leaking many thing when not destroying the target actor!
Differential Revision: https://phabricator.services.mozilla.com/D76156
This should help better classify DAMP errors as this was picked up by TreeHerder log parser,
while not breaking DAMP.
Differential Revision: https://phabricator.services.mozilla.com/D77224
In order to retrieve the list of impacted element for a given CSS warning,
we are evaluating a document.querySelector expression,
using the cssSelector we get from the error itself.
But if the warning message comes from an iframe, we are not retrieving the
impacted elements, only items from the top-level document.
By storing the target actor id a message is emitted from directly in the message
itself, we can retrieve the target front, and use it to do the evaluation against
the right target.
This is not enough though, as non-remote frame don't have a dedicated target,
and we'll be back at square one, using the top-level document to do the evaluation.
In order to fix that, we're passing the innerWindowID to the evaluateJSAsync method,
so it can be used on the server to retrieve the window instance we need.
A test is added to ensure this feature works as expected for iframes, and it
passes with or without fission enabled.
Differential Revision: https://phabricator.services.mozilla.com/D75811
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
Before this patch, we were not trying to cleanup anything when the process
was known to be in process of destruction. We assumed that everything would
be cleaned up anyway.
But mochitest is actually asserting that nothing is leaked on process shutdown,
and we are easily leaking many thing when not destroying the target actor!
Differential Revision: https://phabricator.services.mozilla.com/D76156
In order to test its parsing and serialization, we expose it but protect
it behind a pref.
Besides, I would like to drop layout.css.aspect-ratio-number.enabled in
the next patch because the spec has been updated. It seems we don't have
to keep this pref and we should always use Number.
Differential Revision: https://phabricator.services.mozilla.com/D74955
Reinstate customUserAgent interface for nsIDocShell. This is so it can be used
as a choke-point to catch setting values on docshells which are in the process
of changing process. We don't want to send changes which will be rejected on the
parent side.
This code should be removed once callers setting customUserAgent are refactored
to only occur from parent process.
Differential Revision: https://phabricator.services.mozilla.com/D75006
Fix up the browser_tab_label_during_restore.js test to wait for the right number of tab title changes, since the timing of the tab title updating has now changed.
Differential Revision: https://phabricator.services.mozilla.com/D72562
Now that nsIScriptError have a `isPromiseRejection` flag, we can consume it
in the console to indicate to the user that we're dealing with a promise rejection.
The exception message is then: "Uncaught (in promise) XXX".
A few tests needed to be updated, and we take this as an opportunity to
ensure we have a stacktrace for uncaught promise rejection.
Differential Revision: https://phabricator.services.mozilla.com/D75780
There was no benefit of having cached messages being different from the "live" ones,
so in this patch we make the message packet consistent.
A few tests had to be modified, and we still handle old-style cached
messages for backward compatibility.
Differential Revision: https://phabricator.services.mozilla.com/D75089
Fix up the browser_tab_label_during_restore.js test to wait for the right number of tab title changes, since the timing of the tab title updating has now changed.
Differential Revision: https://phabricator.services.mozilla.com/D72562
Fix up the browser_tab_label_during_restore.js test to wait for the right number of tab title changes, since the timing of the tab title updating has now changed.
Differential Revision: https://phabricator.services.mozilla.com/D72562
This patch use the new `exception` and `hasException` field from nsIScriptError
so we can render the actual object in the message error instead of a stringified
version.
Error object are still displayed using the `customFormat` prop, so we display
only the type + message + stacktrace (but we'll have a way to inspect them
in the sidebar soon).
Existing tests were updated to fix failures, and some tests/test cases were
added to make sure we cover all the different kind of errors we can display
in the console.
Differential Revision: https://phabricator.services.mozilla.com/D71288
This patch use the new `exception` and `hasException` field from nsIScriptError
so we can render the actual object in the message error instead of a stringified
version.
Error object are still displayed using the `customFormat` prop, so we display
only the type + message + stacktrace (but we'll have a way to inspect them
in the sidebar soon).
Existing tests were updated to fix failures, and some tests/test cases were
added to make sure we cover all the different kind of errors we can display
in the console.
Differential Revision: https://phabricator.services.mozilla.com/D71288
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
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
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
Raw Cr.ERROR don't get stack information, same as throwing JS literals instead
of `new Error()`s.
This was done automatically with a new eslint rule that will be introduced in
the next commit. One instance of a raw Cr.ERROR was not replaced since it is
used in a test that specifically checks the preservation of raw Cr values in
XPCJS. The rule will be disabled for that instance.
Differential Revision: https://phabricator.services.mozilla.com/D28073
We no longer need to fire fake mouse events after replacing `sendTouchEvent` with `sendNativeTouchPoint` in D69885.
Depends on D69885
Differential Revision: https://phabricator.services.mozilla.com/D72905
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
The new `followWindowGlobalLifeCycle` argument and field makes the actor behaves like a WindowGlobalTargetActor and only care about the current global (and all its inner iframes, still).
But it ignores the previous/next document. We still uses the DebuggerProgressListener, but mostly for iframes.
will-navigate and navigate are irrelevant for this actor now.
The plan would be to eventually switch all codepaths to this WindowGlobalTargetActor and rename it.
For now, this would only be used for remoted iframes, only additional frame targets.
But not for top level document, nor top level target switching.
Differential Revision: https://phabricator.services.mozilla.com/D65521
When remote-debugging a device, it might happen that the device clock
is not exactly at the same time as the client clock. In such case, we
may end up in cases where the result of a command as an older timestamp,
which means we could have in the console output a result that was displayed
before the command message that triggered it.
In order to fix this, we add a `startTime` property on the evaluateJSAsync
response, that we can then check on the client. If the server time is
older than the client time, then we remove the existing command message
and add a new one, with the server timestamp.
We could have waited the result of the command before displaying the
command message (so we don't have to add a message, and then remove it
when the timestamps don't match), but the UI wouldn't feel snappy, and
even worse in case of long execution times (e.g. a top-level await fetch command).
Differential Revision: https://phabricator.services.mozilla.com/D72705
When remote-debugging a device, it might happen that the device clock
is not exactly at the same time as the client clock. In such case, we
may end up in cases where the result of a command as an older timestamp,
which means we could have in the console output a result that was displayed
before the command message that triggered it.
In order to fix this, we add a `startTime` property on the evaluateJSAsync
response, that we can then check on the client. If the server time is
older than the client time, then we remove the existing command message
and add a new one, with the server timestamp.
We could have waited the result of the command before displaying the
command message (so we don't have to add a message, and then remove it
when the timestamps don't match), but the UI wouldn't feel snappy, and
even worse in case of long execution times (e.g. a top-level await fetch command).
Differential Revision: https://phabricator.services.mozilla.com/D72705
Daisuke Akatsuka
Alexandre Poirot
Mihai Alexandru Michis
Nicolas Chevobbe
manas
Razvan Maries
Narcis Beleuzu
Julian Descottes
Bogdan Tara
Hubert Boma Manilla
Kris Maglione
Christoph Kerschbaumer
Noemi Erli
Butkovits Atila
Kriyszig
Logan Smyth
wartmanm
Sebastian Streich
Taegeon Lee
Dorel Luca
Jeremy Ir
Yura Zenevich
Brad Werth
Sonia Singla
Alexander Surkov
Mark Banner
Emilio Cobos Álvarez
Kashav Madan
Luca Greco
Cameron McCormack
Johann Hofmann
Frederik Braun
Farooq AR
Csoregi Natalia
Andrea Marchesini
Andreea Pavel
Matthew Gaudet
Nika Layzell
Razvan Caliman
Samarjeet
Coroiu Cristina
Stepan Stava
Cosmin Sabou
Brindusan Cristian
Sebastian Zartner
Jan Odvarko
Nihanth Subramanya
Tooru Fujisawa
Jason Laster
James Teh
David Walsh
Boris Chiou
Dan Glastonbury
David Teller
Neil Deakin
Tom Schuster
Ian Moody
Julien Wajsberg
Micah Tigley
Ciure Andrei