Debugger state gets confused when debugging gmail on beta
Categories
(DevTools :: Debugger, defect, P2)
Tracking
(Not tracked)
People
(Reporter: Gijs, Unassigned)
References
Details
+++ This bug was initially created as a clone of Bug #1532240 +++
STR:
-
66beta12, on mac
-
open gmail and log in.
-
open inspector
-
click {event} bubble on <html> (this doesn't work on nightly, see bug 1532237) . Expand the first 'click' event handler (there are a lot).
-
click the "go to this in the debugger" button
-
stare in confusion at the minified JS, and click "pretty print" button in the bottom left hand corner
-
lose your place, so go back to inspector, repeat step 3/4 (I'm assuming this is already on file elsewhere).
-
the debugger focuses the
addEventListenercall.b.addEventListener(c.toString(), e, f);
-
set a breakpoint here.
-
click an empty bit of space in the page (e.g. to the right of the search field, and to the left of the set of icons in the top right corner)
ER:
the breakpoint either gets hit or doesn't get hit, and the focused line will be the line that has the breakpoint on it.
AR:
the debugger stops for the breakpoint, but for handling the click event in the actual event listener, which is a few lines down in the source code. The screenshot in bug 1431400 shows this case.
|
||
Updated•5 years ago
|
|
|
||
Updated•5 years ago
|
|
||
Comment 1•5 years ago
|
||
With the recent breakpoint work, I wonder if this still persists. Could you help by re-testing, :Gijs?
|
Reporter | |
Comment 2•5 years ago
|
||
(In reply to :Harald Kirschner :digitarald from comment #1)
With the recent breakpoint work, I wonder if this still persists. Could you help by re-testing, :Gijs?
Following the steps in comment #0 on current beta (67), I get stuck at step 6 because repeating the steps always loads the non-pretty-printed version of the script, so I can't even see the event listener I want to debug. So things haven't really improved much for this case.
|
|
||
Comment 3•5 years ago
|
||
Following the steps in comment #0 on current beta (67), I get stuck at step 6 because repeating the steps always loads the non-pretty-printed version of the script, so I can't even see the event listener I want to debug.
This works for me. It even jumps to the right event listener. Breakpoints also worked, including Logpoints.
|
|
Reporter | |
Comment 4•5 years ago
|
||
(In reply to :Harald Kirschner :digitarald from comment #3)
Following the steps in comment #0 on current beta (67), I get stuck at step 6 because repeating the steps always loads the non-pretty-printed version of the script, so I can't even see the event listener I want to debug.
This works for me. It even jumps to the right event listener. Breakpoints also worked, including Logpoints.
On beta or on nightly?
|
|
Reporter | |
Comment 6•5 years ago
|
||
(In reply to :Harald Kirschner :digitarald from comment #5)
Nightly.
On Nightly, for me the line in question gets hit for mousemove events, but not for click events, and although the "Paused on breakpoint" warning shows up, the line is sometimes not highlighted. I haven't been able to figure out a pattern for when this does and doesn't happen.
Do you want me to file a separate bug for pretty print and "go to this event listener in the debugger" not working properly on beta? Are you aware of a separate bug already on file, and/or are we OK shipping that regression to beta?
|
|
||
Comment 7•5 years ago
|
||
Do you want me to file a separate bug for pretty print and "go to this event listener in the debugger" not working properly on beta? Are you aware of a separate bug already on file, and/or are we OK shipping that regression to beta?
This long-standing issue should be tracked in bug 1532240, which is why I am thinking about closing this bug as dupe and make sure that bug 1532240 fixes both the position and potentially the highlighting (which does have issues apart from pretty printing, so probably not too related).
|
|
Reporter | |
Updated•5 years ago
|
Description
•