Breakpoint doesn't work in Browser Toolbox

UNCONFIRMED
Assigned to

Status

P2
normal
UNCONFIRMED
3 years ago
4 months ago

People

(Reporter: u560889, Assigned: jlast)

Tracking

(Blocks: 1 bug)

43 Branch
x86_64
Linux

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

21.51 KB, application/gzip
Details
(Reporter)

Description

3 years ago
Created attachment 8715784 [details]
bug.tar.gz

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.
(Reporter)

Updated

3 years ago
Component: Untriaged → Developer Tools
OS: Unspecified → Linux
Hardware: Unspecified → x86_64

Updated

3 years ago
Component: Developer Tools → Developer Tools: Debugger
Sounds like this is affecting the Browser Toolbox
Summary: Toolbox breakpoint doesn't work → Breakpoint doesn't work in Browser Toolbox
Blocks: 1070868
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).
Priority: -- → P1
(Reporter)

Comment 3

3 years ago
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.
Priority: P1 → 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?
Flags: needinfo?(jlong)
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.
Flags: needinfo?(jlong)
(Assignee)

Updated

3 years ago
Assignee: nobody → jlaster

Updated

4 months ago
Product: Firefox → DevTools
You need to log in before you can comment on or make changes to this bug.