Move the function taking care of closing the Browser Console to shared-head so
we can close it before closing the tabs opened during the test.
While attaching the worker, check that the Worker Debugger isn't closed, and
if it is, reject the promise. On the target list, catch rejection while attaching
and simply bail out so we don't call the rest of the code in onTargetAvailable.
Those guards are not enough to prevent any failure while attaching, so we're
wrapping calls to `attachAndInitThread`/`_onThreadInitialized` in try/catch
blocks to avoid test failures.
Differential Revision: https://phabricator.services.mozilla.com/D88766
At the moment, we don't have any guards in the targetList to _not_ execute the
creation/destruction listeners once the toolbox gets destroyed.
We only have a stopListening function on the targetList that is called when we
close the toolbox, but we can't rely only on that since it's also called when
doing a target switch (and working around that is very racy).
One solution would be to follow the common pattern we have everywhere by having
a destroy method that we would check before trying to call the listeners callback.
This might help with intermittent test failures.
Differential Revision: https://phabricator.services.mozilla.com/D88765
PDF print preview are using about:blank documents, which are ignored
by DevTools in order to save resources.
We avoid creating targets for these, very often, transcient documents.
I tried to find ways to distinguish typical temporary about:blank documents
from this print preview one.
Differential Revision: https://phabricator.services.mozilla.com/D88956
Some tests made some assumptions about the number of returned entries
by performance.getEntries, and these assumptions are not valid
anymore once we added new entries.
Depends on D66463
Differential Revision: https://phabricator.services.mozilla.com/D68645
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
Reduces explicit "elem.style.x = 'y' assignments by consolidating them
into associated Objects, and using `Object.assign` to make the style
modifications to the respective elements."
Depends on D86866
Differential Revision: https://phabricator.services.mozilla.com/D86867
I had to put it in toolbox.css as it wasn't working from EvaluationContextSelector.css.
I imagine that's because the context DOM element are actually in toolbox document rather than the console one.
Also, React must be re-creating all DOM elements anytime there is an update
as you can see the list scroll up, everytime there is an update.
We should probably have a look at that as well.
Differential Revision: https://phabricator.services.mozilla.com/D87620
Some tests made some assumptions about the number of returned entries
by performance.getEntries, and these assumptions are not valid
anymore once we added new entries.
Depends on D66463
Differential Revision: https://phabricator.services.mozilla.com/D68645
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
Nicolas Chevobbe
Hubert Boma Manilla
Alexandre Poirot
Daisuke Akatsuka
Andreea Pavel
Emilio Cobos Álvarez
manas
Julian Descottes
Anny Gakhokidze
Yury Delendik
Cosmin Sabou
Sean Feng
Mihai Alexandru Michis
Cody Welsh
Razvan Maries
Narcis Beleuzu