Still use a shouldCloseClient flag, but instead of closing the client from the target's destruction,
from which we should ignore cross process target switching,
we now close it from the descriptor destruction.
Descriptor destruction should only happen when the toolbox is meant to be closed.
Differential Revision: https://phabricator.services.mozilla.com/D106835
- implement the new "inspected-window" command
- move WebExtensionInspectedWindowFront implement to the command, making the front empty
- migrate tests to use the commands instead of front
- stop maintaining the current top level target in ExtensionParent.jsm, no longer have to use watchTargets
- stop creating a new descriptor on each new target
- instead only pull one new dedicated "commands" for WebExt (still in ExtensionParent.jsm)
- remove TabDescriptor isDevToolsExtensionContext as we no longer need anything special in the descriptor
- remove now unused methods on DevToolsShims (createWebExtensionInspectedWindowFront, createDescriptorForTabForWebExtension)
- remove the now unused TabDescriptorFactory.createDescriptorForTab's "forceCreationForWebextension" option, as CommandsFactory.forTab always instantiate a brand new commands
- migrate webext to use the command instead of front
Differential Revision: https://phabricator.services.mozilla.com/D108994
Move the methods of the targetCommand that were related to targetConfiguration
to a dedicated command.
We also move the custom TargetConfigurationFront methods into the command.
Callsites are modified to use the new command. Doing so for the debugger involved
a bit more work as we needed to pass the command to the existing `setupCommands`
bootstrap function.
Differential Revision: https://phabricator.services.mozilla.com/D110200
This adds a resource for the cookie storage type, that supports inspecting iframes, etc. on Fission.
NOTE: in order to use this new resource, set the `devtools.testing.enableServerWatcherSupport` to `true`
Differential Revision: https://phabricator.services.mozilla.com/D108040
This adds a resource for the cookie storage type, that supports inspecting iframes, etc. on Fission.
NOTE: in order to use this new resource, set the `devtools.testing.enableServerWatcherSupport` to `true`
Differential Revision: https://phabricator.services.mozilla.com/D108040
Enabling the support for stylesheet resources highlighted some issue with the
current situation.
A couple server tests needed to instantiate a resource watcher to pass.
We also add a test case for link from inspector to stylesheet when doing a same
process navigation (we already had one for target switching).
Differential Revision: https://phabricator.services.mozilla.com/D106081
With the previous patches in this queue, it looks like the
timing is stlightly modified, and on initial load we can
reveive stylesheet resources _before_ the intial dom-loading
event.
Since we're using dom-loading to clear the UI, we might destroy
stylesheets that we shouldn't.
We fix that in 2 folds:
- clear the UI in onTargetAvailable, which we do receive before any resources
- add a flag to the `dom-loading` resource when we're already going to be triggering
onTargetAvailable for a given interaction (toolbox opening, cross-process
navigation or any navigation when target will follow the global lifecycle).
Differential Revision: https://phabricator.services.mozilla.com/D109471
This was previously done in the inspector panel initialization phase, after the
inspector front was created, which could lead to races.
Since the pageStyle actor requires stylesheets to being watched (when watcher
support is enabled), we do this in the inspector front, before creating the
page style actor.
We put the resourceWatcher instance on targetFront from resourceWatcher#_onTargetAvailable
so we can use it from everywhere.
Differential Revision: https://phabricator.services.mozilla.com/D109470
Enabling the support for stylesheet resources highlighted some issue with the
current situation.
A couple server tests needed to instantiate a resource watcher to pass.
We also add a test case for link from inspector to stylesheet when doing a same
process navigation (we already had one for target switching).
Differential Revision: https://phabricator.services.mozilla.com/D106081
With the previous patches in this queue, it looks like the
timing is stlightly modified, and on initial load we can
reveive stylesheet resources _before_ the intial dom-loading
event.
Since we're using dom-loading to clear the UI, we might destroy
stylesheets that we shouldn't.
We fix that in 2 folds:
- clear the UI in onTargetAvailable, which we do receive before any resources
- add a flag to the `dom-loading` resource when we're already going to be triggering
onTargetAvailable for a given interaction (toolbox opening, cross-process
navigation or any navigation when target will follow the global lifecycle).
Differential Revision: https://phabricator.services.mozilla.com/D109471
This was previously done in the inspector panel initialization phase, after the
inspector front was created, which could lead to races.
Since the pageStyle actor requires stylesheets to being watched (when watcher
support is enabled), we do this in the inspector front, before creating the
page style actor.
We put the resourceWatcher instance on targetFront from resourceWatcher#_onTargetAvailable
so we can use it from everywhere.
Differential Revision: https://phabricator.services.mozilla.com/D109470
We have two parts in the codebase that we get the browsingContextId.
1) Inside the DOM code with profiler_register_page function whenever a
navigation happens.
2) Inside the profiler recording front-end when we start the profiler. That was
kept as activeBrowsingContextID, and now it's kept as activeTabID.
We are now changing these parts to keep the browserId instead so it directly
corresponds to the tabs. BrowsingContexts are replaced when there is a
cross-group navigation, but BrowserId is being preserved.
Differential Revision: https://phabricator.services.mozilla.com/D109281
This patch is only about renaming the internals of the profiler codebase and
it doesn't touch any parts that requires a backwards compatibility or version
bump.
Differential Revision: https://phabricator.services.mozilla.com/D109280
I kept a few having some overrides. But they may be irrelevant.
And I kept some eslint files for all folder that aren't matching the pattern matching "**/test*/**/browser*/".
Ideally we would rename these folder to match.
Last but not least, I identified one case where we were using mochitest file for xpcshell tests!
Differential Revision: https://phabricator.services.mozilla.com/D109481
A long standing issue is that MOZ_ASSERT and related don't print stack
traces in debug builds when they're directly or indirectly emitted from
non-libxul code. Moving WalkTheStack to mozglue alleviates the problem.
It's also not printing stack traces when emitted from C code (and for
some C third party libraries, we do redirect assert to MOZ_ASSERT),
which we solve by making the corresponding API available without C++
(which WalkTheStack being a static method of the nsTraceRefCnt class
didn't allow, or the use of a closure on Android).
This requires some adjustements to headers that indirectly assume that
Assertions.h includes ErrorList.h through nsError.h through nscore.h
through nsTraceRefcnt.h.
We also remove TestStackCrawl.cpp because it hasn't been built since
bug 158528, 19 years ago.
Differential Revision: https://phabricator.services.mozilla.com/D108913
This parsing is hidden behind the pref layout.css.page-size.enabled.
It isn't ideal that we parse this as a property, but we can't treat it as a
descriptor because of compatibility issues with other browsers. There are also
outstanding spec issues related to how descriptors like page-size are cascaded,
and whether the !important specifier is valid or not.
Differential Revision: https://phabricator.services.mozilla.com/D103958
Because targetFront.url may not be properly updated, this isn't a reliable attribute
to assert that we got the expected target.
First, the url passed via Target's form may be about:blank,
then will-navigate and navigate events might be missed and url won't be correctly updated.
Differential Revision: https://phabricator.services.mozilla.com/D109039
Like BrowsingContextTargetActor.detach which was throwing { error: wrongState }
and we were logging "(void 0)" because error.message was undefined,
while error was the thrown JS object.
Differential Revision: https://phabricator.services.mozilla.com/D107986
This parsing is hidden behind the pref layout.css.page-size.enabled.
It isn't ideal that we parse this as a property, but we can't treat it as a
descriptor because of compatibility issues with other browsers. There are also
outstanding spec issues related to how descriptors like page-size are cascaded,
and whether the !important specifier is valid or not.
Differential Revision: https://phabricator.services.mozilla.com/D103958
Close method may be called by the transport on close.
This was highlighted by browser_target_from_url.js
Surprisingly devtools/shared/tests/xpcshell/test_debugger_client.js
tries quite hard to cover such issue, but we seem to get yet another type of reentrancy.
This probably depends on WebSocketTransport, which is a bit hard to get covered.
No test seems to be spawning a WebSocket DevToolsServer...
Differential Revision: https://phabricator.services.mozilla.com/D107988
Still use a shouldCloseClient flag, but instead of closing the client from the target's destruction,
from which we should ignore cross process target switching,
we now close it from the descriptor destruction.
Descriptor destruction should only happen when the toolbox is meant to be closed.
Differential Revision: https://phabricator.services.mozilla.com/D106835
Close method may be called by the transport on close.
This was highlighted by browser_target_from_url.js
Surprisingly devtools/shared/tests/xpcshell/test_debugger_client.js
tries quite hard to cover such issue, but we seem to get yet another type of reentrancy.
This probably depends on WebSocketTransport, which is a bit hard to get covered.
No test seems to be spawning a WebSocket DevToolsServer...
Differential Revision: https://phabricator.services.mozilla.com/D107988
Starting with macOS 10.14, the generic light/dark vibrancy is deprecated, and semantic vibrancy names are preferred.
If we ever need more vibrancy, we can add new values with semantic names.
Depends on D107910
Differential Revision: https://phabricator.services.mozilla.com/D108152
When enabling the watcher support, we end up having duplicate platform messages as we
received them both from the content process and the parent process (the messages are cloned).
A couple test cases are added to ensure we handle all kind of messages properly.
Depends on D107648
Differential Revision: https://phabricator.services.mozilla.com/D103285