It allows
* toggling Source Map support entirely
* open the source map URL (when a bundle file is currently selected)
* open the mapped source (original or bundle)
* toggle the "open original source by default" setting
* show source map status (source map error, is it original or bundle file, is this a regular source?)
Differential Revision: https://phabricator.services.mozilla.com/D187577
This helps accumulate RDP packets related to resources being available/updated/destroyed
and emit less and larger RDP packets instead or more and smaller.
This appears to reduce the overhead of DevTools transport and JSWindowActor layers.
The issue in browser_markup_events_toggle.js is interesting.
It highlights that a resource notified before a call to WatcherActor.watchResources,
may be emitted during the call to watchResources.
This makes ignoreExistingResources flag a bit brittle as that resource should be
considered as an existing/past one.
We should probably flush past resource and probably introduce a more explicit
way of handling "existing" resources on the server side.
The fix in document-events.js relates to failures in browser_net_offline_mode.js.
This test was passing thanks to late dom-complete event emitted on the previous WindowGlobal.
Surprisingly, when reloading the page in offline mode, the previous, already existing WindowGlobal
triggered the WebProgressListener and we were emitting dom-complete event.
Because of throttling, this resource is no longer transfered to the client as the related target
actor is already destroyed on reload.
But at the end, the issue was the missing dom-interactive and dom-complete events for the error page.
Regarding browser_net_ws-sse-persist-columns.js, it looks like this test was properly waiting
for the WebSocket table to update. We were really lucky it was working without frequent intermittent!
Similarly to the client side, DOCUMENT_EVENT's will-navigate is special
and has to be emitted synchronously in order to prevent clearing things out of order.
This is also true for NETWORK_EVENT_STACKTRACE which is expected to be received
*before* related NETWORK_EVENT. NETWORK_EVENT_STACKTRACE is fired from the content
process while NETWORK_EVENT is fired from the parent process.
For now, it is easier to synchronously emit those resources rather than trying
to do cross process coordination.
We may revisit this choice once we start doing throttling from the parent process
and may be once D143409 lands.
About browser_resources_clear_resources.js, it is surprising it wasn't already failing.
Differential Revision: https://phabricator.services.mozilla.com/D197772
We set up a Map keyed by resourceId, whose value is an AbortController that
controls the MediaQueryList change event listeners that we set on a given stylesheet.
We also take care of aborting the existing abort controller before setting new
event listeners on a stylesheet, to avoid leaks.
Differential Revision: https://phabricator.services.mozilla.com/D200180
Since for relative elements we imagine a hypothetical original position,
zoom needs to be considered when doing the calculations.
Differential Revision: https://phabricator.services.mozilla.com/D200287
We should probably expose new RDP methods to prevent relying on console evaluations for this.
We would still have some potential issues if the evaluated method is about a JS symbol
whose name is the console command.
Differential Revision: https://phabricator.services.mozilla.com/D200167
Let's avoid tracing content process targets for now as this would require some more work (bug 1874204).
Also ignore web extension documents as they are all running in the same process dedicated to WebExt.
(JavaScriptTracer class only support being instantiated once per thread and all these documents run on the same)
(bug 1874219)
Differential Revision: https://phabricator.services.mozilla.com/D200169
Adding a new HeaderVariety called eVarietyRequestEnforceDefault. It
allows setting request header value as default even even if the header
exists.
We need this to setting default header value without changing the order
of the header.
Differential Revision: https://phabricator.services.mozilla.com/D199991
Because the JavaScript tracer is currently running in each process/thread/target actor independently,
it is more complex to make it record across navigations as it may be spawn in a distinct process.
While it is fine for stdout and webconsole outputs (we could just spawn many concurrent tracers in each process),
this is more complex for the experimental "profiler" output.
For now, the profiler output automatically stops on target destruction and will open the profiler result.
By having an option to start recording on next page load, it prevents starting the tracer and prevent logging traces
for the current WindowGlobal. It should help focus on the new document.
For the profiler output, it prevents having the profiler to show up for the previous WindowGlobal.
Sideby tweak:
* stop passing logMethod and consider, like other option to be coming from the preferences.
* fix confusing state when debugging a page running in the same process.
Differential Revision: https://phabricator.services.mozilla.com/D196874
This simplifies toggling the Tracer on all active targets.
But this will be especially useful in the next changeset.
This allows to have two distinct level of enabling:
* the target configuration
* the actual start of tracing done by the tracer (on user interaction or next page load)
Doing this allows to distinguish tracer simple enabling,
when "trace on next user interaction" is enabled,
where we can display a badge on the tracer icon to significate it isn't tracing just yet.
And actual start of the tracer, when the first user interaction happens,
where we can remove the badge.
Differential Revision: https://phabricator.services.mozilla.com/D198961
Ensure updating the tracing state from the TracerCommand,
so that its internal state is correct whenever we start tracing
via the console or debugger.
Differential Revision: https://phabricator.services.mozilla.com/D196961