Implement assertions that dbg objects we are handling are owned by the thread actor's debugger
Categories
(DevTools :: Debugger, task, P3)
Tracking
(Not tracked)
People
(Reporter: loganfsmyth, Unassigned)
References
(Blocks 1 open bug)
Details
https://bugzilla.mozilla.org/show_bug.cgi?id=1536618 could easily have been caught before it landed if we could assert that a given object is owned by the thread actor's debugger up front when the source actor is created, instead of waiting for things to throw when we call findScripts
.
Updated•6 years ago
|
Updated•6 years ago
|
Updated•6 years ago
|
Comment 1•6 years ago
•
|
||
I guess at a more basic level, what is the rationale behind allowing multiple Debuggers to exist for a thread? The Debugger for the thread actor is easy to access, and having other debuggers hanging around which can't interoperate seems like something of a footgun.
Comment 2•6 years ago
|
||
I believe the rationale was that you might want to have multiple connections (i.e. the devtools panel and an editor connecting remotely). I believe that this was a feature that was added early on and has not been well tested/supported. I could be totally off the mark as well. CC Jim
Comment 3•5 years ago
|
||
The rationale for supporting multiple Debuggers at the SpiderMonkey level was that people might want to build multiple tools that interoperate. But the devtools server ideally would have only one Debugger per debuggee per connection, since we would like share Debugger.Foo objects freely between them.
Comment 4•5 years ago
|
||
Multiple Debugger support is thoroughly tested at the SpiderMonkey level. The server, I don't know.
Jason, I'm not sure what information you're looking for, but if this doesn't help, please clarify and flag me again.
Updated•4 years ago
|
Updated•2 years ago
|
Description
•