Mozlando Devtools Servo

Devtools support in Servo

How do we test our impl?

• jdm: How do we know we work with nightly?
• jryans: There are none in Firefox. Only tests are desktop firefox connecting to itself.
• jdm: LucidDreaming from ted?
• jryans: Not here yet. Alex is converting test suites to it. Have a harness running in try.
• brian: Useful for back-compat against old versions of Firefox.
• jryans: Generally, should be back-compat (desktop client can connect to much older versions of the protocol). we do that for FFOS already. But there are no test.
• jdm: Changes in profiling tools are hard...
• brian: Actors in Rust. Do you need to update them a lot?
• jdm: Every time I create a project for students, it turns out our DevTools support is broken.

How do we implement the protocol?

• jryans: fitzgen is leaning towards having servo use the gecko server code and just implement engine API. Challenge is no privileged JS in Servo right now...
• larsberg: don't we need it for browser.html?
• jdm: No, more that we can't inject JS code into the same running context as unpriviledge context w/o horrible security problems.
• jryans: That's probably a good long-term strategy.
• brian: Gotta remove XPCOM & move to WebIDL.
• jryans: Which actors today?
• jdm: inspector-related things. WebConsole. Network requests. A timeline actor that records DOM events.
• brian: Debugger?
• jdm: No. Overwhelming.
• jryans: You really want to just use our files. You have the same JS engine.
• brian: Is there a test we could do to get hello, world actors in?
• jdm: If you had a barrier, we could create a separate JSRuntime that runs the priviledge JS code & impls of the barrier do the engine stuff as calls across runtimes. Then we can't leak. I'd be willing to help with this. The protocol and interface with it makes so much more sense in JS code than in Rust. If you can create the abstraction, i'd help.
• jryans: Inventory the APIs first, maybe?
• brian: All XPCOM / WebIDL things?
• jdm: Anything directly interacting with web content in the server code?
• brian: Inspector to set attributes.
• jdm: That, for Servo, we'd need an abstraction there.
• brian: May be web exposed APIs you don't implement in Servo yet.
• jdm: Promises?
• jryans: EVERYWHERE!
• jdm: Could use a promises library for now...
• jryans: If you think we should just use the JS code, that would make sense.
• brian: First step is to create a hello, world actor and see what's not working. There will be a lot in the Inspector Actor, and having the simple one up first would help.
• jdm: Particular actor with a minimum amount of interaction with direct web content or special chrome APIs?
• jryans: We can create an empty actor for you. The echo actor that replies, for example, to see if the infra can even load at all. No DOM APIs at all.
• jdm: That seems like very little investment to get started.
• jryans: Then we can just go actor-by-actor. Inspector, though, has many APIs.
• brian: If you have stuff in the console, then maybe we could do the Services Observer(?) logging to the console. Can ignore cmdline helper, etc.
• jryans: Console is mainly client-side.
• jdm: Also has evaluate this JS...
• brian: And network monitoring...
• jryans: Need the SM debugger APIs accessible, too.
• jdm: Yes. Would you accept patches to create an "API module" and replace those direct usages of XPCOM stuff?
• jryans: DevTools should chat as a team about how we want it structured, but seems reasonable.
• jdm: Much usage of components.utils.import and such?
• jryans: Not a lot of jsm, but there is some. Also use other components things, like components.stack to get stacktraces. And anything that uses XPCOM. Most things are just common JS modules. Have our own loader to implement require.
• jryans: We have a custom loader that does the require stuff by creating sandboxes. What are you gonna do there?
• jdm: Maybe replicate them in Servo. They are safe places for JS to play in.
• jryans: It's a safe global (no window!) that you can just do whatever you want in that environment.
• jdm: There's an implemention we could presumably port to Rust.
• jryans: not sure about tests...
• brian: If we can get devtools in a tab, we should be able to get some basic tests up.
• ms2ger: Have to get an independent implementation of one of the sides...
• jdm: jgraham was talking about creating a separate devtools client in python that we could script and test. If we were using the code from m-c, that's another area we'd need to import/vendor.
• jryans: We're considering moving DevTools to a separate repo, which would make it much easier... but absolutely no promises. I'm a little afraid of adding a bunch of Servo code to m-c that we can't test. Or when we add more code that will not work with Servo.
• jdm: Could duplicate the Servo design, which is instead of having DevTools in the same JSRuntime but priviledges, isolate it in a new JSRuntime, don't have the XPCOM globals at all, and have to remote it across.
• larsberg: Would that be ergonomic, or would people hate it?
• brian: How do you handle setAttribute?
• jdm: Gotta shim it, proxy across the other runtime, find the other node, and then poke it over there...
• jryans: Feels kinda tricky. Gotta replicate every DOM method.
• manish: GC problems with grips everywhere?
• jdm: Yes.
• brian: Why would you not be able to touch the DOM nodes in Servo?
• jdm: Our current design is that we can't have devtools server code running in the same thread for security. We have no concept of priviledges vs. unpriviledged JS code.
• jryans: No plans to add priviledge JS?
• ms2ger/jdm: Trying to avoid it if at all possible.
• jdm: Other option is to have COWs for all DevTools interactions. In servo, when we get a request to find an attribute, we send a message to script is send it.
• jack: Couldn't you also just mirror the DOM to the DevTools JSRuntime? You'd get great read access, but any write would have to go over via MutationObservers or similar.
• brian: Async writes?
• jdm: Sync from the perspective of DevTools.
• jryans: Would reduce the changes, for sure.
• brian: Just for DOM, or for debugger server, too?
• jdm: Also round-trips to main thread.
• jdm: Where are you running Devtools in e10s? Content process?
• jryans: Yes. Initial connection is received by the main chrome process. Then, uses e10s messages to start up chrome code in the child process to start its own server. All the TCP messages come in the main process, then across e10s...
• jack: So we could have DevTools in the same process.
• jdm: No reason it couldn't be in the same thread...
• jack: Little worried if we end up making profiling slow. Seems to make the profiler less than useful. If in the same process, no big deal to copy the DOM.
• jdm: With my proposed changes, we'd have to be on a separate thread, since you can't run two pieces of JS at the same time.
• ajeffrey: If we hand a copy of the DOM over to layout for readonly access anyway, don't we already have a mechanism for that?
• jack: It's just once and done.
• jdm: Mechanism is "stop script until layout is finished."
• jack: Profiling tools should not block script!
• ajeffrey: Separate convo, but we don't want to do that for layout anyway.

How do we support the IDE (hopefully html...)?

• manish: How much of the toolkit do you use?
• jryans: Not much. For the demo this week, we copied everything out of the repo, removed the XUL, and removed the privildeged JS. Was an experiment, and is something the team wants to do, but still need to figure out how to do that in production. Tried to run the UI in Servo. I got a white rectangle... probably lack of flexbox. On the UI side, we need to figure out which CSS features are missing.
• brian: Also, DOM APIs. There's a path forward there - something there.
• jryans: We do have this experiment. If we wanted to look at the UI, could look there for what needs to be done to run in Servo.
• jdm: Where is that?
• brian: Current experimental UI: https://github.com/joewalker/devtools.html, which either doesn't open or crashes when trying to open in Servo: https://github.com/joewalker/devtools.html/issues/4

How to get timeline view working in Servo

• jack: ms2ger implemented it, but it suddenly stopped working. Want to get some help with fixing it, because there are no errors - it just doesn't work.
• jryans: jordan or victor are the right people. They are here at Mozlando.

Version of language

• larsberg: We need let for Devtools. Can we land a new language level?
• jryans: We really need new-let, too.
• jack: Already working on an SM update.
• jdm: Maybe an option for the language version? Changing the default is silly.
• ms2ger: Exposing an arg is also silly.
• larsberg: What does Firefox do?
• jdm: You can set it, but I don't want to make it global.
• jack: You have to use args to the script tag. This is the very first thing that happened with Shumway, Browser.html, etc.
• jdm: I would like to keep the same default JS version. For DevTools, we would know it was DevTools code and set the compartment version.
• tetsuharu: SM is implementing a new ES6 features and ship them incrementally, so I think we don't have to consider JavaScript's version if we upgrade SM continuously. Then, what we need to think is what SM's feature flag is enabled in Servo.
  • (^is talking with jdm and larsberg in offiline)

WebAssembly

• ajeffrey: What's the story?

• brian: Meeting this morning...

• jryans: The JS team will make it work so the DevTools aren't affected?

• ajeffrey: Debugger will give you step expressions?

• jdm: SourceMaps will take you back to the C++.

• pcwalton: There's a JS standard (SourceMaps) that you can use. I think Firefox and Chrome have support for it.

• jryans: Yes, we do. Chrome supports it in the console, but we don't yet.

• ajeffrey: Repl will still be JS?

• jryans: Yes.

• fitzgen: yes, odin monkey folks are going to implement the existing Debugger API for wasm, should require very minimal changes on devtools protocol server side

• fitzgen: FYI source maps are totally insufficient for C++, way too big (gigabytes), need something new, not part of v1 wasm debugging. Will initially be debugging the (wip/semi-?)standardized text representation of wasm

Next steps

• separate JSRuntime and bare-bones UI stuff (servo - jdm)
• file issues on stuff that is broken trying to load the HTML UI (devtools - brian on crash, jryans on no output) ** Crash is fixed after pulling and rebuilding servo