User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:43.0) Gecko/20100101 Firefox/43.0 Build ID: 20151210085131 Steps to reproduce: I've set a breakpoint using Firefox toolbox debugger inside the code I had developped for the Scratchpad tool. The function I needed to test is available under view > Highlight Mode > Plain text. Actual results: The breakpoint didn't work, I had to enter a breakpoint statement (debugger;) and setting a breakpoint on this line (1967). Expected results: The debugger should have stopped the execution on the breakpoint.

Sounds like this is affecting the Browser Toolbox

This bug is not actionable in it's current form. seb-dev, I know you provided steps to reproduce, but I cannot actually use these to reproduce the issue, since I don't have access to the source files you used. Could you please attach these to the bug, together with the exact steps you used to reproduce the issue? (i.e. what filename + linenumber you set the breakpoint on).

I've set the breakpoint inside scratchpad.js on line 1967. First, there was no debugger statement, and the toolbox didn't stop on this line, then I added the debugger statement on line 1967, corresponding with the breakpoint line. The files I've modified are given as a tar archive in attachments. I don't know if it's related, but I didn't rerun "./mach build faster" after modifying the javascript code from these files, resulting in state where the code displayed inside toolbox didn't match the code executed. Tell me if you need more.

Nobody is actively working on this right no, so assigning P2.

(In reply to James Long (:jlongster) from comment #4) > Nobody is actively working on this right no, so assigning P2. I just had a conversation about this with Patrick yesterday: priorities reflect whether someone *should* be working on a bug, not if someone is actually working on it. The idea is that we can search for P1 bugs when deciding what to work on next. We obviously have more P1 bugs than we can actively work on, but if we start downgrading P1 bugs simply because no-one has gotten around to them yet, we risk losing track of what bugs are important to work on. We also create a false sense of security: having more P1 bugs than we can chew off is a good signal that we might have to assign more resources. There are exceptions to this of course: if a P1 bug has been sitting around for over a year, then it's obviously not P1. However, that's not the case here. I want to propose resetting this to P1. James, what is your opinion?

I thought we agreed that P1 bugs are bugs that someone should *immediately* stop everything else and work on. Patrick sent out the email saying that we shouldn't have unassigned P1 bugs. I cannot assign this to me; I have a long list of assigned bugs already and I need to reduce them, not add to them. If this can't be assigned to somebody (which also indicates that it's being worked on), then this has to be P2. P1 should not be used as bookmarks. They are bugs that need immediate attention *and* are getting it. Bugs that we can't get to must be P2, and we can bump up the priority later. What's missing in the general workflow is "bookmarks": bugs that need to be looked at but we can't yet. I have my own personal system for this. I have my own simple UI that I can "star" bugs. Starred bugs are ones that need to get done but nobody is working on them yet. Maybe I misinterpreted what we decided P1 was for, but if it's only a hope that this gets worked on immediately it loses its meaning.

de-prioritizing because the scratchpad is not a priority.