When scripts are collected by the GC, the debugger loses the ability to set breakpoints at locations within them. When all the scripts in a source are collected, the source itself will not be shown by the debugger. These GC sensitive behaviors can only happen when attaching the debugger to an existing tab (when the debugger is open it keeps all debuggee scripts alive), but in that case they are a persistent source of unexpected and confusing behavior which needs to be fixed, or at least improved --- the second problem cannot be entirely fixed (eventually the GC must be able to erase all traces that a script was ever loaded into a realm), but it should happen less often and in a way that can be more easily controlled through tuning.
Per bug 944260 comment 9, the strategy here has two main aspects:
Keep the URLs for the sources in a realm around as long as possible. Heuristics here are TBD; we can't keep the URLs around forever, but if they are able to live longer and have predictable/controllable lifetimes then things should be less confusing for users. If the server finds a URL that has been loaded into a realm but has no sources, it can fetch that URL and show it in the client, as it has to do now when attaching to an existing tab and showing the HTML for inline scripts.
Obtain breakpoint positions in URLs where scripts have been GC'ed. To do this we need to ask spidermonkey to reparse the source (which is rather tricky when it's an inline script) and fetch the breakpoint positions in the resulting scripts so that the client can allow the user to set breakpoints in all scripts in the source, regardless of whether they have been GC'ed.
This work will be split up into dependent bugs on this one.