Thanks for opening this bug.
I'm having a hard time understanding why the debugger becomes 100% blank because of a missing event?
Shouldn't it always be rendering its complete UI, but may be empty in same places?
I would expect the following components to always be rendered, even if server's behavior is confusing:
- The three panels: left sidebar, sources and right sidebar
- empty source tree
- breakpoint control toolbar
- all the breakpoint control UI (watchpoints, breakpoints, XHR, Event, DOM), possibly empty
Doing that, might help limiting breakages to a very particular part of the debugger instead of making it 100% unusable.
I'm seeing more and more reports of blank debuggers, leading to a totally unusable product rather than a partially broken one.
(In reply to Logan Smyth [:loganfsmyth] from comment #0)
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.
To be clear, it looks like the debugger frontend would miss a more systemic pattern to prevent becoming blank.
I don't think this has to be specific to bug 1581530's very particular breakage.
It sounds like something at Redux level, or within bootstrap code, should be done so that, in general, the base debugger UI renders.