Network override needs this already for <link>, the test was using
@import to bypass the usual caching.
browser_resources_css_messages.js needs to clear the cache as well now
that reloading might not reparse the stylesheet.
Differential Revision: https://phabricator.services.mozilla.com/D243770
After splitting the test in c12995f9bf8e all skip-ifs were removed from the main test.
Within one week, the main test has still failed relatively often on linux, restoring this skip-if.
Differential Revision: https://phabricator.services.mozilla.com/D241298
This is not the main intermittent failure, but the addon targets are sometimes
destroyed in the middle of the test, making it quite flaky.
Differential Revision: https://phabricator.services.mozilla.com/D240874
The "target/" rule matches all folders named target regardless of the depth.
Removing redundant entries and adding an exclusion for the devtools folder.
Differential Revision: https://phabricator.services.mozilla.com/D240728
The Browser Toolbox currently debug all scripts in a given content process
via the related Content Process Target actor.
Because of this, we have to ignore the WindowGlobal Target actors
for anything related to Sources, breakpoints,...
But VS.Code would benefit from reusing the Browser Toolbox codepath,
while never using the Content Process targets (which have no real meaning for the user in VS.code),
and instead debug the sources via the WindowGlobal Target actors.
Introduce a new configuration to be able to distinguish the two codepaths.
Differential Revision: https://phabricator.services.mozilla.com/D235681
The TargetCommand will avoid listening for CONTENT_SCRIPT targets for the browser toolbox,
so we can safely enable them in the server.
This will allow VsCode to listen for CONTENT_SCRIPT, while not spawning the CONTENT_PROCESS ones.
Differential Revision: https://phabricator.services.mozilla.com/D235680
Create a dummy rule with the content of the rule being modified so we can
check if it has a nested rule. In such case, we can then get the location
of the nested rule so we can insert the added text in the correct position.
A few unit test cases are added to make sure the RuleRewriter does handle
nested rules properly.
Differential Revision: https://phabricator.services.mozilla.com/D237734
I stumbled upon this bug while realizing that some of the math I'm doing
for PiP windows doesn't work at all on Linux (bug 1934760), because
screenX != mozInnerScreenX, even though outerWidth == innerWidth.
I've tested this on X11 and Wayland (plasma and Gnome) with CSD and SSD,
and in general, this is the same thing Windows does, so should be fine.
The basic idea is:
* Keep mBounds being frame manager bounds (so, outer* and screen*),
relative to mShell.
* Keep mClientMargin to translate from mBounds to client bounds.
This is both simpler and makes the math consistent.
Differential Revision: https://phabricator.services.mozilla.com/D230981
The source of trouble here is the Web Extension Fallback Document,
which is loaded via the system principal and used by DevTools
as the top level target.
Because of it being system principal, we use the special "devtools loader" for ESM.
This is what cause the exception about the "global" option.
Using global attribute set to contextual fixes this exception.
Because of it being the top level target, we are trying to send the request
from its document. But as it is a system principal, it is ignored by the Network Observer.
So that the resent request is sent, but isn't shown.
Using the currently selected target in Network Command helps circumvent that
by sending the request with a real extension document and the request
is then shown in the network monitor.
But this change also impact web page and browser debugging.
Differential Revision: https://phabricator.services.mozilla.com/D231602
This patch affects both the console context selector and debugger source tree / thread panels.
The URL should still be displayed in tooltips.
Differential Revision: https://phabricator.services.mozilla.com/D231026
DevTools currently broadcast its data to all processes (in order to reach all service workers, which may run in arbitrary processes).
We expect for the queries to be processed in the content process before replying back to the client/frontend in the related RDP request.
But, in some case, some content process may be stuck on a CC or slow page script.
When this happens, DevTools would be blank on opening or very slow to operate.
Let's try to avoid waiting for any query send to process which timed out on any past query.
Differential Revision: https://phabricator.services.mozilla.com/D229960
This helps ensure that the object actors returned by the console actor evaluation RDP request
are the same for the same JS values being processed and notified via the tracer ressources.
This allows identifying same objects when doing a search per value.
Differential Revision: https://phabricator.services.mozilla.com/D225237
