Summary: | Can't put a breakpoint inside minified script in the main resource | ||
---|---|---|---|
Product: | WebKit | Reporter: | Simon Fraser (smfr) <simon.fraser> |
Component: | Web Inspector | Assignee: | Nobody <webkit-unassigned> |
Status: | NEW --- | ||
Severity: | Normal | CC: | inspector-bugzilla-changes, joepeck, simon.fraser, webkit-bug-importer |
Priority: | P2 | Keywords: | InRadar |
Version: | WebKit Local Build | ||
Hardware: | Unspecified | ||
OS: | Unspecified |
Description
Simon Fraser (smfr)
2017-01-06 14:41:24 PST
^unminified Possible solutions: 1. Preferred: Pretty Print HTML content 2. Half Way: Pretty Print at least <script> in HTML content 3. Always Useful: Right Click + Set Breakpoint at Exact Location I'm sure we have other bugs for (1). But I'd like to use this for (3) which should be pretty easy to do and has applicability even with Pretty Printed code! For example if you wanted to set a breakpoint inside of something that is not broken up across multiple lines even when pretty printed. Here is an arbitrary examples off the top of my head, deciding to pause inside of a default argument expression. function add(a, b = (() => |x + b))() { ... } This is a rather weird case that would be hard to pause in otherwise (you'd have to pause at the caller of add and step to get into it otherwise. I don't think I would have discovered 3). Also it would be super hard to step through minified JS, so I'm not sure it makes sense to allow breakpoints in the middle of a long line. (In reply to comment #4) > Also it would be super hard to step through minified JS, so I'm not sure it > makes sense to allow breakpoints in the middle of a long line. Stepping through minified JS should be much better now that we highlight exactly what expression / statement is about to execute. If we have issues there I can address them as well. |