Doing this helps knowing if some resources are coming from ResourceCommand cache,
or if they are live resources coming from the server.
Differential Revision: https://phabricator.services.mozilla.com/D116984
We were calling ResourceCommand.watchResources from onTargetAvailable, whereas we could and should
call it once before or after calling TargetCommand.watchTargets.
Doing this helps calling watchResources only once, for all the resource types.
Also tweaked networkFront and responsiveFront instantiation.
to only instantiate them when we need them.
Differential Revision: https://phabricator.services.mozilla.com/D116983
Support fit-content for preferred size, min size, and max size. This
patch only implement the style system. For layout part, we will do that
in the following patches.
Differential Revision: https://phabricator.services.mozilla.com/D107161
The actor code for attaching/detaching service worker targets and to push/start workers should no longer be used when parentintercept is disabled because all the UI triggering this is disabled in that case.
Consequently we can remove the server side code supporting this. We still have to be able to list service worker targets when parentintercept is disabled, so there are still some codepaths using isParentInterceptEnabled in the server.
Differential Revision: https://phabricator.services.mozilla.com/D116850
The methods is replaced by adhoc SpecialPowers.spawn task
or when possible with getContentPageElementProperty calls.
Depends on D117018
Differential Revision: https://phabricator.services.mozilla.com/D116964
In Bug 1710582, `refreshTab` switched to use `navigateTo` in order to handle target switching.
The catch is that `navigateTo` uses `BrowserTestUtils.loadURI`, which triggers a slightly
different behavior than `gBrowser.reloadTab` (for example, it does not keep the scroll position).
In this patch, we modify `navigateTo` so it uses `reloadTab` if the URL provided for
the navigation is the same as the current one.
Differential Revision: https://phabricator.services.mozilla.com/D117018
Clearing debugger state from onTargetAvaible should be fine,
as soon as we do it immediately.
But doing it from DOCUMENT_EVENT will-navigate may help
if we get some debugger related resources while the target is still attaching on the client.
It should better ensure that state is cleared at the right time, the earliest right time.
Differential Revision: https://phabricator.services.mozilla.com/D116810
`connect` and `willNavigate` actions are redundant, except for the isWebExtension argument.
And calling `connect` late, after a few async code make us reset redux state way too late.
Some sources/breakpoints could be processed before and we end up having confusing state.
Differential Revision: https://phabricator.services.mozilla.com/D116809
The methods is replaced by a helper.
Some tests were using testActor.hasNode as
a way to check if a frame switch was successful;
for those we check the markup instead.
Depends on D116692
Differential Revision: https://phabricator.services.mozilla.com/D116818
This helps track all navigations, including the cross process navigation
and navigation with JSWindowActor based targets.
With work from bug 1702511, this also helps clearing at the precise right time.
Differential Revision: https://phabricator.services.mozilla.com/D115818
This helps clearing the netmonitor it all navigation, including the cross process navigation
and navigation with JSWindowActor based targets.
With work from bug 1702511, this also helps clearing at the precise right time.
Note that nothing special is being done for the initial document request,
but if we need to we can use NETWORK_EVENT's isNavigationRequest boolean
to help make it work.
Differential Revision: https://phabricator.services.mozilla.com/D116032
We don't store an inspectorFront and a target anymore in HighlightersOverlay,
but retrieve them directly from the inspector instance, as this will provide up-to-date
references.
We also dont' listen for `will-navigate` on the target, but call
`HighlightersOverlay#onWillNavigate` from the inspectors's `_onBeforeNavigate`,
which already handle fission usage.
Finally, we switch to DOCUMENT_EVENT `will-navigate` instead of targetFront `will-navigate`
event in order to handle fission cases.
Differential Revision: https://phabricator.services.mozilla.com/D113541
This patch removes the `setTouchEventsOverride` method on the targetConfigurationCommand,
as we're now enabling the touch simulation from the server, in `BrowsingContextActor#updateTargetConfiguration`.
A new configuration property is added, `reloadOnTouchSimulationToggle`, so the
actor is responsible for reloading the page if the user set the pref.
The `touchSimulator` property is moved from the responsive actor to the browsingContext one
to facilitate managing the touch simulation state.
Differential Revision: https://phabricator.services.mozilla.com/D116103
This helps execute code on navigation, even if the document loads super fast
and target actor's navigate is emitted before frontend has a chance to register the navigate event.
Differential Revision: https://phabricator.services.mozilla.com/D115825
This helps clear various things for all navigations, including the cross process navigation
and navigation with JSWindowActor based targets.
With work from bug 1702511, this also helps clearing at the precise right time.
Differential Revision: https://phabricator.services.mozilla.com/D116423
Tests that were using `evaluateJSAsync` are updated, either by using the new command,
or by awaiting for the `evaluationResult` event.
A couple chrome tests were moved to devtools/shared/commands/js/tests/ and turned
into browser tests, and some of them were completely removed as we tested the
features in mochitests as well.
Differential Revision: https://phabricator.services.mozilla.com/D116248
This method is meant to replace the direct usage
of webconsoleFront.evaluateJSAsync.
The WebConsoleCommands file is removed, and all
client calls to evaluateJSAsync are migrated to
the new method. Callsites are simplified when
possible, and some test are refactored to switch
to spawned task to retrieve content page information.
Differential Revision: https://phabricator.services.mozilla.com/D116242
This patch removes the `setTouchEventsOverride` method on the targetConfigurationCommand,
as we're now enabling the touch simulation from the server, in `BrowsingContextActor#updateTargetConfiguration`.
A new configuration property is added, `reloadOnTouchSimulationToggle`, so the
actor is responsible for reloading the page if the user set the pref.
The `touchSimulator` property is moved from the responsive actor to the browsingContext one
to facilitate managing the touch simulation state.
Differential Revision: https://phabricator.services.mozilla.com/D116103
This code calling `watchResourcesForTarget` should only be called when
we already called `TargetCommand.watchTargets()`.
When we call `ResourceCommand.watchResources` for the first time, `TargetCommand.watchTargets`
will process already existing targets and call `ResourceCommand.onTargetAvailable` (which calls `watchResourcesForTarget`).
But for any subsequent call, we should use `TargetCommand.getAllTargets` and call `watchResourcesForTarget` manually.
Differential Revision: https://phabricator.services.mozilla.com/D116027
The method is replaced by an helper in shared-head that uses SpecialPowers.spawn
to access the element.
Depends on D116556
Differential Revision: https://phabricator.services.mozilla.com/D116557
Without this, the new pending call to watchResources throws because we close the toolbox while the console still initiates.
Differential Revision: https://phabricator.services.mozilla.com/D116489
Replace its usage with a helper in shared-head that
scroll to the ndoe matching the selector and then
uses BrowserTestUtils.synthesizeMouse to trigger the
mouse event.
Differential Revision: https://phabricator.services.mozilla.com/D116393
All usage of the methods are replaced with a shared helper
that uses a content task to retrieve the number of elements
on the page.
Differential Revision: https://phabricator.services.mozilla.com/D116341
navigateTo contains all the logic to wait for panel updates on reload,
as well as wait for the process of the new target.
Differential Revision: https://phabricator.services.mozilla.com/D114828
Surprisingly, there is no issue with ResourceWatcher cache,
but only with the WebConsoleWrapper which gets its inner cache purged.
Differential Revision: https://phabricator.services.mozilla.com/D112232
Note that the timestamp being set in WebConsoleWrapper is overriding the one passed from will-navigate
and ends up being wrong and too late.
Differential Revision: https://phabricator.services.mozilla.com/D115974
The following changeset, migrating from target's will-navigate events
to DOCUMENT_EVENT resources, triggers some action dispatch while calling
`_attachTargets`. i.e. Some dispatch* methods of WebConsoleWrapper get called.
But as it wasn't initialized yet, it was throwing.
Differential Revision: https://phabricator.services.mozilla.com/D116024
That's to ensure clearing the panels sooner than later.
A few tests depend on this. Without that, target actor's "navigate" event,
which isn't throttled, fires *before* DOCUMENT_EVENT's will-navigate.
That ends up being a logic issue in the console code.
Differential Revision: https://phabricator.services.mozilla.com/D112230
Share the concept of a panel content with all other menupopups / panels.
This avoids importing global.css in the shadow tree, and renames the
arrowcontent part to just "content", since we want to introduce a
"content" part for other panels.
This shouldn't change behavior but makes bug 1708136 a matter of
tweaking a couple CSS rules and fixing up test failures.
Differential Revision: https://phabricator.services.mozilla.com/D113990
Share the concept of a panel content with all other menupopups / panels.
This avoids importing global.css in the shadow tree, and renames the
arrowcontent part to just "content", since we want to introduce a
"content" part for other panels.
This shouldn't change behavior but makes bug 1708136 a matter of
tweaking a couple CSS rules and fixing up test failures.
Differential Revision: https://phabricator.services.mozilla.com/D113990
One of the SpecialPowers.spawn task was failing because the page was navigating
while the task wasn't over yet.
This seems to be fixed by waiting for the proper document to load, as well as
waiting for the reload that is done when closing RDM.
Differential Revision: https://phabricator.services.mozilla.com/D115369
This patch surface the private properties in Reps and in the ObjectInspector.
Tests cases are added to cover the basic behaviors we want to have in the
same version private fields are shipped in (90).
Differential Revision: https://phabricator.services.mozilla.com/D115685
`assertPreviews` was hovering over a token and then checking the Redux store in
order to assert what should be in the popup. This can be a bit brittle and it's
probably safer to check what's rendered in the DOM, as it directly maps to what's
shown to the user.
Some unused or irrelevant test helpers are removed, and tests are updated accordingly.
Differential Revision: https://phabricator.services.mozilla.com/D115859
This patch makes use of the new `getOwnPrivateProperties` method on DebuggerObject
to include private properties in object grip preview.
We're also adding a PrivatePropertiesIterator actor (and associated front) that
will allow us to retrieve all the private properties (e.g. when expanding an
object in the ObjectInspector).
A xpcshell test is added to ensure we do return the expected properties.
Differential Revision: https://phabricator.services.mozilla.com/D115702
In the case a custom error object was defining the `name` and/or `message` property
in getters, we weren't displaying those information in the console.
That's because when retrieving those information, we were avoiding calling getters,
as they're deemed unsafe.
In those specific case, even if unsafe, we always want to show it to the user
so they're not missing any information when debugging.
A test case is added to ensure this works as expected and we don't regress.
Differential Revision: https://phabricator.services.mozilla.com/D115678
* Stop memoizing web console front
* track navigations via DOCUMENT_EVENT's dom-complete
* await for HarAutomation async initialization from toolbox codebase
These changes help fix browser_harautomation_simple.js.
But this isn't enough as will-navigate can easily be missed.
Differential Revision: https://phabricator.services.mozilla.com/D114464
This introduces uncessary complexity and makes it uterly complex to wait
for HarAutomation's async initialization.
Its init isn't async yet.
Differential Revision: https://phabricator.services.mozilla.com/D114837
About browser_jsterm_autocomplete_getters_cache, we weren't correctly waiting
for popup to close because of the reload. Instead we probably worked around intermittents
by closing the popup explicitly before the reload.
But that creates other issue, where the reload may close the popup *after* we do Ctrl+Space.
(this patch doesn't trigger any issue with this test, but better fix that)
Differential Revision: https://phabricator.services.mozilla.com/D112231
One of the SpecialPowers.spawn task was failing because the page was navigating
while the task wasn't over yet.
This seems to be fixed by waiting for the proper document to load, as well as
waiting for the reload that is done when closing RDM.
Differential Revision: https://phabricator.services.mozilla.com/D115369
The underlying issue was fixed on platform in Bug 1709542,
so we're adding a test case to make sure this won't regress
in the future.
Differential Revision: https://phabricator.services.mozilla.com/D114822
Since ergonomic brand check were enabled in Bug 1710510,
babel needs support to parse script using this new syntax.
A test case is added, and the test was failing without the
new plugin.
Differential Revision: https://phabricator.services.mozilla.com/D115381
This patch adds a `refreshTargets` action that is called from the toolbox when
a dom-interactive DOCUMENT_EVENT is received.
This action will only update a new state property, `lastTargetRefresh`, with the
current timestamp, so the `EvaluationContextSelector` component will re-render;
as the target information are directly retrieved from the target fronts, any
changes in the title/url will be shown in the component.
Differential Revision: https://phabricator.services.mozilla.com/D115205
This will be consumed by the toolbox to not update detached window title when
the user triggered a frame switching (i.e. selected a document in the frame switcher
menu in the toolbar).
Differential Revision: https://phabricator.services.mozilla.com/D115204
This patch adds a `refreshTargets` action that is called from the toolbox when
a dom-interactive DOCUMENT_EVENT is received.
This action will only update a new state property, `lastTargetRefresh`, with the
current timestamp, so the `EvaluationContextSelector` component will re-render;
as the target information are directly retrieved from the target fronts, any
changes in the title/url will be shown in the component.
Differential Revision: https://phabricator.services.mozilla.com/D115205
This will be consumed by the toolbox to not update detached window title when
the user triggered a frame switching (i.e. selected a document in the frame switcher
menu in the toolbar).
Differential Revision: https://phabricator.services.mozilla.com/D115204
This is necessary to remove the Init methods from principals, allowing
immutable fields to be marked as const and clearly separated from mutable
fields to improve threadsafety.
Differential Revision: https://phabricator.services.mozilla.com/D115091
As an intermediate step to allow mach commands as standalone functions, the MachCommandBase
subclass instance that currently corresponds to self has to be made available as a separate
argument (named command_context).
Differential Revision: https://phabricator.services.mozilla.com/D109650
The event listeners that were set in the constructor were not
actually removed in the `on` method, as we weren't using the
proper function reference.
Furthermore, the event listeners were removed only if some
resources were put in the cache, which could lead to some
buggy behavior when watching/unwatching multiple times.
Differential Revision: https://phabricator.services.mozilla.com/D114927
Event listeners were set on target available, but they were never removed, which
could cause issue if a consumer was watching/unwatching for resources multiple
times.
A test (that was failing without this patch), is added to ensure we don't regress this.
Note that the test is still incorrect and will be properly fixed in Bug 1710674.
Differential Revision: https://phabricator.services.mozilla.com/D114926
When using JSWindowActor based target, each target actor is destroyed on each reload/navigation.
This code in walker actor is registering a DOMContentLoaded listener which
only fires after the target is already destroyed. This leads to exceptions.
Differential Revision: https://phabricator.services.mozilla.com/D114367
When enabling devtools.target-switching.server.enabled, all frame targets will be
instantiated from the server side, including the very first top level target.
With this pref turned off, top level targets would always be created on-demand
by the frontend. But that delays the target creation and makes the frontend miss early events/resources.
With this pref turned on, top level frame targets are now all using JSWindow actor.
It also means that their lifecycle is following the WindowGlobal one.
Instead of having one target per DocShell, which will be reused on reloads
and same-process navigations, we will have one target per top level WindowGlobal.
So that even reloads and same-process navigations will spawn a new target.
Differential Revision: https://phabricator.services.mozilla.com/D106551
Use a unique way to know if we have a top level BC / a BC without a parent: `!browsingContext.parent`.
This is typically where we want to know if the BC is the top level tab document.
Also start using `isProcessRoot` in order to know if a BC is either a top level BC,
or, if its embedder is in another process. a.k.a. "top BC in a given process".
Remote iframes in a tab will have a `parent` attribute refering to the top level tab document,
while their `isProcessRoot` will be true.
We will typically use this flag to know if we should spawn a target for the given BC.
Differential Revision: https://phabricator.services.mozilla.com/D114830
This fixes an issue we had with pretty printing scripts
containing private fields.
A test case is added in browser_dbg-pretty-print.js to
ensure it stays this way.
Differential Revision: https://phabricator.services.mozilla.com/D114816
All these get* methods were hosted on WebConsole fronts,
but weren't related to WebConsole actor.
Instead they all target the NetworkEvent actors.
These actors runs in the parent process, where we listen for network requests.
Going through console fronts were an issue during target switching
as there is a small window in between the previous and new target where
there is no webconsole front being alive. The previous's page one is destroyed
and the new page's one is not yet available.
All that while the network event actors are always available.
We could only remove these get* methods once we refactor all tests still using them.
Also it would be great to followup and stop having one actor per request,
and instead fetch these attributes via the network-parent actor.
By doing this, we could finaly drop the last usage of DevToolsClient.request and make _requestData much simplier.
Differential Revision: https://phabricator.services.mozilla.com/D114538
Symbols are information on the structure of a given script (assignments, functions,
expressions, …)
This patch handles scripts using private fields and fixes a few things in the debugger:
- we get the full expression when hovering a private property access,
a prerequisite to get the value of a private propery in the variable tooltip
(which will be handled in Bug 1709567).
- private methods now show up in the outline view under their proper name, and
not `anonymous`. `simplifyDisplayName` was fixed as well to not strip the `#`
at the start of the method name.
Tests are added to ensure this works as expected.
A side-effect from modifying examples/simple1.js is that browser_dbg-outline-pretty.js
was broken since pretty-fast wasn't able to parse file with private fields syntax.
pretty-fast is updated to its latest version and the pretty-print worker is updated
so the test does not break anymore.
Depends on D114345
Differential Revision: https://phabricator.services.mozilla.com/D114459
The very first navigation wasn't using navigateTo and that caused some exception
because we were trying to use previous target's memory front which was already destroyed.
I also removed this now uncessary fork of navigateTo.
Differential Revision: https://phabricator.services.mozilla.com/D114478
After some investigations,I'l try to explain what i see. What seems to be happening is that the data provider is
intialized when the webconsole-ui is initialized so that is when the instance of the console
front is created. When a target switch happens, that instance of the console front gets destroyed
so when the data provider needs to request the network details it fails and this._client
is null.
This patch moves the creation of the data provider to onTargetAvailable (as we do with that in the network panel).
This fixes the issue, and TRY seems to be good with it, I wonder if this is best solution or this can be improved.
What are your thoughts?
I can add a test if we think this is the way to go.
Differential Revision: https://phabricator.services.mozilla.com/D113167
Now that _startListening is synchronous, we can fix the race conditions
that exists between many calls made to watch and unwatch resources.
And we would benefit from simplifying the various ways to track
what resources is being watched.
We no either use _watchers and _pendindWatchers to have the live number
of registered listeners. And in parellel to that, only record
which resources is being watched on the server via _listenedResources.
Differential Revision: https://phabricator.services.mozilla.com/D114415
This is the ultimate change in order to ensure calling _startListening
synchronously from watchResources.
Fixes are required to styles tests, as watchAllTarget is only called if we pass a valid resource type.
Differential Revision: https://phabricator.services.mozilla.com/D114414
Calling it twice in a row makes it never resolve.
The actor implementation could probably be made more resilient,
but memoizing it on the front would probably help reduce the number of request we are doing.
This issues appears with the first changeset, parellizing the call to ResourceCommand._startListening.
Differential Revision: https://phabricator.services.mozilla.com/D114413
This isn't solely for performance reason.
This will help ensure calling _startListening synchronously when calling watchResources.
This is to help simplify the various states store to track which resources are being watched.
And ultimately fix races between watch and unwatch.
Differential Revision: https://phabricator.services.mozilla.com/D114411
If an expression contained a class with private fields, getExpressionVariables
would return an array with undefined elements, which was making the JSPropertyProvider
fail on the server.
This is fixed by checking that we don't add falsy value into the array of variables.
The existing test for variable autocomplete is expanded to assert this case.
Differential Revision: https://phabricator.services.mozilla.com/D114460
The URLs of network requests containing Unicode characters are now displayed encoded within the Console. Previously, the domains were shown in punycode and the paths had a URL encoded representation.
This change makes their display consistent with the one within the Network Monitor.
Users can still see the punycode version of the domain at the top of the Headers view. And the encoded version of the URL parameters is displayed within the raw request headers view.
Differential Revision: https://phabricator.services.mozilla.com/D110711
We're using frame-helper#createTargets to set the flag as we're already looping
over the browsing context we need to handle.
We keep a Map of watcher/observer so we can remove the observer when the targets
get destroyed.
For the browser toolbox top-level browsing context we keep setting the flag in
the browsing context target actor as it lives in the parent process, and we
don't have watcher support enabled by default, so frame-helper wouldn't be hit.
frame-helper is not used in the legacy browser toolbox, so we won't set the flag
on tabs when devtools.browsertoolbox.fission is false, but that's okay it's not
currently set anyway in this setup.
Tests are added with multiple cases to ensure the flag is set in different situations.
Differential Revision: https://phabricator.services.mozilla.com/D113628
Depends on D114198
The isDevToolsExtensionContext flag was removed in Bug 1699493, we should be able to remove this check
Differential Revision: https://phabricator.services.mozilla.com/D114199
We no longer support connecting to FF87. emitDescriptorDestroyed was added to all tab descriptors in FF88 so all the code checking it can be removed.
Rephrased the comment around the about:debugging use case.
Differential Revision: https://phabricator.services.mozilla.com/D114198
The rest of the patches in this stack will remove WatcherActor traits.
But the call sites should still check that the watcher is available.
Making the argument optional allows to reuse the same method as we remove the traits.
Differential Revision: https://phabricator.services.mozilla.com/D114216
This test was added in Bug 1651420, and then broken silently, due to an error
in the activation of the test by Bug 1653567. This edge case behaviour
shouldn't block us from landing private fields and methods
Tracking fixing this I have opened Bug 1708812.
Differential Revision: https://phabricator.services.mozilla.com/D114016
MarkupView#destroy is synchronous, so there's no need for _destroyMarkup to return
a Promise.
The different callsites don't do anything with the returned value so there's nothing
more to cleanup.
Differential Revision: https://phabricator.services.mozilla.com/D113803
This was making 2 tests failing:
- browser_toolbox_selectionchanged_event.js had a pending promise that would make
the test fail (whereas pending Promise.jsm don't). It was setting an `undefined`
selected node with a reason, which is something we don't do in the codebase (we set
it to null, with no reason). So here we change it by setting the selection to a
null node, which is consistent with real world scenario.
- browser_markup_shadowdom_clickreveal.js was failing because the container of
a node was slotted while it shouldn't be. It looks like the switch to DOM Promises
changed the timing slightly, so we're now waiting in the test to make sure we
have another container than the slotted one we were handling before.
Differential Revision: https://phabricator.services.mozilla.com/D113539
As the inspector front initialization is asynchronous and can take some time,
we might miss will-navigate events being emitted very early (e.g. when a new
navigation happen just after a previous one).
Differential Revision: https://phabricator.services.mozilla.com/D113481
the test document has a script that adds dom nodes, js sources and stylesheet
to the document every 200ms. It might that the navigateTo call we were using to navigate
to the document would never resolve, as the load event won't fire because of the constant
addition of stylesheets and scripts.
This is fixed by not using navigateTo, as we don't really need the document to be ready,
but only register the navigation so later in the test we can do backward and forward navigations.
Differential Revision: https://phabricator.services.mozilla.com/D113480
In the `BrowserTestUtils.browserLoaded` call we use in `navigateTo`, we weren't
checking for a specific uri to be loaded, which means the Promise could resolve
on *any* page being loaded.
This patch makes it more secure by waiting the load event for the uri we navigated to.
Differential Revision: https://phabricator.services.mozilla.com/D113479
It's the wrong pseudo-class name! Plus, it's not really needed, just
override the page styles temporarily.
Remove the pseudo-class, since it's its only remaining usage.
Differential Revision: https://phabricator.services.mozilla.com/D113374
It could happen that 2 warning group messages could be added successively, before
the navigation message was emitted.
In the reducer, the second message would be seen the same as the first one, and
we'd try to increment the repeat count for the first one.
Unfortunately, the code was expecting a warning group to be created, and there
was an exception thrown as we couldn't retrieve it.
This is fixed by not allowing warning groups to be repeated.
A mocha test is added instead of a mochitest, as the issue would have been tricky
to trigger properly.
Differential Revision: https://phabricator.services.mozilla.com/D113276
As the inspector front initialization is asynchronous and can take some time,
we might miss will-navigate events being emitted very early (e.g. when a new
navigation happen just after a previous one).
Depends on D113480
Differential Revision: https://phabricator.services.mozilla.com/D113481
the test document has a script that adds dom nodes, js sources and stylesheet
to the document every 200ms. It might that the navigateTo call we were using to navigate
to the document would never resolve, as the load event won't fire because of the constant
addition of stylesheets and scripts.
This is fixed by not using navigateTo, as we don't really need the document to be ready,
but only register the navigation so later in the test we can do backward and forward navigations.
Depends on D113479
Differential Revision: https://phabricator.services.mozilla.com/D113480
In the `BrowserTestUtils.browserLoaded` call we use in `navigateTo`, we weren't
checking for a specific uri to be loaded, which means the Promise could resolve
on *any* page being loaded.
This patch makes it more secure by waiting the load event for the uri we navigated to.
Differential Revision: https://phabricator.services.mozilla.com/D113479
This removes the testing enableServerWatcherSupport flag for indexedDB and cookies resources. As a consequence of this, some tests that were previously marked as failing on fission now pass, so they have been re-enabled as well.
Differential Revision: https://phabricator.services.mozilla.com/D113143
This internal pseudo-class used to be to highlight nodes in the
inspector, but the inspector no longer sets it. Now the only thing that
sets it is devtools/server/actors/accessibility/audit/contrast.js to
remove the text color / shadow from the test.
We should probably find another way to implement that that doesn't
misuse this pseudo-class (and then presumably remove this pseudo-class),
but for now this code is dead.
Differential Revision: https://phabricator.services.mozilla.com/D113371
We had about 9 gaps / unused bits. I moved the devtools ones at the end
because I think we should be able to remove them (but separate bug).
Differential Revision: https://phabricator.services.mozilla.com/D113365
Our implementation was setting a custom user agent on the document
before reloading it, and then resetting it as soon as the document
was loaded.
In Chrome, once the webextension sets the user agent, it persists
across reload and navigations, and is reset only when the toolbox
is closed.
This patch is adding similar behaviour to our implementation.
We also set the currentUserAgent flag on the browsing context from
the parent process instead of content. This is re-using the
targetConfigurationCommand, which also handle for us resetting the
user agent when the toolbox closes.
The existing test is expanded so it includes a remote iframe to ensure
the feature is supported on Fission. It also check the value of the user
agent through navigator.userAgent, and not only through the request header.
Differential Revision: https://phabricator.services.mozilla.com/D112980
Our implementation was setting a custom user agent on the document
before reloading it, and then resetting it as soon as the document
was loaded.
In Chrome, once the webextension sets the user agent, it persists
across reload and navigations, and is reset only when the toolbox
is closed.
This patch is adding similar behaviour to our implementation.
We also set the currentUserAgent flag on the browsing context from
the parent process instead of content. This is re-using the
targetConfigurationCommand, which also handle for us resetting the
user agent when the toolbox closes.
The existing test is expanded so it includes a remote iframe to ensure
the feature is supported on Fission. It also check the value of the user
agent through navigator.userAgent, and not only through the request header.
Differential Revision: https://phabricator.services.mozilla.com/D112980
Was not able to get any confirmation about the impact of this change with try pushes.
However all the failures seem related to random waitFor calls in this test, without any regular pattern.
I suspect that our waitFor delay might be too short in some cases, increasing the interval will allow to verify this assumption.
Differential Revision: https://phabricator.services.mozilla.com/D113156
Alexandre Poirot
Boris Chiou
Andrey Bienkowski
Julian Descottes
surajeet310
Hubert Boma Manilla
Nicolas Chevobbe
Ashray
Alexandru Michis
Olli Pettay
Alexander Johansen
Noemi Erli
Tooru Fujisawa
Anthony Frehner
Edgar Chen
R. Martinho Fernandes
Michelle Goossens
Sandor Molnar
Emilio Cobos Alvarez
Butkovits Atila
Dorel Luca
Gijs Kruitbosch
Siddhant Gupta
Csoregi Natalia
Christoph Kerschbaumer
Nika Layzell
Alex Lopez
Daisuke Akatsuka
Gagah Pangeran Rosfatiputra
Mark Banner
Andreea Pavel
Manuel Carretero
Sebastian Zartner
Ben Hearsum
Brindusan Cristian
Florian Quèze
John Bieling
Matthew Gaudet
Belén Albeza
Valentin Gosu
Falguni Islam
imoraru
Vaidehi
Emma Malysz
Markus Stange