Closed Bug 1577673 Opened 5 months ago Closed 3 months ago

"Continue to Here" does not pause

Categories

(DevTools :: Debugger, defect, P2)

defect

Tracking

(firefox71 fixed)

RESOLVED FIXED
Firefox 71
Tracking Status
firefox71 --- fixed

People

(Reporter: jlast, Assigned: chris.muldoon90)

References

(Depends on 1 open bug, Blocks 2 open bugs)

Details

(Whiteboard: [debugger-mvp])

Attachments

(2 files, 1 obsolete file)

The editor's context menu has an option for continue to here, which fails if you are not selecting a valid breakpoint position. We should hide the option if there is not a valid position.

Duplicate of this bug: 1577674
Priority: -- → P2
Blocks: dbg-71
Whiteboard: [debugger-mvp]

To clarify, I think we should show the context menu item if there is a column breakpoint at the location the user clicked or to the right of it. So if the user clicks on line 71, col 12 and there is a column bp there or to the right we should show the menu item and then use it.

… or to the right we should show the menu item and then use it.

What about looking to the left?

It's our call, my thought was that sliding to the right was simpler. I've attached a visual of what sliding to the right would look like. Pink are positions where we will pause at the next breakable position. Red are positions where we do not have a breakable position on that line.

https://www.figma.com/file/CIQMlxue0yJDN1VaenI2cl/Untitled?node-id=1%3A19

Attached image continue to here.png

Hi Jason.

I'm a little confused of what constitutes a failure, and what you are alluding to, so i ran quick screen-cast of the different scenarios of 'continue to pause' (CTP)

Action - Click CTP on a line before the currently paused breakpoint.
Result - Jumps to next breakpoint (identical to chrome)

Action - Click CTP on a line after the currently paused breakpoint.
Result - Jumps to next breakpoint (identical to chrome)

Action - Click CTP on the SAME line before OR after the currently paused breakpoint (same line different column)
Result - Breakpoint does not change (Chrome will jump to the next breakpoint)

Which scenario should we be hiding the CTP option in the context menu?

Hey Chris,

I don't think where have the curser is relevant to this bug. There seem to be two objectives from what I understand.

  1. If there are column or regular breakpoints to the right of the paused position of the debugger, then 'Continue to Here' will pause on the next breakpoint. (Right now, this only works for regular breakpoints, not column breakpoints).
  2. If there are no breakpoints to the right of the paused position (column or otherwise), 'Continue to here' should be hidden from the context menu.

Let me know if that answers your question.

Assignee: nobody → chris.muldoon90

(In reply to janelledement from comment #8)

Hey Chris,

I don't think where have the curser is relevant to this bug. There seem to be two objectives from what I understand.

  1. If there are column or regular breakpoints to the right of the paused position of the debugger, then 'Continue to Here' will pause on the next breakpoint. (Right now, this only works for regular breakpoints, not column breakpoints).
  2. If there are no breakpoints to the right of the paused position (column or otherwise), 'Continue to here' should be hidden from the context menu.

Let me know if that answers your question.

Hi Janelle.

Thanks for the clarification.

Jason spoke with me via Slack video chat (that's how far off i was) to clarify this.

Seems you were a lot closer than me!

Early WIP patch.

Attachment #9098823 - Attachment description: Bug 1577673 - Continue to Here does not pause - fix continueToHere method to correct breakpoint → Bug 1577673 - Continue to Here does not pause. r=davidwalsh
Pushed by jlaster@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/bdbe51ab36a1
Continue to Here does not pause. r=davidwalsh
Status: NEW → RESOLVED
Closed: 3 months ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 71
Attachment #9098823 - Attachment is obsolete: true
Depends on: 1589870
You need to log in before you can comment on or make changes to this bug.