Bug 291140 – Web Inspector: Wrong breakpoint and search result positions after pretty-printing inline script with multi-line template literal

• Component: Web Inspector
• Status: RESOLVED FIXED

[Jeff Johnson]

Created attachment 474838 [details]
Search result pretty-printed

This bug apparently goes back for years, in my testing.

Steps to reproduce:
1) Open https://www.timothyricks.com/lumos-components
2) Open the web inspector
3) Search for execcommand("copy")

If the document is pretty-printed, then the search results highlight the wrong lines. And I can't even set a breakpoint at document.execCommand("Copy") in the pretty-printed document (line 1684). If I disable pretty-printing, then the search results highlight the right line (923), and I can set a breakpoint there. However, if I re-enable pretty-printing, then the breakpoint moves to the wrong place.

See the attached screenshots.

[Jeff Johnson]

Created attachment 474839 [details]
Search result original formatting

[Jeff Johnson]

Created attachment 474840 [details]
Breakpoint original formatting

[Jeff Johnson]

Created attachment 474841 [details]
Breakpoint pretty-printed

[Jeff Johnson]

By the way, pretty-printing inline scripts seems to work fine in Google Chrome.

[Alexey Proskuryakov]

rdar://29417859

[Razvan Caliman]

Took a while to get to the root cause of this. 

It turns out pretty-printing an inline script which has a multi-line JS template literal (aka template string) messes up formatted line offsets for anything following the template literal in the context of the wider HTML page.

This happens because `JSFormatter` appends the template literal as a single token which assumes it goes on a single line:
https://github.com/WebKit/WebKit/blob/6ed6b6a4c121b050e54bedea8db4a811aa6fa323/Source/WebInspectorUI/UserInterface/Workers/Formatter/JSFormatter.js#L868-L873

It's why this issue occurs in the test page for the query `execCommand("copy")` because the first occurrence is after the first multi-line template literal. Searching for something before, like `createCodeEditor` yields correct locations for breakpoints and search results.

This issue happens only in inline scripts because the formatter has to switch modes between HTML and JS and the `JSFormatter` instance adopts the line endings array from the original HTML file. When formatting a standalone script file, a `JSFormatter` uses line endings only from the script source text.

See `HTMLFormatter.prototype._formatWithNestedFormatter()`:
https://github.com/WebKit/WebKit/blob/6ed6b6a4c121b050e54bedea8db4a811aa6fa323/Source/WebInspectorUI/UserInterface/Workers/Formatter/HTMLFormatter.js#L329-L334

[Razvan Caliman]

Pull request: https://github.com/WebKit/WebKit/pull/54549

[Razvan Caliman]

Created attachment 477549 [details]
Reduced test case

Reduced test case from the original web page. Search for "execCommand" in Web Inspector Search tab and pretty print the result.

[Razvan Caliman]

Created attachment 477550 [details]
Test case for unwanted newlines after multi-line template literal

[Razvan Caliman]

Created attachment 477551 [details]
Screen recording of build with patch applied vs original

[EWS]

Committed 303680@main (b21fb0d39d87): <https://commits.webkit.org/303680@main>

Reviewed commits have been landed. Closing PR #54549 and removing active labels.