For devtools html we need to keep the dependencies on files using chrome only APIs to a minimum. Moving the code necessary to load the inspector in a standalone chrome tab will help reduce the number of this kind of dependencies in inspector.js. (FYI, in Bug 1291049, we will probably reuse a similar approach in order to create a fake toolbox when loading the inspector in a content tab.)

Comment on attachment 8809378 [details] Bug 1316577 - move chrome tab loading logic out of inspector.js; https://reviewboard.mozilla.org/r/91992/#review91940 What is chrome in this code? I see mostly the BrowserLoader Cu.import. I imagine you will have a BrowserLoader anyway? How are you going to instanciate one in content? I landed this code in order to ensure using the same codepath, so I'm quite against having it being distinct!

As discussed on IRC, the chrome usage mostly comes from the additional dependencies pulled here : - devtools/client/framework/attach-thread.js - devtools/client/framework/target-from-url.js I'm ok with trying to take a different approach here and instead of moving the code just cleaning up the chrome dependencies related to it. Looking at the files, the Cu/Ci/Cc imports don't actually seem used. The DebuggerServer is being used in target-from-url though so we'll need to extract this one. I know the other topic here is whether we should reuse what was done by debugger.html or what you did. It was faster for us to reuse what debugger.html had but we definitely want to merge the two approaches in the long run. I'll discuss it in today's daily (feel free to join) and will try to clarify the plan here.

As discussed in standup, we won't move the logic out of inspector.js ; instead I will just use mocks for the dependencies that can't be loaded in content when bundling.