1621819 - Pretty-printing and adding breakpoints on a minified file can cause jank on refresh and zombie breakpoints

Status: NEW

(DevTools :: Debugger, defect, P2)

Description

[:Harald Kirschner :digitarald]

https://perfht.ml/3aFkV4e

STR was a local project with livereload, only a few files. Browser had a few extensions installed. No breakpoints were active in the project.

Comment 1

[:Harald Kirschner :digitarald]

Logan, maybe you can help kickstart the root cause analysis. It seems like Brian optimized some of those code paths last year. Do you see anything from the profile where we could improve?

Comment 2

[Logan Smyth [:loganfsmyth]]

@Harald Two questions to validate:

1. Were the breakpoints on this page in an HTML file, or a JS file?
2. Were the breakpoints on this page in minified content?

From the trace, it looks like a lot of the logic causing the jank is because we're processing possible breakpoints on a line that has a very large number of possible breakpoint positions, which would imply minification.

Comment 3

[:Harald Kirschner :digitarald]

Greg, could you help with Logan's questions in comment 2?

Comment 4

[Alexandre Poirot [:ochameau]]

I saw Greg mention that the Debugger wasn't opened.

At first sight, the profile seems to mostly highlight Redux work... but may be bug 1419352 and using this component might help?
https://searchfox.org/mozilla-central/source/devtools/client/shared/components/VisibilityHandler.js#8-13
Console and netmonitor already applied such optimization and it is being tracked in Damp via PanelsInBackground test.

Comment 5

[Greg Tatum [:gregtatum]]

Attachment: Screenshot showing no breakpoints

Comment 6

[Greg Tatum [:gregtatum]]

Ok, I did some more investigation. This seems to be related to Lastpass. At one point in my life I was investigating a perf bug with Lastpass, and I set a breakpoint in onloadwff.js, which is a file with all the code on a single line. This file causes a huge amount of jank anyway just opening it. The debugger was mostly unusable while I had a breakpoint in that file, and I finally managed to get rid of it. However, they still seem to be there.

So here is a potential STR for setting these zombie breakpoints:

• Install Lastpass
• Open Lastpass's content script onloadwff.js in the debugger
• Hit "pretty print source"
• Set some breakpoints in the source
• Then... I'm not sure how to reproduce them not showing up and turning into zombies. Maybe it has to do with pretty printing?

While interacting with onloadwff.js to produce this STR, the breakpoints showed back up in the UI. I'm guessing that each page I visit tries to set these breakpoints on this massive minified file. However, the breakpoints were not showing up in the UI. Interacting with Lastpass's onloadwff.js is truly a performance cliff. Which, I think it's pretty similar to many other minified files that app developers interact with.

Comment 7

[Greg Tatum [:gregtatum]]

Attachment: Screenshot showing zombie breakpoints returning

Comment 8

[Greg Tatum [:gregtatum]]

I removed the breakpoints in the UI by clicking the X, and the breakpoints returned. They are really zombies for me.

Comment 9

[Logan Smyth [:loganfsmyth]]

I was able to reproduce the zombie breakpoint issue. From a quick look, I think what is happening is that when we remove the breakpoint, we remove the breakpoint data object from pendingBreakpoints for the generated location, but there is also an entry for the prettyPrinted location that does not get removed from the pendingBreakpoint list. Then, when the debugger is closed and re-opened, it attempts to re-apply the breakpoint using the pretty-printed location, causing the breakpoint to re-appear.

I haven't looked at the breakpoint logic much in a long while, @jlast do you know if there are any known issues around this, or does this seem like a likely cause?

@digitarald As for the jank, this file is really large, and because it is all on one line, it takes a very long time for us to process the breakpoint data for it. We have some optimizations in place to try to reduce the amount of data we fetch when a file is sourcemapped, which includes pretty-printed files, but that may not apply properly when you refresh the page and we try to apply the breakpoints before we've had time to pretty-print the file again/fetch the sourcemap data.

So to me this sounds like 2 separate bugs, both of which may require a decent amount of exploration to properly address, so we'll need to figure out priorities of these and split them up.

Comment 10

[:Harald Kirschner :digitarald]

… , but that may not apply properly when you refresh the page and we try to apply the breakpoints before we've had time to pretty-print the file again/fetch the sourcemap data.

If pretty print breakpoint handling would work correctly breakpoints are applied to the pretty-printed version that is faster to parse? If so the performance issue is then somewhat related to the inconsistent handling of breakpoints.

Breaking those out into 2 bugs would be great. Logan, since you have a better sense of where the root causes are, could you file them?

Comment 11

[Jason Laster [:jlast]]

Thanks for looking into it logan. I'd be happy to look at how breakpoints are stored in pendingBreakpoints, this is something i'm fairly comfortable with.

Comment 12

[Logan Smyth [:loganfsmyth]]

If pretty print breakpoint handling would work correctly breakpoints are applied to the pretty-printed version that is faster to parse? If so the performance issue is then somewhat related to the inconsistent handling of breakpoints.

Realistically I don't think we can wait for pretty-printing to run before adding breakpoints, so I think the only way to truly address the jank here would be to rework our code to handle ranges, even in the case of generated files. I've filed https://bugzilla.mozilla.org/show_bug.cgi?id=1623549 to address that.

Maybe we can leave this issue open to address the issue of zombie breakpoints on minified files?

Comment 14

[kevinrfleischman]

Wondering if there's been any additional work done on this bug? I don't see many updates in the log here, just some related tickets.

The scripts I'm dealing with at work are very large bundles, so if the issue is a race condition between loading up script files and pretty printing them, then that would likely be exacerbated by the assets i'm dealing with. I run into zombie breakpoints very frequently, many times over the course of a workday. At its worst, I have to frequently completely shut down Firefox and start fresh (if there's an easier known workaround for clearing all breakpoints, I'd love to know).

Sometimes this is rough enough that I have to throw in the towel and switch to Chrome for devtools-heavy work, which is a bummer.

I'd be happy to take a shot at investigating this and trying to work out a fix, but it would be my first contribution here, and I'm not clear on how rough of a bug this would be for a first timer to fix. I'm also not clear on whether this is something that would even really be open to an outsider trying to fix - I don't think I see a corresponding bug on Codetribute https://codetribute.mozilla.org/projects/devtools?project%3DDebugger