When running test_webconsole-node-grip.html with server side target switching,
the test was failing as accessing this._connections[connID] was returning a
null object.
From some quick investigation, it looks like the object was nullified after
a first connection was closed.
Retrieving all the connection objects before looping closing them seems to
fix the issue.
Differential Revision: https://phabricator.services.mozilla.com/D121165
10ms time shift isn't enough. Locally --run-until-failure no longer reproduce with 20ms.
This time shift controls the negative time shift we apply to will-navigate
so that it appears *before* dom-loading.
The issue we work around is that will-navigate is notified by the platform
*after* the timestamp for dom-loading is recorded.
Differential Revision: https://phabricator.services.mozilla.com/D121054
We need to use documentStoragePrincipal rather than the regular document principal, because it
contains the partitionKey which is used to isolate storage of third-party resources.
Differential Revision: https://phabricator.services.mozilla.com/D120853
Add initial support for the color-scheme CSS property, allowing pages to
choose between light and dark system colors per-element, and such.
Things that are left to do so that this can be enabled by default:
* Dark system colors on Windows / Android / Standins.
* Dark Canvas/CanvasText/Link visited colors (which right now are set
via PreferenceSheet).
* Dark form controls in nsNativeBasicTheme.
* Processing the color-scheme meta tag to fill-in
Document::mColorSchemeBits.
But this seems like enough progress to be landable on its own.
Differential Revision: https://phabricator.services.mozilla.com/D120843
This helps enabling server targets only for local tabs descriptors
and so prevents enabling them for about:debugging toolboxes.
They are always using remote tabs descriptors and do not support target switching yet.
Differential Revision: https://phabricator.services.mozilla.com/D120629
target actor's will-navigate and navigate is no longer fired with server targets.
These two tests are still asserting them, so disable server target in these two tests.
We should probably remove them once we drop the server target preference (bug 1721852).
Differential Revision: https://phabricator.services.mozilla.com/D120947
Wait for accessibility front to be available on target switch in the client.
Disable accessibility service on ParentAccessibilityActor destroy.
Differential Revision: https://phabricator.services.mozilla.com/D120827
Destroy previous target before instantiating a new one.
Otherwise we will destroy it after having setup the new one
and the teardown sequence of the previous may undo the setup of the second.
Typically, in styleeditor, the `styleSheetChangeEventsEnabled` boolean would be toggled
to true by the new target and reset back to false by the old target.
Differential Revision: https://phabricator.services.mozilla.com/D120342
Introduce a new watcher for DOCUMENT_EVENT, now running in the parent process.
This watcher will only emit the "will-navigate" resource and we will stop emitting it from the
existing watcher, running in the content process. (except for iframe switching. i.e. the iframe dropdown menu)
We have to move it to the parent to better handle bfcache navigations
and more generally all navigations which are initiated from the parent process.
bfcacheInParent feature enabled many types of navigations to be controlled from the parent process.
This was especially important to have this implementation in the parent
because the navigation event may be fired too late in the content process.
Leading to will-navigate being emitted *after* the new target we navigate to is notified to the client.
Differential Revision: https://phabricator.services.mozilla.com/D116383
In this patch, we pass a property alongside the DevToolsFrameChild:bf-cache-navigation-pageshow
message that indicates if a new target is being created as a result of this
bfcache navigation.
This flag is then used in the ParentProcessStorage to spawn a new StorageActorMock
when a new target is being created.
As a result we can stop disabling the bfCacheInParent pref in browser_storage_cookies_navigation.js,
where a bfcache navigation is performed.
Differential Revision: https://phabricator.services.mozilla.com/D120438
This makes browser_touch_device.js and browser_toolbox_rule_view_reload.js pass
with server side target switching enabled.
Differential Revision: https://phabricator.services.mozilla.com/D120457
The functions were only called from RDM ui `updateTouchSimulation`, before
the call to updateConfiguration for touch simulation, based on the touch simulation value.
This means we can directly set the proper flag on the docShell in
BrowsingContextTargetActor#updateTargetConfiguration before handling touch simulation.
The devtools.responsive.metaViewport.enabled pref is removed, as it was set to
true by default, and wasn't exposed in any UI.
Differential Revision: https://phabricator.services.mozilla.com/D120456
setupInParent is now only used by WebExt toolbox, which should have
server side targets enabled.
Keep setupInParent tests running until we migrate WebExt toolbox to resources.
This is blocked on supporting WebExt targets by the Watcher actor (bug 1675456).
We can't remove any usage of setupInParent in storage until this is done.
Differential Revision: https://phabricator.services.mozilla.com/D120448
We weren't emitting window-ready in case of iframe switching,
leading to some breakage in walker actor not updating correctly when using the iframe dropdown.
Differential Revision: https://phabricator.services.mozilla.com/D120339
In the ParentProcessStorage class, we are listening for window-global-created/destroyed
event to notify the client that hosts can be added/removed.
But in case of bfcache navigation, those events are not emitted.
In order to fix this issue, we forward pageshow and pagehide events from the
DevToolsFrameChild to the DevToolsFrameParent, where the watcher actor can emit
those events, which we'll be listened to by the ParentProcessStorage.
Test cases are added to ensure this works as expected.
Differential Revision: https://phabricator.services.mozilla.com/D118325
The check from `shouldNotifyWindowGlobal` was only used from frame-target helper, from the parent process.
The only case it was filtering out was for browser toolbox watcher,
where we were filtering out tabs with about:blank loaded in a content process.
We weren't having any issues around about:blank with tab watchers.
I added test coverage for tab watchers, but they were already passing.
The check in DevToolsFrameChild was wrong with the browser toolbox codepath.
We don't have any browserId. This wasn't throwing because shouldNotifyWindowGlobal
was rejecting the about:blank documents.
This issue was catched by browser_console_content_object_in_sidebar.js,
which probably only involve about:blank documents.
Differential Revision: https://phabricator.services.mozilla.com/D117466
ActorReadyGeckoProfilerInterface is used in two contexts:
- For the perf actor, which is used when the profiler is used from the
devtools Performance panel or via remote debugging (on about:debugging), and
- On about:profiling, which only exercises a subset of the interface's methods
because about:profiling does not have any UI for capturing profiles.
There are three other ways to capture profiles:
- The global browser keyboard shortcuts (implemented in DevToolsStartup.jsm)
- Clicking the toolbarbutton directly (implemented in popup/menu-button.jsm.js)
- Clicking the Capture button inside the popup (implemented in popup/panel.jsm.js)
These three other ways use functions in popup/background.jsm.js to capture the profile.
They do not call ActorReadyGeckoProfilerInterface.getProfileAndStopProfiler().
When the ActorReadyGeckoProfilerInterface instance for the perf actor is created,
we pass { gzipped: false }. Consequently, ActorReadyGeckoProfilerInterface.getProfileAndStopProfiler()
is only ever called with gzipped: false. So the option can be removed.
The other three ways to capture profiles, which use captureProfile in
popup/background.jsm.js, always get the gzipped profile because captureProfile
calls Services.profiler.getProfileDataAsGzippedArrayBuffer().
Differential Revision: https://phabricator.services.mozilla.com/D119561
`beforeinput` event was shipped and it won't be disabled for avoiding confusion
of web developers. So, we can drop the pref setting of
"dom.input_events.beforeinput.enabled" in our tests.
Depends on D119716
Differential Revision: https://phabricator.services.mozilla.com/D119729
I don't think it was any useful to block synchronously on the call to `doResume`.
In the past it used to send an event to the client synchronously,
it may have been important back then.
test_nesting-03.js is still covering nested event loop by using two clients.
Differential Revision: https://phabricator.services.mozilla.com/D118173
Slow runtimes highlight race conditions explain in bugzilla comment 3,
which aren't trivial to address. So better disable this test on debug builds for now.
And at least keep it running on opt.
Differential Revision: https://phabricator.services.mozilla.com/D119323
* avoid unwatching DOCUMENT_EVENT in case of target-switching
* ensure emitting DevToolsFrameChild:destroy for all currently registered target actors
(didDestroy was clearing the list of actors used by _getTargetActorForWatcherActorID)
* do not try to stop and restart server side watchers in case of bfcache navigation
Differential Revision: https://phabricator.services.mozilla.com/D118795
Nicolas Chevobbe
Alexandre Poirot
Claudia
Christoph Kerschbaumer
Sandor Molnar
Paul Zuehlcke
Emilio Cobos Álvarez
Hubert Boma Manilla
Markus Stange
Dana Keeler
Masayuki Nakano
Luca Greco
Julian Descottes