Closed Bug 997119 Opened 6 years ago Closed 1 year ago
Actor from Browsing Context Target Actor
47 bytes, text/x-phabricator-request
|Details | Review|
bug 977043 followup. Ideally, DebuggerServer should only be about implementing the server and doing the network and actor machinery. But it contains some code specific to debugger actor, especially some code specific to the ThreadActor. So that if you want a very good comprehension of ThreadActor you have to read the ThreadActor class, but also a bunch of DebuggerServer methods. Bug 977043 introduced new will-navigate/navigate events that should help moving thread actor code back to the ThreadActor class.
I believe when you write DebuggerServer above you are referring to the TabActor in webbrowser.js (DebuggerServer is in main.js).
Component: Developer Tools → Developer Tools: Debugger
OS: Windows 7 → All
Priority: -- → P3
Hardware: x86_64 → All
Summary: Uncouple ThreadActor from DebuggerServer → Uncouple ThreadActor from TabActor
Version: unspecified → Trunk
Hi Alex. Could you clarify exactly how you would like to decouple ThreadActor from TabActor?
Move (if possible) all code related to ThreadActor out of main.js (most likely script.js?) Code like this can be easily moved to script.js: http://mxr.mozilla.org/mozilla-central/source/toolkit/devtools/server/actors/webbrowser.js#1293 TabActor should be a generic abstraction and shouldn't contain anything of the child actors it manages. For historical reason, many code related to the debugger have been entangled within core code for the debugger server/protocol. Now we have some usage of the DebuggerServer where we don't care about the debugger (script.js, js code debugging, breakpoint, ...). And we should be able to load a barebone DebuggerServer instance without loading anything regarding the debugger. This is related to my work to strip down memory usage of the server.
(In reply to Alexandre Poirot [:ochameau] from comment #3) > Move (if possible) all code related to ThreadActor out of main.js (most > likely script.js?) > > Code like this can be easily moved to script.js: > http://mxr.mozilla.org/mozilla-central/source/toolkit/devtools/server/actors/ > webbrowser.js#1293 > > TabActor should be a generic abstraction and shouldn't contain anything of > the child actors it manages. > For historical reason, many code related to the debugger have been entangled > within core code for the debugger server/protocol. Now we have some usage of > the DebuggerServer where we don't care about the debugger (script.js, js > code debugging, breakpoint, ...). And we should be able to load a barebone > DebuggerServer instance without loading anything regarding the debugger. > This is related to my work to strip down memory usage of the server. I agree. Ideally TabActor should be completely unaware of the internals of ThreadActor. Are you aware that we've recently added some dependencies for ThreadActor on TabActor (so in the other direction?) I'm talking about stuff like makeDebugger in webbrowser.js. Are you ok with those dependencies? I assume you are only talking about dependencies of TabActor on ThreadActor.
Yes deps on the other direction are fine.
Summary: Uncouple ThreadActor from TabActor → Decouple ThreadActor from TabActor
Pushed by firstname.lastname@example.org: https://hg.mozilla.org/integration/autoland/rev/f285ee7fedd7 Move ThreadActor logic from BrowsingContext. r=yulia
Assignee: nobody → jarilvalenciano
Fission Milestone: --- → M4
You need to log in before you can comment on or make changes to this bug.