September 5th

This past week was one of the more impressive weeks in the project:

@codehag, @darkwing, @rohanprasad, @pradeepgangwar, @jasonLaster, @nyrosmith, @bomsy, @gabrielluong, @yurydelendik, @wldcordeiro

UX/UI:

Project Search is one of those features, which is hard to get just right. This week, @bomsy fixed an issue which was breaking keyboard navigation when search results were streaming in. The basic problem was every time the results were updated, the UI needed to re-focus on the first item, this is easier said than done! We also added a lot of polish to the UI, @zacck is working on making sure our focus, hover, and select states are all correct!

project

Empty lines:

We think the debugger is a great place to teach users about the semantics of JS. This is why, we’ve started marking lines of code that are in scope when paused. It is also, why we wanted to start disabling lines of code that are not executable. Another nice benefit is that the debugger will no longer try and guess where to “slide” a breakpoint to, which can create some weird interactions.

Huge thanks to @darkwing who added the parser utilities for finding empty lines, the reducer for storing empty lines, and the empty lines component.

empty

Workers panel:

Firefox has great support for web workers and service workers. For instance, a worker can have a child worker. Unfortunately, the Firefox debugger has lagged behind Chrome’s. We hope to catch up. This past week @nyrosmith started working on a workers right sidebar panel which will show a list of workers that can be debugged. The old UI had this, and we know it is important to surface. We hope to make it possible to debug workers in the same toolbox in Q1 of 2018.

AST breakpoints:

AST breakpoints is perhaps the biggest upgrade to breakpoints that since source mapped breakpoints :) In July, we started checking the breakpoint’s generated location on reload to see if it had moved away from the original location. If it had, we would remove it and create a new one. With AST breakpoints, we are now saving the breakpoints closest function and offset so that on reload we can see if the function moved, and if so move the breakpoint as well. We hope to add more AST specificity in the future so that breakpoints can be pinned to variable declarators, call expressions, and many other AST locations!

ast

Mapping Minified Variables

One of the biggest issues with debugging with source maps, is that while you get line-to-line mapping, you don’t get variable-to-variable mapping. This means, that you can add a breakpoint and step easily with breakpoints, but you can’t easily see or preview the variables when paused. There are three specific bugs here: the variables in the scope pane are from the “generated” scope and hovering on a variable or evaluating in the console is broken.

We hope to solve these problems by mapping generated and original variables. And we’re starting with the minified case. This week, @yurydelendik created the initial PRs for doing the mapping and got a proof of concept of preview and scopes working!

map

Async Stepping:

Async stepping is a subtle feature, where when the user pauses on an async expression they expect to be able to step over it and land on the next statement.

This means that when the debugger pauses it needs to figure out if it is at an await expression and then where the next statement is.

async function updateUser(name, email) {
  const realName = formatName(name)
  const updatedUser = await updateUserAPI(realName);
  return updatedUser;
}

@jbhoosreddy landed this feature last week. It’s

async

Bugs

Code Health

Documentation

Infrastructure: