Bugzilla

https://bugzilla.mozilla.org/show_bug.cgi?id=1581530 was caused because we assumed that the server would emit a `newSource` event before sending us a `paused` notification in a given source. We've generally relied on that, but it may be worth considering whether receiving a `paused` packet should actively fetch the sources if they are not found in the store already.

Alternatively, we should auto-resume if we receive a pause in an unknown location, but that may just delay the problem.

https://bugzilla.mozilla.org/show_bug.cgi?id=1581530 was caused because we assumed that the server would emit a `newSource` event before sending us a `paused` notification in a given source. We've generally relied on that, but it may be worth considering whether receiving a `paused` packet should actively fetch the sources if they are not found in the store already.

Alternatively, we should auto-resume if we receive a pause in an unknown location, but that may just delay the problem.

EDIT:
Another option would be that we can accept that these exceptions are going to happen sometimes, and just try to make it so that the debugger recovers on page refresh, instead of staying white forever. That may be the best option.

We upgraded to React 16 a while back, which will unmount the whole application if an exception during rendering reaches the root component. Instead, we should have an Error Boundary (https://reactjs.org/docs/error-boundaries.html) to catch the exception. An exception is an exception, so we can still put the UI into an un-useful state, but at least having the boundary would let us re-render the application once the user navigates the page.

We should also probably explore having boundaries without the application panels, but I think it's not obvious what granularity we would choose.