870355 - Breakpoints in the Debugger aren't always set right

Status: RESOLVED INVALID

(DevTools :: Debugger, defect)

Description

[Ioana (away)]

Reproducible on the latest Firefox 21, 22 and 23 builds.

STR:
1. Load http://carlcamera.com/codemash/ in a new tab.
2. Open the Debugger (Ctrl/Cmd+Shift+S).
3. Make sure jquery.isotope.js script is selected.
4. Click next to line 15 ((function( window, $, undefined ){) to set a breakpoint.

Actual Results:
The breakpoint is shown as set for a second, then it's moved to line 19.

Expected Results:
The breakpoint is set. If there are special conditions under which you cannot set a breakpoint, a warning about that should be displayed. No breakpoints should be set on other lines.

Notes:
1. This issue also reproduces on other scripts/lines from this website, but I couldn't reproduce it with other sites.
2. This is a regression that appeared in Firefox 19 (works well in 18).

Comment 1

[Mihai Sucan [:msucan]]

As far as I know this is working as intended. Victor, is there a way to avoid showing the breakpoint on a different line for (less than) a second?

Comment 2

[Nick Fitzgerald [:fitzgen] [⏰PST; UTC-8]]

Followed the STR and I am able to set a breakpoint on line 15.

Regardless, I suspect what is happening is that we are trying to set a breakpoint on a location where there isn't an offset and so we get back an actualLocation and then update the breakpoint icon ui.

I think it would be nice to just have a css transition so that moving the breakpoint icon wasn't so jarring.

Comment 3

[Victor Porof [:vporof][:vp]]

(In reply to Mihai Sucan [:msucan] from comment #1)
> As far as I know this is working as intended. Victor, is there a way to
> avoid showing the breakpoint on a different line for (less than) a second?

Yes, this is working as intended.

If the breakpoint was added via the source editor (click in the gutter), then no, we can't avoid flashing, since the new location needs to go through the API, checked serverside for sane-ness, then sent back. This, obviously, takes a bit of time. I suppose the source editor API could provide some prefs like "don't display an icon when clicking on the gutter until we say so", but I think that's overkill.

Comment 4

[Victor Porof [:vporof][:vp]]

(In reply to Nick Fitzgerald [:fitzgen] from comment #2)
> Followed the STR and I am able to set a breakpoint on line 15.
> 

WFM in Nightly, the breakpoint goes to the right location.

Comment 5

[Ioana (away)]

Attachment: Video screen capture of this bug reproducing

As visible in the video, the first time I click line 15, the breakpoint is displayed on line 15 for a second (or less), then it suddenly gets set on a line below without me doing anything else. The same happens when clicking line 21.

I reproduced this issue on all the main platforms, but it doesn't always reproduce with the exact same lines (e.g. I clicked line 15 and the breakpoint got set on line 18, another time on line 19, and once on line 15)

Comment 6

[Victor Porof [:vporof][:vp]]

(In reply to Ioana Budnar, QA [:ioana] from comment #5)
> Created attachment 747841 [details]
> Video screen capture of this bug reproducing
> 
> As visible in the video, the first time I click line 15, the breakpoint is
> displayed on line 15 for a second (or less), then it suddenly gets set on a
> line below without me doing anything else. The same happens when clicking
> line 21.

And that's ok IMHO. There's bug 799077 for making things prettier. Mihai, what do you think?

Comment 7

[Ioana (away)]

(In reply to Victor Porof [:vp] from comment #6)
> And that's ok IMHO. There's bug 799077 for making things prettier. Mihai,
> what do you think?

This is not just about tranzitions. As a user, when I click a certain line, I expect the breakpoint to be set there. If that's not possible, I expect to see a message that explains that to me.

Besides that, this used to work in the debugger before, so I doubt the impact on an older user can be any kind of good.

Comment 8

[Mihai Sucan [:msucan]]

What we can do is to not really add the breakpoint in the editor until we know on which line it ends-up. We avoid transitions and flickers. However users will then complain they click one line and they get the breakpoint on a totally different line.

We can't make everyone happy - bug 799077 is, probably, the most sensible approach.

Comment 9

[Panos Astithas (he/him) [:past] (please ni?)]

(In reply to Ioana Budnar, QA [:ioana] from comment #7)
> (In reply to Victor Porof [:vp] from comment #6)
> > And that's ok IMHO. There's bug 799077 for making things prettier. Mihai,
> > what do you think?
> 
> This is not just about tranzitions. As a user, when I click a certain line,
> I expect the breakpoint to be set there. If that's not possible, I expect to
> see a message that explains that to me.
> 
> Besides that, this used to work in the debugger before, so I doubt the
> impact on an older user can be any kind of good.

What used to work before is that the breakpoint location wasn't being updated to reflect the location that contained actual bytecode. You might wonder how come line 15 doesn't contain any bytecode, and it really does, but that (outer) script has been scavenged by the time the debugger opens. That's the reason the breakpoint sticks for some and slides for others.

For a reliable experience, open the page, then open the debugger after it has finished loading, then set the breakpoint. It should slide to line 19. Then with the debugger open reload the page and try to set the breakpoint again. It should stick to line 15.

I'm closing this bug, since, even though it can be unintuitive in some cases like this one, this is how breakpoints are designed to work.

Comment 10

[Ioana (away)]

(In reply to Panos Astithas [:past] from comment #9)
> I'm closing this bug, since, even though it can be unintuitive in some cases
> like this one, this is how breakpoints are designed to work.

A behavior being by design does not excuse the fact the it's unintuitive. IMHO, we should care more about user experience. Can't there at least be added some kind of message that would let the users know what's happening?

Comment 11

[Victor Porof [:vporof][:vp]]

(In reply to Panos Astithas [:past] from comment #9)
(In reply to Ioana Budnar, QA [:ioana] from comment #10)

I can see how this might be, not necessarily confusing, but surprising for a second. I'd imagine, though, that when a breakpoint moves to a different line, the reason becomes at least apparent if not obvious.

Going back to comment #0, adding a breakpoint on line 15 there might mean "please break when this function is defined", which is the same as "please break when this function is executed" in this case. So a popup or notification box specifying what happened to the breakpoint might be pertinent.

Other cases for breakpoints moving to different lines are, for example: setting them on comments, empty lines etc. I think it completely redundant to specify a reason in those scenarios, because it's pretty obvious that you can't break where there's no code :)

However, code-wise, you can't easily (if at all) distinguish surprising scenarios from obvious ones, so it's hard to come up with a notification that's both useful and not redundant 90% of the time.

Having said that, it's useful to remember that the current behavior is actually doing the user a service. It's better to move the breakpoint to a pertinent line than having a breakpoint that never hits. Most IDEs I worked with never actually do this and it can get frustrating sometimes.