My understanding is that the goal is for all developer tools to live in the chrome process. This means that the developer tools would need to use IPC to communicate with the content processes. My understanding from talking with imelven is that the devtools team is already working on migrating all the developer tools to use the remote debugger protocol, which is a big part of doing this. I am filing this bug just so that the people working on sandboxing will have something to reference. It would be great if the devtools team could dupe this to some existing bug that I couldn't find, and/or fill in the dependencies based on their understanding of what things would need to be done.

dcamp said he would see if someone on the DevTools team has time to work on this bug for Q4 2014. He estimates the work will take about one week.

What work is left to do? Pretty sure we're 100% remote debug protocol now. If there's anything left to do, some details here would be nice to have.

(In reply to Rob Campbell [:rc] (:robcee) from comment #2) > What work is left to do? Pretty sure we're 100% remote debug protocol now. > If there's anything left to do, some details here would be nice to have. $ grep -R target.tab | wc -l is a decent place to start looking, It's mostly tests that still use that.

The remote inspector is not 100% ready: - highlighter is not remotable (the remotable highlighter is way too basic) - tag editing is not possible - font inspector & image preview rely on the fact that the server and the client resolve URLs the same way Probably more stuff.

The $0 helper in web console still depends on direct access to the page (bug 787975). Also, I think the paint flashing, tilt and responsive design mode tools do not use the remote protocol yet. Do we have bugs on file for them?

As I understand things, the main work here is hooking up the debugger to use the message manager transport similar to how the webapps stuff works now.

Yeah, just need to swap the transport. There are a few small holes (I'll add to paul's list: completion list in markup view search) but just hooking up the message manager transport should be a pretty solid proof of concept.

(In reply to Panos Astithas [:past] from comment #5) > The $0 helper in web console still depends on direct access to the page (bug > 787975). Also, I think the paint flashing, tilt and responsive design mode > tools do not use the remote protocol yet. Do we have bugs on file for them? Not afaik. We should file bugs for those and the message manager PoC. Filing them now...

Added 4 bugs. I have not created bugs for these yet: (In reply to Paul Rouget [:paul] from comment #4) > The remote inspector is not 100% ready: > - highlighter is not remotable (the remotable highlighter is way too basic) > - tag editing is not possible > - font inspector & image preview rely on the fact that the server and the > client resolve URLs the same way > > Probably more stuff.

Thanks for filing these Rob. It's probably clear already, but I just want to point out that bug 937172 is the highest priority for us right now since nothing else will work in e10s without it.

I don't know anything about the e10s roadmap. How soon should we start working on these bugs?

We'd like to have bug 937172 pretty soon so that people can use the debugger. Mostly we'd like to be able to debug chrome code in the child process. I'm not sure if bug 937172 will cover that. But debugging content code would be nice too. Our goal is for add-on developers to be able to debug their add-ons in e10s. The other bugs are probably of lesser importance, but they would be nice.

Bill, you can currently debug chrome code in e10s using the Browser Debugger (set devtools.chrome.enabled and remote.enabled to true in about:config or via the preferences panel on the toolbox). Doing a little preliminary testing this week, I was able to get that to work pretty well, just don't try descending into any content code. There may be issues. I'm planning on taking a look at bug 937172 over the next couple of weeks and can hopefully make some headway there. In terms of planning, some of these other bugs are going to depend on this, so there'll be downstream work to do.

> Bill, you can currently debug chrome code in e10s using the Browser Debugger (set > devtools.chrome.enabled and remote.enabled to true in about:config or via the preferences > panel on the toolbox). I think the main thing we need is the ability to debug chrome code running in frame scripts in the child process. That's why we need the message manager stuff.

That's different from what I thought (and is probably going to be different again from pure content debugging). We might need a 3rd state to debug remote frame scripts from a "local" debugger. "Chrome debugging" in e10s will likely have to change to support debugging frame scripts as well. Let's move further discussion about debugging into bug 937172 and keep this for organizing dependent bugs.

Note we have e10s forced on for Holly - https://tbpl.mozilla.org/?tree=Holly Feel free to push stuff here to test dev tools work. We can reset holly easily if things get messed up. I'll be working on win tests this week as well.

Jimm, now that we have a bunch of tests that run correctly on e10s, that would be really handy to be able to run them on Try, or even better, run them on fx-team! I get the sense that we should now have a pretty decent blacklist so that we should be able to get green runs. Ideally we would still run non-e10s tests, so that we would run mochitests twice. Once in non-e10s and another time with e10s turned on. Is there any plan to do such thing? I imagine it won't benefit only to devtools...

(In reply to Alexandre Poirot [:ochameau] from comment #17) > Jimm, now that we have a bunch of tests that run correctly on e10s, that > would be really handy to be able to run them on Try, or even better, run > them on fx-team! > I get the sense that we should now have a pretty decent blacklist so that we > should be able to get green runs. > Ideally we would still run non-e10s tests, so that we would run mochitests > twice. Once in non-e10s and another time with e10s turned on. > Is there any plan to do such thing? I imagine it won't benefit only to > devtools... Absolutely, although there is work to do here (tracking bug 984139). For example - https://tbpl.mozilla.org/?tree=Holly that's every test suite we have running with e10s turned on. Currently test coverage isn't blocking our milestone 2 (oct 14th) but will block our milestone 3. We are however trying to get tests going sooner if we can. Key areas to work on are: whitelisted mochitest-plain tests on all 3 platforms running on trunk repos whitelisted mochitest-browser tests on all 3 platforms running on trunk repos audit whitelists which have become out of date, and block M3 on any tests that are blacklisted that should be enabled. As far as running both e10s and non-e10s tests on checkins, that's a decision that has not been made yet. It would be nice if we could run just e10s tests once e10s is enabled by default, but there are situations where firefox will not run with it, for example when accessibility clients connect. So exactly what we run and when is still to be determined.

I think the best strategy is to get the devtools tests green on Holly (by making them work in e10s or by disabling them in e10s) and then we can work on enabling them for other trees.

(In reply to Bill McCloskey (:billm) from comment #19) > I think the best strategy is to get the devtools tests green on Holly (by > making them work in e10s or by disabling them in e10s) and then we can work > on enabling them for other trees. Most of the devtools components already have bugs to fix them, but getting the tests green just by skipping them seems like a good first step so we don't keep adding new ones that break. Filed Bug 1058875 to do this.

Blocking e10s M6 milestone because most dte10s bugs ought to block e10s riding to Aurora.

Liz suggested that we may want to move this up to m5 to get more time on nightly before aurora uplift. Re-noming to discuss in triage.

I think Liz meant bug 1126014.