1172931 - Breakpoint not hit after reload when set on pretty-printed source

Status: RESOLVED FIXED

(DevTools :: Debugger, defect, P2)

Description

[nayinain]

Attachment: testcase.html

Comment 1

[J. Ryan Stinnett [:jryans] (Use needinfo, replies may be slow)]

This is not enough information to proceed.

Can you provide precise steps, as well as a code test case for reproduction?

Comment 2

[nayinain]

(In reply to J. Ryan Stinnett [:jryans] (use ni?) from comment #1)
> This is not enough information to proceed.
> 
> Can you provide precise steps, as well as a code test case for reproduction?

1. Open the "testcase.html".
2. Open Debuger, Refresh and select the Data-URL item.
3. Prettify Source, Set a breakpoint at line 2.
4. Refresh.

Sorry for my bad English.

Comment 3

[J. Ryan Stinnett [:jryans] (Use needinfo, replies may be slow)]

Great, thanks!  (I thought the attachment was just a picture at first, but it includes the test source too!)

Comment 4

[Hallvord R. M. Steen [:hallvors]]

This is an important issue.
Here's another test case:
http://hallvord.com/temp/moz/bug/1172931/minified-1.htm

STR: 
1) Load test
2) Open debugger, pretty-print the external JS file and set random breakpoints
3) Re-load page, observe how the debugger claims all breakpoints still exist but it doesn't actually stop at them

Comment 5

[Hallvord R. M. Steen [:hallvors]]

What would it take to fix this? It's making it impossible to use the debugger on tons of production sites, given that most of them have JS that needs pretty-printing. When you can't stop on a non-user-triggered thread it's a severe limitation on what you'll be able to use the debugger for.

Comment 6

[Mike Taylor [:miketaylr]]

This bug is making figuring out https://bugzilla.mozilla.org/show_bug.cgi?id=1258733 really hard. :( 

Lately I've just been using the Chrome DevTools debugger for debugging prettified code, but in this instance I really need to understand why Firefox's behavior is different.

Comment 7

[James Long (:jlongster)]

I can repro this. I'm not sure what the cause is off-hand; we've touched this code but I don't what happened. I'm coworking today with someone so it'll have to wait until tomorrow.

Comment 9

[Patrick Brosset <:pbro>]

I just tested this in the latest version of the new debugger. On Firefox Nightly 54, with devtools.debugger.new-debugger-frontend set to true (which is its default value on Nightly and Aurora).
It looks like it kind of works, but I can't be sure.

- Open the test case from comment 0
- Open the debugger (reload the page to make the source appear in the list, it's weird that it's not there by default, but that's probably another bug)
- Right-click on the tab (above the source code section) and choose "pretty print"
- Add a breakpoint on line 2
- Reload the page

==> For me, the debugger paused right after the page was reloaded. The source was back to its original non-pretty-printed state though. But according to comment 4, the problem seemed to be that the debugger would not even stop at all.
Of course it then takes one more right-click/click to prettify the source again, which isn't great.

Right now, the new debugger is only ON in nightly and aurora because there still are some missing features from the old debugger that we want to implement before we turn it on everywhere.

Bryan: could you link to the meta bug we use to track the missing features?

Comment 10

[Bryan Clark (DevTools PM) [:clarkbw]]

Here's where we are tracking the required items for release: https://github.com/devtools-html/debugger.html/milestone/17

Comment 11

[Boris Zbarsky [:bzbarsky]]

Fwiw, this is not working for me with the new debugger frontend.  Steps:

1) Load http://www.needhamma.gov/index.aspx?NID=262
2) Open debugger.
3) Select "92729130.js" in the left-hand pane.
4) Prettyprint.
5) Breakpoint in the first line of the function assigned to r['webgl']
   (line 4487 in the prettyprinted bit as of today).
6) Reload.

The breakpoint is not hit.  That code _is_ hit; I can tell by setting C++ breakpoints in the webgl canvas stuff.

Comment 12

[Boris Zbarsky [:bzbarsky]]

Oh, and the reload is needed, because this is modernizr startup code, so only runs during the initial pageload....

Comment 13

[Bryan Clark (DevTools PM) [:clarkbw]]

I believe this is being tracked in this issue: https://github.com/devtools-html/debugger.html/issues/3532 where pretty printed breakpoints are not persisted.  When I try the STRs without the pretty print step it works as expected.

Comment 14

[Boris Zbarsky [:bzbarsky]]

> When I try the STRs without the pretty print step

Right, but how do I set a breakpoint on a particular statement in minified code without prettyprinting it first?

Comment 15

[Bryan Clark (DevTools PM) [:clarkbw]]

(In reply to Boris Zbarsky [:bz] from comment #14)
> > When I try the STRs without the pretty print step
> 
> Right, but how do I set a breakpoint on a particular statement in minified
> code without prettyprinting it first?

Sorry, that wasn't clear.  I was just confirming the other action works, I don't think there's a way to set a breakpoint otherwise unless we had column breakpoints enabled (and we don't).

Comment 16

[Patrick Brosset <:pbro>]

Comment 2 and comment 4 now work for me in FF58. 
I've had troubles with the STR in comment 11 though. I think I reproduced the issue once but then couldn't.

Comment 17

[Jason Laster [:jlast]]

I believe this is fixed. Let me know if you can reproduce.

Comment 18

[Boris Zbarsky [:bzbarsky]]

This still reproduces for me with the steps in comment 11 (the relevant file is now <http://www.needhamma.gov/862359113.js>).

What I see happening is that the page loads, the code runs, and _after_ all that the debugger UI updates to show the breakpoint being set.  So it's possible that we are in fact setting the breakpoint, but too late, after the code has already run...

In any case, the breakpoint is certainly not being hit with the steps from comment 11 modified with the updated filename.

Comment 19

[Jason Laster [:jlast]]

Thanks. I tested an indeed it is not working.

While testing, I noticed that the breakpoint is added and then removed when we reload, which is not great.

Comment 20

[Jan Honza Odvarko [:Honza] (always need-info? me)]

Updated STR:

1. Load http://www.needhamma.gov/index.aspx?NID=262
2. Open debugger.
3. Select "862359113.js" in the left-hand pane.
4. Prettyprint.
5. Breakpoint in the first line of the function assigned to r['webgl']
   (line 4496 in the prettyprinted bit as of today).
6. Reload.
7. The breakpoint is hit for me. // <- Was not previously working

The only issue I can see is that the source file is not auto-scrolled to the 4496 line

@bz: can you try the steps? Does it work for you?

Thanks!
Honza

Comment 21

[Boris Zbarsky [:bzbarsky]]

Yes, now it works for me, modulo the not scrolling to the line we're stopped on.

Comment 22

[:Harald Kirschner :digitarald]

Honza, can you confirm that for your steps that it jumps to the right line now (today's Nightly)? It does have some flickering in the highlighting (1st highlight wrong first line, 2nd and 3rd highlight on the right line). If so, we can close this and open a bug for the wrong highlighting.

Comment 23

[:Harald Kirschner :digitarald]

Attachment: triple-highlight.gif

3 highlights firing but ending on the right line.

Comment 24

[Jan Honza Odvarko [:Honza] (always need-info? me)]

(In reply to :Harald Kirschner :digitarald from comment #22)

Honza, can you confirm that for your steps that it jumps to the right line now (today's Nightly)? It does have some flickering in the highlighting (1st highlight wrong first line, 2nd and 3rd highlight on the right line). If so, we can close this and open a bug for the wrong highlighting.

Yes, works for me in Nightly (auto scrolls to the line) and I can also see the flickering

Honza

Comment 25

[:Harald Kirschner :digitarald]

Per last comment, verified fixed.