Bug 875871 (dte10s)

[tracking] Developer Tools support for e10s

NEW
Unassigned

Status

6 years ago
4 months ago

People

(Reporter: briansmith, Unassigned)

Tracking

(Depends on: 21 bugs, Blocks: 3 bugs, {meta})

Firefox Tracking Flags

(Not tracked)

Details

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.
Summary: [tracking] Developer tools don't work with e10s → [tracking] Developer Tools support for e10s
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?
Depends on: 787975
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...
Alias: dte10s
Depends on: 937166
Depends on: 937167
Depends on: 937169
Depends on: 937172
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.
Depends on: 944106
Depends on: 989043
Depends on: 982319
tracking-e10s: --- → +
Depends on: 1011677
Depends on: 1030318
Depends on: 1030347
Depends on: 1030357

Updated

5 years ago
Depends on: 1007133
Depends on: 1034601
Depends on: 1035706
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.

Updated

5 years ago
Blocks: 984139
Depends on: 1039528
Depends on: 1040653
Depends on: 985597
Depends on: 1036409
Depends on: 1036421
Depends on: 1040670
Depends on: 1042253
Depends on: 1034213
Depends on: 1046174
Depends on: 1046478
Depends on: 1047248
Depends on: 1049103
Depends on: 1049888
Depends on: 1055333
Depends on: 1058033
Depends on: 1011663
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...
Flags: needinfo?(jmathies)
(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.
Flags: needinfo?(jmathies)
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.
Depends on: 1058875
Depends on: 1058879
(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.
Depends on: 1058898
Depends on: 1060093

Updated

4 years ago
Keywords: meta
Depends on: 1067576

Updated

4 years ago
Depends on: 975084
Depends on: 1074180
No longer depends on: 1073927

Updated

4 years ago
Depends on: 1076873
Depends on: 1079131

Updated

4 years ago
Depends on: 1029717

Updated

4 years ago
Depends on: 1080884
Depends on: 967201
Depends on: 1036406
No longer depends on: 1088291
No longer depends on: 1007133
Depends on: 1029545
Depends on: 1099392
Blocking e10s M6 milestone because most dte10s bugs ought to block e10s riding to Aurora.
tracking-e10s: + → m6+
Depends on: 1104908
Depends on: 1104323
Depends on: 1106692
Depends on: 1106702
No longer depends on: 937169
Depends on: 1107656
Depends on: 1107888
Depends on: 1107949
Depends on: 1068400
No longer depends on: 1070837
No longer depends on: 1074180
No longer depends on: 1098984
Depends on: 1118301

Updated

4 years ago
Depends on: 1120373
Depends on: 1121765

Updated

4 years ago
Depends on: 1122009
Depends on: 1079805

Updated

4 years ago
Depends on: 1127756
Depends on: 1128988
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.
tracking-e10s: m6+ → ?
I think Liz meant bug 1126014.
tracking-e10s: ? → -

Updated

4 years ago
Depends on: 1142292
No longer depends on: 1147044
No longer depends on: 1147043

Updated

4 years ago
Depends on: 1157820
Depends on: 1157816

Updated

4 years ago
Depends on: 1175850
Depends on: 1199876
Depends on: 1200612
Depends on: 1103839
Depends on: 1205482
Depends on: 1206032

Updated

3 years ago
Depends on: 1211107

Updated

3 years ago
Depends on: 1222409
Depends on: 1242221

Updated

3 years ago
Depends on: 1233780

Updated

3 years ago
Depends on: 1249934

Updated

3 years ago
Depends on: 1250058

Updated

3 years ago
Depends on: 1208293

Updated

3 years ago
Depends on: 1252201
Depends on: 1252283
Depends on: 1252345
Depends on: 1254613

Updated

3 years ago
Depends on: 1254821

Updated

3 years ago
Depends on: 1229864

Updated

3 years ago
Depends on: 1269102
Depends on: 1271872

Updated

3 years ago
Depends on: 1193296

Updated

3 years ago
Depends on: 1272350

Updated

3 years ago
Depends on: 1272115
No longer depends on: 1272350
Depends on: 1242986

Updated

7 months ago
Product: Firefox → DevTools
Blocks: 1387114
tracking-e10s: - → ---
You need to log in before you can comment on or make changes to this bug.