Adds a `--wait-for-jsdebugger` CLI option which will spin the event loop until
the debugger connects to allow debugging _some_ startup code paths, such as the
beginning of the `browser.js` file.
Startup code paths that run before the DevTools CLI handler will be missed for
now. This can be improved in the future if we move this to an earlier phase of
app startup.
MozReview-Commit-ID: J1A8lWLETGY
Ever since protocol.js was added as a way to create DevTools actors, we've had
lots of confusion about the correct way to implement actor destruction. If your
actor's _parent_ was the legacy kind, you had to use `disconnect`. If it was
protocol.js, you had to use `destroy`.
There is no reason for this madness, which makes reasoning about destruction
quite hard. Here we rename `disconnect` to `destroy` so there is only one name
for every destruction path.
MozReview-Commit-ID: C1Yw9NfUUR2
In ThreadActor._getAllEventListeners, we construct a list of handler functions
for each target in the event target chain of a given event target. If a handler
is an event handler object, we obtain the handler function from its handleEvent
property. Otherwise, the handler function is assumed to be the handler itself.
To detect whether a handler is an event handler object, we would check its class
name property. This approach is fragile for several reasons: if the handler is
a proxy, accessing its class name may cause the debuggee to run. Moreover,
since accessing a proxy's class name requires us to enter the compartment of the
proxy's handler, if the latter is a security wrapper, accessing its class name
will cause security warnings in debug mode.
Since a handler is either an event handler object or a function, it should be
safe to assume that a handler is an event handler object if and only if it is
not callable. Checking whether a proxy is callable cannot cause the debuggee to
run. Moreover, it does not require us to enter the compartment of the proxy's
handler, thus avoiding the security warnings we mentioned earlier.
Also contains folded version of the following patches that have to land at the same time with enabling the new implementation (or be backed out at the same time, if it comes to that):
Add Promise checks to test_xrayToJS.xul. r=bholley
Change Promise debugger hook tests to use Promise ctor instead of makeFakePromise. r=shu
Change DOM interface tests to assume Promise is an ES builtin, not a DOM one. r=bz
Remove some PromiseDebugging references. r=bz
Adapt promise rejections test to new xray-unwrapping error. r=bz
Fix expectations in browser_timelineMarkers tests. r=tromey
Also contains folded version of the following patches that have to land at the same time with enabling the new implementation (or be backed out at the same time, if it comes to that):
Add Promise checks to test_xrayToJS.xul. r=bholley
Change Promise debugger hook tests to use Promise ctor instead of makeFakePromise. r=shu
Change DOM interface tests to assume Promise is an ES builtin, not a DOM one. r=bz
Remove some PromiseDebugging references. r=bz
Adapt promise rejections test to new xray-unwrapping error. r=bz
Fix expectations in browser_timelineMarkers tests. r=tromey
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.
The special code path carved out in bug 1225160 dropped the `actor.isPending`
check which causes many, many attempts to set a breakpoint on every new source
notification, leading to a very slow debugging experience.
MozReview-Commit-ID: A3pnHzh5eeh
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
