Closed Bug 1016046 Opened 7 years ago Closed 2 years ago
Debugging content scripts is confusing
With content scripts a single script is often loaded into multiple contexts at different times. The way this is handled in the Add-on Debugger UI is quite confusing (to me at least). Suppose we've got a simple add-on. It adds an action button: when you click the action button the add-on attaches a content script "annoy.js" to the current tab, that does something annoying (adds a click handler to the document that displays an alert). At first, "annoy.js" isn't available in the debugger, as I guess you'd expect, since it's not loaded yet (though it would be awesome if the debugger could somehow let me set breakpoints in scripts that haven't been loaded yet). Once I load a page and click the action button, "annoy.js" appears and I can set a breakpoint in it. If I then open a new tab and click the action button again, then the add-on attaches a new instance of "annoy.js". The breakpoint I set before doesn't work in this new instance of "annoy.js", but there's no indication of this in the UI. So: setting a breakpoint in a content script doesn't "carry forward" to future instances of the script: it is only applied to any instances of the script that are loaded at the time the breakpoint was set. This makes sense from an implementation perspective of course, but it makes the UI quite confusing, since the UI only displays a single entry that seems to represent "all instances of this script": but for a particular instance some breakpoints will work, and some won't, depending on when they were set.
Summary: Working with content scripts using the Add-on Debugger is confusing → Debugging content scripts is confusing
Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.