Meeting Devtools Servo 2

Protocol plans

• jim: concern is that if Servo implements the Gecko protocol, it will be the only other client and might get in the way of implementation work
• jack: Planning to use Gecko’s until our June release. Would like to demo debugging servo using firefox. Need console and performance, inspector doesn’t really matter but may be close to working. and page load performance. After June, could decide between the Gecko and Chrome protocols.

Valence

• Nox: Wasn’t sure if it would work for us?
• jim: Valence is not a 100% solution for full support of either protocol. But, it does allow testing pretty nicely. But, even if you go with Chrome protocol in Servo, you can still use Firefox dev tools to debug Servo.

Devtools.html

• jim: Change to non-XUL, usable frontend for Servo is possible.
• Ryan: We tried standing this up in Servo; main problem is missing platform/DOM APIs in Servo right now.
• Jack: Certainly, we could try to use the standalone devtools.html to make a standalone Servo-based application there. We could talk about that after June.
• Brian: I think we got it to mostly render during the Orlando thing.
• Jim: It seems like your browser.html support should be sufficient - non-content HTML accompanying content HTML. That’s exactly what we need for devtools.html.
• Nox: Does this still all communicate via the protocol, or priviledged APIs?
• Ryan: ALWAYS the protocol.
• James: currently not via WebSockets, but that’s all coming.

Privileged JS / Debugging

• Fitzgen: right now, debugger API is only a JS interface. We could make C bindings for the same interface, but via C. That’s easy to wrap in Rust.
• Jdm: C++ APIs are also things we can use now. Binding generation is much better now.
• Fitzgen: traits templates?
• Nox: NO
• Fitzgen: mainly the memory stuff has a lot of template magic / traits stuff, which would be harder. The debugger API has been fuzzed and used for years, so we should try to create the C bindings and not start again from scratch
• Jim: debugger is strictly intra-thread. Same stack as the debuggee. Fuzzed & optimized (only slows down asm.js - not normal JS code). Everything’s implemented in SM; doesn’t rely on XPCOM or any of the other outside stuff. If we wanted a JS server, just need access to the Debugger global. No reaching through memory / reading raw memory.
• Jdm: intra-thread… do you mean intra-runtime?
• Jim: Yes. If you want to debug worker threads, they have their own runtime and a single global that’s the content. Eddy added the support for multiple globals, which are only pseudo-privileged, in that they can’t touch the content objects directly to protect the debugger objects.

Supervisory JS

• Jim: So, Servo is avoiding this… what do you have for browser.html?
• Jdm: browser.html is treated as web content, but if dom.mozbrowser.enabled pref is true and the web content is in toplevel, it can add mozbrowser attribute to the iframe and gives access to the extra APIs on the iframe.
• Nox: Keeping in Rust instead of JS is because there’s no real benefit except where the self-hosted JS is faster. We like the Rust code because it’s clean.
• Jim: Some devtools folks also agree that we’d love to have Rust & some types.
• Tom: The big problem is that the Actors are no longer shared with Gecko then, so you have to keep the JS and Rust code up to date.
• Fitzgen: if Servo doesn’t use the Firefox protocol long-term, then it doesn’t really matter. If it does, then the work to separate out the actors from the XPCOM, it would be a ton of work anyway.
• Eddy: chromium instead has a dispatch map (in C++) to handle their privileged APIs. I suspect that any adoption of chrome’s protocol would remove actors.

Breakpoints & event queues

• Jim: When stopped at a breakpoint, the event loop is shared for the debugger AND the devtools UI. All those events end up in the same event queue that would be dispatching things in the debugee. So, when the content JS frame is on the stack, it makes a bunch of XPCOM calls to disable events to a given window & its children. Kinda works. But, sometimes there are other events that will get you - e.g., insertion of a script, which has an http event tied to it, can mean that not everything gets paused correctly. Too many entry points into content javascript. How hard is it to really pause a content page in the debugger but still have the UI live?
• Fitzgen: so, just saying a given event queue no longer has events.
• Jdm: It’s not hard at all. Already have a system for enabling/disabling subqueues of events for our given domain. IF the debugger interface is running cross-origin, they have totally independent event queues. Separate queue also just for the interfacing between the debuggee/debugger server.
• Jim: Great.
• Fitzgen: seems like if the server is written in Rust, it’s less of an issue there. Really want fatal asserts there - don’t want the debugger to lie to you.
• Jdm: google.com & google.com/somethinelse might mean we pause ALL things from the same-origin
• Jim: probably the right thing, right? If we have two separate tabs visiting the same site, can’t they share some stuff slyly?
• Jdm: I think this is BrowsingContext from the specs (or “related BrowsingContext”)

Killer features

• Jim: What are some killer features? Given our love for rr, I’m thinking all debugging is really reverse debugging. Bhackett has webrr, isolates debuggee it in its own process. Records some sources of non-determinism, and preserves some of those. Seems a bit fragile / complicated…
• Larsberg: Most of the sources of non-determinism in Servo are all isolated into threads/channels. We should be able to record/log the interactions and replay them. I’ve been talking with Brian Burg, and most of the architecture is amenable to doing things as he did in WebKit, but there are a few things (GPU-driven animations, DateTime, etc.) we need to do.
• Jim: Can we get some more notes from that? E.g., how do they handle JS state? I’ve been invited to comment on Brian Hackett’s WebRR project.
• Jim: Other nifty features?
• Jack: JIT coach?
• Jim: We’re talking about doing coaching for other things in the browser.
• Jack: Be nice to be able to show how parallel the rendering was and what the elements (e.g., floats) that got in the way of it were
• Fitzgen: Another thing is to have the infra exposed to web developers be the same that the engine developers are using. Gecko profiler addon has a split from the devtools. Nice to have performance probing/tracing in from the start. Recently found the profiler stuff, which is a great start. Nice to add dtrace-like probes to stuff random rust functions in random places to get profiles via script. Counters for how many reflows over a time, etc. Or give traces a unique ID and optional backpointer to the “why.” So that the timeline could show a correlation between the enqueued item and the work.
• Jack: for relayout, whenever it’s triggered, we have flags for whether it came from a query (and if so which one) or for redisplay. We could show that immediately.
• Fitzgen: getting the framework there and making it ubiquitous would help.
• Jdm: Linking it back to specific JS lines that triggered it would be like magic. Zero introspection into executing code right now.
• Fitzgen: There’s a method for capturing stacks now in SM that you should be able to use. Can keep them in the traces optionally.
• Tom: longstanding Gecko request. Everything on the network monitor should have a reason. What brought it in via what chain?
• Jim: stack capture is neat - shares common tails.
• Fitzgen: only walk to capture the first time, so it’s basically free in a loop.
• Joe: broader version of the layout is why did things lay out where
• Jack: not really user facing, but it shows the change in properties over each pass
• Fitzgen: specific CSS selector or rule would be great!
• Joe: would change the game for many web devs
• Jim: want the chain of causality
• Larsberg: Do we know what web devs have trouble with? Margin collapse hard to explain. Float clearing is easier.
• Jack: Maybe focus on top/left? And explain width - why is this all the way across the screen, etc.
• Jim: Explain 100%s? WHERE do they come from?
• Larsberg: Yeah, that’s easy but could be totally confusing… e.g., widths from heights :-)

Console

• Jack: Who can nox work with on Console and performance tools
• Fitzgen: Brian Grinstead and Lin Clark on the Console. Then probably me on perf tools - perhaps greg. People are kinda busy with Tofino.