1629557 - Add ability to set breakpoints in event listeners from event popup in inspector view

Status: RESOLVED WONTFIX

(DevTools :: Inspector, enhancement)

Description

[Kartikaya Gupta (email:[e-mail])]

When I open the devtools inspector, elements that have event listeners attached have a little "event" badge next to the element. Clicking on that gives a list of event listeners with expando arrows on the left to expand the code of the listener. In this expando view it would be great if clicking in the left gutter would allow setting a breakpoint, because there's often no other way to do it. There's a little "go to debugger" icon but in the case of minified/obfuscated sources it sometimes doesn't go to anything useful.

Comment 1

[Razvan Caliman [:rcaliman]]

Attachment: pretty print source debugger

Thanks for the idea!

While it's good in principle, it adds a lot of complexity stemming from the fact that the expando view isn't really an instance of the Debugger so it can't keep state of set breakpoints or allow for navigation during pause. It would also require 2-way sync between it and the Debugger itself. While it would be nice, it also unlikely we'll get to it anytime soon, so I'll mark it as WONTFIX for now.

If using the icon to jump to the Debugger, there is a way to pretty print the source (see attached screenshot), which would then enable you to set breakpoints and navigate accordingly. Hope this helps.

Comment 2

[Kartikaya Gupta (email:[e-mail])]

(In reply to Razvan Caliman [:rcaliman] from comment #1)

If using the icon to jump to the Debugger, there is a way to pretty print the source (see attached screenshot), which would then enable you to set breakpoints and navigate accordingly. Hope this helps.

Yeah in practice this is kinda useless, on the occasions that it does work. In the specific instance I was looking at here, jumping to the debugger didn't even work because the URL was some webpack:// url that didn't resolve. And previously when I've tried this, after pretty printing the source (if that works, which it doesn't always) I end up with a source file that's thousands of lines long and no line number to use to find the thing I care about.

Comment 3

[Botond Ballo [:botond]]

Looping in a couple of Web Compat folks:

Ksenia, Karl, I imagine you need to put breakpoints in event handlers a lot as part of web compat investigations. Do you have a technique for doing this that avoids the difficulties Kats describes in comment 2? How significant of an improvement would you find the feature described in this bug?

Comment 4

[Karl Dubost💡 :karlcow]

Attachment: pretty-print-source

yes the story is not perfect, there are different techniques and tricks to achieve what we want. There's not one clean story working for everyone.

kats, do you happen to remember which site was specifically failing, a kind of steps to reproduce. Because this is super helpful for the devtools team to fix eventual bugs attached to some specific frameworks.

1. Pretty print helps
2. if pretty print doesn't work (it can be slow), you can try through the ctrl+click on the file name in blue (see screenshot) and have another pretty print
3. multi-file search in debugger to find the exact instance i was looking for before setting the breakpoint
4. using the event breakpoint directly in the debugger
5. using chrome devtools to find the offending line, then go back to the firefox devtools to set the right breakpoints.
6. using something like DITM https://addons.mozilla.org/en-US/firefox/addon/ditm/ to replace the script with a prettified version of my own (through VS Code).

It's not a pretty story indeed, but devtools team improves it at every turn.

Big miss: no pretty print for inline scripts in html files. see Bug 1010150 (essential)

Comment 5

[Kartikaya Gupta (email:[e-mail])]

I reported this as a result of debugging at https://bugzilla.mozilla.org/show_bug.cgi?id=1629101#c2 - so the URL in that bug (https://new.reddit.com/r/firefox/comments/fy1bqf/firefox_75_release_chat/) is where I was seeing the problem.

Comment 6

[Karl Dubost💡 :karlcow]

Attachment: webpack not resolved

so for this specific issue, in debugger in the right panel with event listener breakpoints, i ticked mousewheel and wheel events and tried scrolling.

the devtools bug here is that it gives a

Error while fetching an original source: NetworkError when attempting to fetch resource.
Source URL: webpack:///node_modules/@sentry/browser/esm/helpers.js

which is funny because in the stack trace, all the lines numbers are set so the source is here somewhere.

Also the prettifying is not always good. a kind of half-baked prettified. :)

Comment 7

[Ksenia Berezina [:ksenia]]

I think Karl covered everything, in addition what could help with this particular reddit bug is to turn off source maps in devtools Settings, close and reopen devtools, set a breakpoint for the "wheel" and try to "Step in" until it lands to the app code (file name is not starting with vendors..). This is not ideal and on large sites often time consuming, but works in this case.

Comment 8

[Kartikaya Gupta (email:[e-mail])]

Thanks for the tips, they will certainly come in handy next time I have to do something like this. Hopefully the devtools team can find ways to help with some of these workflows as well.