firefox-devtools / debugger

The faster and smarter Debugger for Firefox DevTools 🔥🦊🛠

Firefox Debugger

The Firefox Debugger is now maintained in Mozilla's central repository.

• Visit docs to learn how to contribute
• Checkout our dashboard to find good first bugs.
• Go to bugzilla to report an issue or suggest an enhancement.
• Feel free to ask questions at any point on Matrix

Thank You

The Firefox Debugger was built in Github for the first 3 years of its development. Over 300+ volunteers contributed thousands of commits and built many of the features we take for granted today.

We hope to continue that spirit today in Mozilla Central. We believe the Debugger can be a great place to collaborate on the next iteration of developer tools. And, that everyone regardless of background or experience can contribute work of significance.

debugger's Issues

Add Logging and Assertions in dev mode

There are three things here:

• logging
• assertions
• development mode

Logging: we could use DevToolsUtils and wantLogging
Assertions: we could use DevToolsUtils assert and testing

development mode - it might be nice to set this in environment.json

Change project name to debugger.html

Lets change the current name "debugger-experiment" to "debugger.html" in all the places it appears

• repo/project name
• readme
• directories/code

Investigate reselect

We currently have simple state query functions in queries.js. Lets investigate, reselect, which should help us clean up the way we access the state.

Investigate connecting to Chrome

Investigate a demo of debugger.html connecting to Chrome over the Chrome remote debug protocol (RDP).  This investigation should also include best target platforms for delivering the Chrome debugger which may be Chrome itself or alternate platforms such as Electron.

2-space CSS

My editor is set to 4-space but we want to conform to the current devtools style which is 2 space

Move Source attributes into selectors

Currently attributes filename and pathname are set in the reducer in _updateText. They should be moved to selectors getFilenameFromSource and getPathnameFromSource.

Write up a CONTRIBUTING.md doc

Set clear expectations and guidelines for contributing.

• Github Quick Replies
  Explaining how we are moving fast etc.
• Link to Contributing doc from the README

CSS Pane / Splitter Component needs to be improved

The Pane / Splitter Component needs to be made more robust in terms of CSS to prevent things like over expansion from child content.

• Prevent child content from expanding the pane size

Refreshing the debugger fails to detatch

Steps:

1. set a breakpoint in the debugger
2. do something in the page to trigger the breakpoint
3. refresh the debugger

What happens:
The debugger does not detatch.

What should happen:
Debugger should call detatch on unload or something to that effect.

Editor style pass

We should update the editor styles so that they are the same as the firefox editor.

Here is a link to the official stylesheet

Update Editor style

• Update font styles
  The current font choice is small and could be improved by using a better monospaced option.

• Update breakpoint styles
  The breakpoint style could be improved and the line number needs to be visible

  https://github.com/jlongster/debugger.html/pull/85

Add Karma test harness

Karma will let us run our tests in different environments (firefox, chrome, node, ...)

Step buttons

User Stories

As a web developer whose code has paused in the debugger I need to be able to step into the next statement on the line that is currently paused such that I go deeper into the stack.

As a web developer whose code has paused in the debugger I need to be able to step out of the current scope I'm paused in such that when I discover I'm in the wrong place I can pop back up the stack.

As a web developer whose code has paused in the debugger I need to be able to step over the function calls on the currently paused line such that I don't jump deeper in the stack and continue to the next statement.

Notes

Standard debugger type buttons that trigger their respective action.

Step In

Step Out

Step Over

• Step In button
  Steps into the next function
• Step out button
  Steps out of the current scope
• Step over button
  Steps over the next function / scope

Sources Style Pass

The Sources Pane is now selectable and grouped by domain.

It'd be great to do a quick style pass on typography and layout. Hopefully we will be able to add nesting/collapsing with a tree view soon, and do a second pass.

Test scripts should find all js test files

Currently the node + browser test scripts only file test files in a test folder. The script should be able to recursively search for test folders and then add tests files.

Toggling breakpoints in global list

User Stories

As a web developer I need to be able to toggle breakpoints in other areas of code that aren't visible in the debugger editor such that I can avoid hitting breakpoints I'm not currently interested in.

• Add checkbox to each breakpoint in the global list
  Checked status of checkbox should be wired up to the enabled / disabled status of the breakpoint.

Investigate Pretty Print Source

User Story

As a developer who is using minified source code I want to be able to convert the code into a pretty print version such that I can more easily read and understand the code.

Notes

Firefox replaces the current source code with the pretty printed version so an improved interaction like how Chrome creates a new source filed x.js:formatted isn't in scope just yet.

UX needs

• Location of toggle button
• Progress bar? (do we need a progress bar for when conversion takes a while)
  • Currently Firefox blocks access to the existing source code, this is an interaction we probably want to avoid
• Button to toggle pretty print
  Swaps out the current editor code with formatted version.

xpcshell tests

Add a dev/prod flag

The flag will help with asserts, logging, and other tools that should only run in dev.

Discuss adding lodash

I'd like to discuss the merits of adding lodash for debugger.html.

reasons to do it:

• readability - lodash's utility functions like (groupBy and isEmpty) could dry up the code considerably (1, 2)
• quality - John-David Dalton is managing the project full time at Microsoft and has done a great job of creating a consistent API, with test coverage, performance metrics, and documentation. Also, many of his APIs are informing the standards bodies.

arguments against doing it:

• lodash would add weight. Lodash minified is relatively small. If at somepoint, we adopt a build system like webpack, only the functions used would be bundled. For example, if we only required chunk, chunk = require('lodash/chunk') only chunk and its dependencies would be added to the build.
• it is easier to build what you need. In practice, I've found that this practice often leads to more bike-shedding, where there is a debate over each new functional bit added. Over time, the internal utilities are often not as good in terms of API design or extendability, as what is available.

Path forward:

• use lodash it for the project
• try lodash with the understanding that if we decide not to keep it, we could easily replace the call sites
• use a subset of core array and object functions

Respond to Pause / Resume events

User Stories

As a web developer, when my code hits a break point I would like to see an indication of which breakpoint was triggered and in which files such that I can inspect the code at that location.

• Highlight the line in the editor
• Toggle the pause / resume button
  Se the pause / resume button to the appropriate state of the debugger.
• Indicate in breakpoint list
  In the global list of breakpoints indicate which breakpoint caused the debugger to pause, if a breakpoint is responsible for the event.
• Open the file with the active breakpoint
  Open the file in the Editor that has a breakpoint that was hit.

Move build directory into public

It'd be nice to move the build directory into the public. The rationale is that then all debugger assets are under public.

• move build directory
• update webpack config
• update server.js
• update test runners

Figure out how to test actions

• how to access client
• mock client functions
• basic assertions on the shape of the store

Node test script should avoid bundling

The node test script currently bundles and transpiles the source for node. It should be possible to avoid bundling the source and instead use babel-register.

This will have a performance win. It will also be easier to debug.

https://github.com/jlongster/debugger.html/issues/57#issuecomment-210608020

Align Action Buttons to Pixel Grid

Spoke with Helen today, and will do a quick pass on some of our SVG icons

- [ ] make the width / height consistent
- [ ] set fill states (disabled, hover, active)
- [ ] convert stroke widths to paths for pixel snapping

[@helenvholmes Edits]:

• pause
• play
• step into
• step out
• step over
• remove all breakpoints
• blackbox source
• pretty print

Selectable Sources

User Stories

• Show source code in CodeMirror
  Use the CodeMirror code to display source code selected from the list
• Indicate which file is currently selected
  When a file is selected it should have some indication in the list that it is the file currently being displayed.

Convert browser test script to a server

Currently, the browser test workflow is two steps:

1. run npm run browser-test
2. refresh browser tab with the tests.

If we create a browser test server, similar to debugger server, then the browser test build will be built on the fly and returned.

Simple variable scope list

User Story

As a web developer who is stepping through their code I want to see the available variables and current scopes involved in the page such that I can inspect the values of my variables and be aware if any of them are hoisted out of my expected scope.

• List of scopes
  On the right hand side, under the breakpoint list.
• List of variables within scopes
  Variables are listed inside the accordion under the scopes.

Investigate Source Tree View

User Story

As a developer I would like the various JS source files organized by domain and folder such that I can easily navigate the hierarchy to find the files I'm looking for.

• Tree Node for each non-empty directory

Investigate Call Stacks

User Story

As a user who has paused the debugger I would like a display of the current frames in the call stack such that I can see the chain of events that brought me to the current code as well as jump from this frame to another to view the source code.

• Selecting a frame opens the source location
• List of all frames in the stack
  Below the break points and above the scope

Selecting a source does not update the breakpoint markers

When you add breakpoints in source a, go to source b, and navigate back to source a, the breakpoint markers are not shown.

This is a relatively easy fix, but it probably requires us to re-think the way we're writing the Editor component, to better take advantage of the redux store.

Integrate devtools eslint file

Consider keeping deps up-to-date with greenkeeper.io

Greenkeeper is popular with other major open source projects. I've used greenkeeper my own projects and find it really useful. It takes the work out of tracking package dependencies by auto-monitoring them and bringing them to our attention as needed.

Greenkeeper sits between npm and GitHub, observing all of the modules you depend on. When they get updated, your project gets a pull request with that update. Your CI tests kick in, and Greenkeeper watches them to see whether they pass. If they do, you can just click the merge button, and we'll even auto-close branches for older versions for you. If not, you can use the branch to fix things.

https://greenkeeper.io/#how-it-works

@jlongster is the admin so he will have to enable this if we want it.

Here's an example of what it will do on the first run: clarkbw/debugger.html#1

Pause / Resume button

User Stories

As a web developer I want to be able to resume the debugger which has paused at a breakpoint such that I can continue watching the code run.

As a web developer I want to be able to pause the debugger such that I can trigger an action and immediately see what code is run first.

• Pause / Resume button
  A pause / resume button that toggles the debugger between the two possible states.

static linters

• CSS linter
  Run on all pull requests
• JS Linter
  Run on all pull requests
• Setup Travis CI for linting

Add / Remove Breakpoints

User Stories

As a web developer I want to be able to add a breakpoint at a certain line of my code such that I can create points in my application where the debugger will pause.

As a web developer I want to be able to remove breakpoints at certain lines of my code such that I can avoid pausing in areas I no longer need to inspect.

As a web developer I want to be able to see a global list of breakpoints currently active such that I know how many breakpoints are active and where.

• Add breakpoint from within the code editor
  Add a breakpoint by clicking on the line numbers in the left hand gutter where a breakpoint doesn't already exist.
• Remove a breakpoint from the code editor
  By clicking in left hand side gutter on an active breakpoint, that breakpoint is removed.
• List all breakpoints in global breakpoint view
  Each breakpoint should be listed in the global breakpoint view as:
  • file:line number
• Update styling for breakpoints

Investigate Conditional Breakpoints

User Story

As a developer who is debugging their code I need a breakpoint that only triggers under certain scenarios such that when a certain expression is true my breakpoint will pause execution.

Notes

Chrome Implementation:  https://developer.chrome.com/devtools/docs/javascript-debugging/conditional-breakpoint-region.jpg

UX Needs

• Button or entry point to open a small input dialog
• Input dialog that explains expression needs
• Initial button to add breakpoint

Fix editor scrolling in Chrome

For some reason it doesn't scroll right now. Works fine in Firefox. It's probably a simple CSS fix (overflow: auto somewhere).

Investigate immutable.js

We are currently using seemless-immutable, but there are benefits to using immutable.js.

Lets weight the pros/cons and make a decision now so that we don't have a bigger refactor later.

Fix Storybook

We broke Storybook yesterday when we added actions to the breakpoint component. Not a big deal, storybook is not on the critical path.

Root cause:

Storybook's webpack config has a babel loader that does not exclude ff-devtools-libs and is causing an issue with Task.async.

Fix:

I'm going to look into a simple upstream fix that will let us write the webpack config that storybook uses.

Refreshing debugger loses breakpoint state

Steps:

1. select a source
2. add breakpoints
3. refresh
4. select the same source

What happens:

The breakpoints are neither shown in the editor or breakpoint list

Use a server

Might as well get a basic server going so avoid file:// issues. A simple express server that serves the static assets works, unless there's something else?

Investigate running tests in node

We are currently working on running our unit tests with xpcshell because it would be easier to integrate when we merge the experiment back.

We've made a lot of progress in this effort. We've made it possible to run xpcshell-unit-test from any directory. We've also added additional shams to ff-devtools-libs for running async tests in an xpcshell environment.

In the process, it's becoming clear that our test infrastructure would rely on the xpcshell environment in a similar way as the gecko debugger client relies on browser internal libraries. This conflicts with one the the primary goals of devtools.html, which is to run the client in any browser context and potentially debug any JS environment.

With this in mind, it would be nice to explore running the debugger's unit tests in node. The primary benefit of node, would be that we would be constrained to writing tests that could potentially run in any environment.

This approach would add additional work when it comes time to merge. I see two possible approaches:

1. we add some hooks in our test infrastructure to run in xpcshell
2. we add try node test runner. This option might be more in vogue with project tofino.

One of the side-effects of using node is the lack of xpcshell test runner. If we go with node, we could either use mocha or write a small test runner with similar semantics to xpcshell test. There has been significant interest in using mocha before, so we should consider that option and see if we would be comfortable using mocha post merge.

Investigate Travis CI for running tests

We want Travis to run tests against every PR however currently it is only running lint tests.

In order to run our unit tests we need the xpcshell binary available on Travis.

There are several ways to possibly accomplish this:

• Download an xpcshell binary (that matches platform) from somewhere and use this to run test
• Build Firefox from source to create the xpcshell binary to run the tests
• Pull a copy of xpcshell into our own repo which could run the tests for us

Investigate Tree View Component

Investigate and review the various Tree View components available as modules compared to the internal Firefox Tree View module available.  This module will be the basis for the Source Code Tree View.

Fixup debug buttons when not paused

There are two problems with the debug buttons when the debugger is not paused:

1. The resume button is shown instead of the pause button
2. The step in, step over, step up buttons are active and not disabled

Update Circle CI firefox version

It's currently running Firefox 42...

It looks like we can improve that easily though
https://discuss.circleci.com/t/installing-the-latest-version-of-firefox-in-circleci/1347

Chrome DevTools crashes

So, this is a little ironic, and mostly sad, but when I'm debugging debugger.html in Chrome, chome devtools is very unreliable. I'd like to get to the bottom of this, I'm not sure if it's a websocket thing, webpack source map thing, or what, but it makes it very difficult to make progress.

Investigate Integration Tests

Debug Button enhancements

we just added the buttons, but there are some enhancements that would be nice to land:

• The buttons should appear on the top of the sidebar (not below breakpoints)
• the handlers should invoke redux actions that talk to the threadClient
• the buttons use real icons 😉