There are two leaks addressed in this commit:
1. The thread actor's `_debuggerSourcesSeen` set was never cleared. This set
exists only as a performance optimization to speed up `_addSource` in cases
where we've already added the source. Unfortunately, this set wasn't getting
cleared when we cleared debuggees out and it ended up keeping the
`Debugger.Source`, its referent, and transitively its referent's global alive. I
figured it was simpler to make it a `WeakSet` than to add it as a special case
in `ThreadActor.prototype._clearDebuggees` and manage the lifetimes by hand. I
think this fits well with its intended use as an ephemeral performance
optimization.
2. Due to a logic error, we were not clearing debuggees in the memory actor's
`Debugger` instance on navigations. This isn't really a "proper" leak, in that
if you forced a GC, the old debuggees would go away as `Debugger` holds them
weakly, however if there was no GC between navigations, then you could still see
the old windows (and everything they "retained") as roots in the snapshot. This
issue is straightforward to fix once identified: ensure that `_clearDebuggees`
is actually called on navigation.
Finally, this commit adds a test that we don't leak Window objects when devtools
are open and we keep refreshing a tab. When it fails, it prints out the leaking
window's retaining paths.
For simple rules like function spacing, we can auto-fix these across the code
base so they are followed in a consistent way.
To generate this patch, I ran:
./mach eslint devtools --no-ignore --fix
After this, I reverted any changes to third party files that we really do want
to ignore.
MozReview-Commit-ID: 6Q8BApkAW20
This commit creates the HeapSnapshotFileActor and moves the transferHeapSnapshot
method from MemoryActor to HeapSnapshotFileActor. This is necessary because
child processes in e10s are sandboxed and do not have access to the file system,
and because MemoryActor is in the sandboxed child process it cannot open the
file and send it over the RDP.
This complexity is hidden at the MemoryFront layer. Users of MemoryFront will
still simply call its saveHeapSnapshot method, and do not need to worry about
the inner workings of how heap snapshot files are transferred over the RDP. This
required adding a third parameter to MemoryFront's initialize method: the
listTabs response.
This commit creates the HeapSnapshotFileActor and moves the transferHeapSnapshot
method from MemoryActor to HeapSnapshotFileActor. This is necessary because
child processes in e10s are sandboxed and do not have access to the file system,
and because MemoryActor is in the sandboxed child process it cannot open the
file and send it over the RDP.
This complexity is hidden at the MemoryFront layer. Users of MemoryFront will
still simply call its saveHeapSnapshot method, and do not need to worry about
the inner workings of how heap snapshot files are transferred over the RDP. This
required adding a third parameter to MemoryFront's initialize method: the
listTabs response.
In a following patch, all DevTools moz.build files will use DevToolsModules to
install JS modules at a path that corresponds directly to their source tree
location. Here we rewrite all require and import calls to match the new
location that these files are installed to.
Move major DevTools files to new directories using the following steps:
hg mv browser/devtools devtools/client
hg mv toolkit/devtools/server devtools/server
hg mv toolkit/devtools devtools/shared
No other changes are made.
