Once upon a time (bug 862341), we decided to enable network listening by
default in DevTools.
In a general sense, that's fine. When you open a toolbox, we listen to that
tab and stop listening when the toolbox closes.
GCLI / Developer Toolbar is quite different, though. It connects to the whole
browser. This meant that enabling GCLI would start listening to network
activity in *every* tab (even though it doesn't have any way to even use that
data). This of course will slow down performance with all the extra tracking
and eat up memory with the tracked request data.
In this change, we move the step to enable network listening into the toolbox,
which seems more like what we intended anyway.
MozReview-Commit-ID: 2UYoQtWCAE1
Adds a new `getRoot` request to the root actor which lists the global actors
only (leaving out the tabs). This is a much better fit for callers who want to
access some global actor only, since it avoids visiting every tab, which could
be a very expensive operation.
MozReview-Commit-ID: 1lIAuaV7zoF
The toolbox can get a preference front for toggling various prefs on the server.
The toolbox destruction code path was written in such a way that it would
request a preference front during toolbox destroy, only to immediately destroy
the front right after. This is extra painful, since we send a `listTabs`
request and other fun things as part of this.
With this change, we cache the preference front when it is first used, and we
only attempt to destroy it if it was previously used.
MozReview-Commit-ID: 9repQSXjdRj
It appears the new debugger UI is working for the Browser Toolbox case, so let's
turn it on to match our approach with web content.
MozReview-Commit-ID: 1HhSKwZMH2f
This makes the new client-side mapping service available from the toolbox. Note
that it's not actually _used_ from here yet, as that will happen in separately.
MozReview-Commit-ID: 5Bq774CANfC
The existing `SourceMapService` uses server-side source maps, which we are
replacing with client-side source maps. It will be removed later in bug
1349354, but for now mark it as deprecated so we don't use it with any other
tools.
MozReview-Commit-ID: ABmWGC5asZd
This was a regression given by bug 1320149; in order to keep the performance
gain I created a lightweight object (`CommandState`) that is required from both
gcli's command and toolbox so that the last one doesn't need to be strong
coupled with the first one.
MozReview-Commit-ID: 3NcTt6i4ezx
`toolbox.win.top` is a bit suspect when we support undocked toolboxes, as this
doesn't allow you to reach a browser window for the toolbox. Here we take a
different approach that should work for all docking types.
MozReview-Commit-ID: 5mlsp4OyZrc
Originally, the profile was placed in `ProfLD` instead of `ProfD`. On some
systems, such as macOS, `ProfLD` is in the user's Caches directory, which is not
an appropriate place to store supposedly persistent profile data.
MozReview-Commit-ID: IWudqEg3kbI
This patch is generated by the following sed script:
find . ! -wholename '*/.hg*' -type f \( -iname '*.html' -o -iname '*.xhtml' -o -iname '*.xul' -o -iname '*.js' \) -exec sed -i -e 's/\(\(text\|application\)\/javascript\);version=1.[0-9]/\1/g' {} \;
MozReview-Commit-ID: AzhtdwJwVNg
By using the toolbox's threadClient reference, we avoid depending on specific
globals from the debugger panel itself, which can differ between old vs. new
debugger and generally aren't expected meant to be an exposed API.
MozReview-Commit-ID: FCvMDHpe1m1
Add options (available in Nightly/Local builds only) to switch between the old
and new frontends for console and debugger.
MozReview-Commit-ID: 413xt7h9aoP
