Developers need to be able to debug a worker through a page reload, and they need to be able to debug a worker initialization, which is normally also done by setting a breakpoint in the worker initialization code and doing a page reload. Chrome handles this by persisting breakpoints in code throughout a browser session. In Canary, it's possible to set a breakpoint in a worker that is already loaded, and when the page is reloaded, the worker breaks on the previously set breakpoint.
Related to https://bugzilla.mozilla.org/show_bug.cgi?id=1192896 Eddy, just FYI, this is the issue I've been raising about not being able to persist breakpoints. It's ok to make it a requirement that a worker be loaded in order to set a breakpoint, but only the first time the worker is loaded. The breakpoint should be saved across a page reload or across a worker kill/restart. There are work arounds we could do, such as breaking on worker load, but for a developer, that's more tedious because they'd have to go back and reset the breakpoint every time. I spent some time debugging workers in Chrome, and I was reloading my page quite often to deal with worker behavior. This is also an issue with service workers. Developers may want to go to the about:debugging page and set a breakpoint for the SW, and then close that debugging session and work with a tab instead. They would want the breakpoint to hit even if the service worker wasn't in memory as long as it is still registered. In Chrome, as long as the SW is registered, the breakpoint will persist. The breakpoint only vanishes once the SW is unregistered. The work around without persisting breakpoints would be to go to 'about:debugging' and load the debugger on a specific SW and leaving that debugging session open while debugging a specific tab. It means the user now would need multiple windows - one for the tab and one for the SW. In Chrome you can get to the SW if the page loaded in the tab touches the SW. How difficult is this to do? Hopefully this does not mean re-architecting the debugger.
We almost certainly need the ability to "break on load" to install breakpoints at that point. The higher level debugger stuff can do that automatically on behalf of the user, but we obviously need to be able to install breakpoints before any script runs under the hood.
(In reply to Kyle Huey [:khuey] (firstname.lastname@example.org) from comment #2) > We almost certainly need the ability to "break on load" Sounds like (a specific form of) bug 917963, which shouldn't be too hard for someone who understands the debugger server.
Another issue here is that a page reload destroys the worker in that page, and the debugger server in that worker with it. Since we store our breakpoint state in the debugger server for each worker, we lose these breakpoints every time the page gets reloaded. In addition to break on load, we therefore probably need some form of global breakpoint storage, so that breakpoints are persisted between reloads of the same worker, and setting a breakpoint in a source in a worker causes the same breakpoint to be set in every other worker with the same source.
(In reply to Eddy Bruel [:ejpbruel] from comment #4) > Another issue here is that a page reload destroys the worker in that page, > and the debugger server in that worker with it. Since we store our > breakpoint state in the debugger server for each worker, we lose these > breakpoints every time the page gets reloaded. > > In addition to break on load, we therefore probably need some form of global > breakpoint storage, so that breakpoints are persisted between reloads of the > same worker, and setting a breakpoint in a source in a worker causes the > same breakpoint to be set in every other worker with the same source. FWIW, I estimate that implementing this would be moderately difficult, but not as difficult as our original idea of serializing/deserializing the state of the debugger server whenever a worker is destroyed/reloaded.
You need to log in before you can comment on or make changes to this bug.