1910624 - Cant debug world MAIN extension scripts, show up as <anonymous code>

Status: NEW

(WebExtensions :: Developer Tools, defect, P3)

Description

[citizenr]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/126.0.0.0 Safari/537.36

Steps to reproduce:

https://bugzilla.mozilla.org/show_bug.cgi?id=1736575 is great, no longer have to slowly inject scripts manually.

In manifest.json I inject two scripts into "world": "MAIN". Downside is now I cant debug.

Actual results:

• Both files are invisible in Developer Tools.

I tried putting console.log(1) in first and console.log(2) in second. Those show up in console as
1 <anonymous code>:4:9
2 <anonymous code>:4:9

• In 128 and 129.0b9 clicking on any one of <anonymous code> has a high probability of opening the first one. Closing/re opening files/Developer Tools sometimes works to show second one, but since both are showing up as same <anonymous code> file they override each other.

-cant set breakpoint reliably, setting breakpoint in second file can result in first one being displayed after refresh and no breakpoint firing or firing in random spot corresponding to line number set for the second file.

Expected results:

I should be able to see files injected into "world": "MAIN" in Sources Tab with real or at least distinct names.

Comment 1

[Rob Wu [:robwu]]

The presence of <anonymous code> is intentional and implemented in bug 1900410 to prevent web pages from detecting extension URLs, because the ability to detect extension URLs carries privacy risks (fingerprinting).

The difficulty of debugging is an unfortunate side effect of the implementation. It is not a new problem, it also existed in tabs.executeScript + code (bug 1707107 and bug 1651557). On the devtools side, there is the acknowledgement that the behavior of the debugger with the same source URL is not well-tested, at bug 1747819.

As a work-around, you. could add // #sourceURL=your_custom_name.js to your code to customize the name of the file. This will not only make debugging easier, it will also be visible to the web page itself.

Comment 2

[citizenr]

Thank you
//# sourceURL=functions.js
workaround will have to do

Comment 3

[BugBot [:suhaib / :marco/ :calixte]]

The severity field is not set for this bug.
:rpl, could you have a look please?

For more information, please visit BugBot documentation.

Comment 4

[Alexandre Poirot [:ochameau]]

Attachment: Bug 1910624 - Introduce CompileScriptOptionsDictionary.exposeAnonymousURL to make the script location anonymous to content but not to DevTools.

This helps WebExtension codebase inject world: "MAIN" scripts with an anonymous URL,
so that we never leak the add-on URL to the injected page,
while allowing DevTools to know about the original add-on script URL.

Note that using the existing displayURL would leak the script URL,
at least via exception new Error().stack. So I'm introducing a new attribute
dedicated to DevTools usage.

Comment 5

[Alexandre Poirot [:ochameau]]

Attachment: Bug 1910624 - [devtools] Use original script URL in DevTools, if available.

This helps show the real script URL for world: "MAIN" web extension content scripts.

Comment 6

[Alexandre Poirot [:ochameau]]

Here I'm trying to address the cases where sources have an anonymous URL/filename.
I'm passing the actual script url to devtools via CompileOptions + Debugger.Source's originalURL attribute.
I'm using a new attribute as filename/displayURL are both potentialy leaked to the content page.
I'm not sure I'm covering all the cases by patching only ChromeScriptLoader.compileScript?

I imagine we would need to followup to address the tabs.executeScript which is probably still not having any URL.