Closed Bug 1244177 Opened 8 years ago Closed 5 years ago

Fuzz debugger breakpoints

Categories

(DevTools :: Debugger, task, P5)

task

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: jlong, Unassigned)

Details

I'm filing this bug for discussion, I don't have time to work on this yet but it would be great to talk about it. I talked with Jason Orendorff about this in Orlando and he said it's a great idea, and there's already work out there that we can use. Jason, you even mentioned getting someone to help, any idea who that might be?

The goal is to really solidify how our debugger breaks on code, and make sure it's doing what the user expects. The idea is to randomly generate JavaScript, and then randomly set breakpoints throughout the code and make sure it actually breaks.

There's a lot of different tests we could write, in case we also want to test step in/over/out, etc and make sure all of that works. But let's start with a simple one:

Condition: Given a JavaScript source, if I set a breakpoint on line 12, and code on line 12 runs, it should break.

Test:
* Randomly generate a JS file at least 12 lines long
* Set a breakpoint on line 12
* Run the script
* Use our code coverage information to see how many times line 12 was run, and test to make sure that we paused that many times on line 12

Does our code coverage information increase every single time any piece of code on a line is run? That would cause problems here because `foo(); bar();` should only break once; we make sure not to break again on the same line twice. But it will break again if we execute other lines first.

I'm not exactly sure how interesting that test is. But it's a place to start. Eventually it would be great to test stepping, but I'm not sure we can analyze a given JS file and know what the correct stepping would be.
Marking this as P2 for now, because I want us to start looking into this seriously next quarter. Making the debugger behave correctly should be our biggest priority after worker debugging, and breakpoint have been one of the biggest painpoints there.
Priority: -- → P2
Product: Firefox → DevTools
Priority: P2 → P4

I feel better about breakable positions, but it is still an interesting bug.

Thoughts logan?

Type: defect → task
Flags: needinfo?(lsmyth)
Priority: P4 → P5

Yeah tough one. It's a cool idea. I'm pretty confident in breakpoint positions at this point, so this doesn't seem strictly necessary. Breakpoint-wise we have plenty of issues, but position information isn't something I worry about anymore.

Flags: needinfo?(lsmyth)

makes sense.

Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.