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
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
A preview for fonts is added to the Response view of the Netmonitor. This view displays the name and MIME type of the font and generates a preview for it.
If no preview can be created, a hint is shown to the user. This is the case when the font isn't used within the page when generating the preview. For example, this is the case when loading the font via the Font Loading API.
Depends on D110167
Differential Revision: https://phabricator.services.mozilla.com/D110169
Before bug 1706806, this test was passing because it wasn't testing what it
intended to test - it passes even if "Inspect" isn't clicked.
After the patch in bug 1706806, it's now doing what it wanted to do all along,
but sometimes it times out waiting for the context menu to open.
Bug 1706833 has been filed to figure out why.
Differential Revision: https://phabricator.services.mozilla.com/D113057
The openContextMenu() helper does the same thing this test does now: dispatches a MouseEvent to a specified node. Using it allows us to clean up the test considerably.
Differential Revision: https://phabricator.services.mozilla.com/D112835
Without this, devtools/client/debugger/test/mochitest/browser_dbg-watchpoints.js
was timing out for me locally with non-native menus.
Differential Revision: https://phabricator.services.mozilla.com/D112839
Julian Descottes
Nicolas Chevobbe
Falguni Islam
Csoregi Natalia
imoraru
Emilio Cobos Álvarez
Vaidehi
Emma Malysz
Butkovits Atila
Belén Albeza
Markus Stange
Alexandru Michis
Sebastian Zartner
Alex Lopez
Harry Twyford