User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/92.0.4515.131 Safari/537.36

Steps to reproduce:

1. Create an HTML file with an embedded <script type="module">
2. Open the developer tools and set a breakpoint following some variables assignments in the script
3. Reload the page
4. When the debugger hits the breakpoint, hover over variables to see their value in a tooltip

Actual results:

When <script type="module">, no tooltip is displayed. (Note that the Scopes pane is still able to show the values correctly.)

Expected results:

A tooltip showing the variable's value should have been displayed. When the same code is embedded as just <script> (without type="module") the tooltips display correctly.

The Bugbug bot thinks this bug should belong to the 'Core::JavaScript Engine' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Thanks for reporting! I can reproduce this.

Adding another STR

1. Go to https://absorbed-tree-consonant.glitch.me/
2. Open the debugger
3. In the sources tree, select the (index) file
4. Set breakpoints on line 24 (in function foo) and 31 (in function bar)
5. Refresh the page
6. After break point on line 24 is hit, hover over val1
7. A tooltip with 3 should be displayed.
8. Click resume
9. After break point on line 31 is hit, hover over val2.

AR
No tooltip is displayed

ER

A tooltip with 4 should be displayed.

This most likely comes from the parse-script-tags npm package that we pull from here:
https://searchfox.org/mozilla-central/rev/59f0bf3c13dd455d9f5415b89178de701ea6b850/devtools/client/debugger/package.json#27

Over there:
https://searchfox.org/mozilla-central/rev/59f0bf3c13dd455d9f5415b89178de701ea6b850/devtools/client/debugger/src/workers/parser/utils/ast.js#149

  ast = parseScriptTags(source.text, htmlParser) || {};

htmlParser is called for regular script tags, and isn't for module script tags.

I suspect that this npm package doesn't support the later.

Two useful test pages:
data:text/html,<script type="module">%0Abar(4);%0Afunction bar(val2) {%0Aconsole.log(val2%0A)}%0Aexport default bar;%0A</script>
data:text/html,<script>%0Abar(4);%0Afunction bar(val2) {%0Aconsole.log(val2%0A)}%0A</script>

We should probably:

• land this npm package in tree, in debugger/packages folder
• review why we forked (diff against upstream)
• investigate why it doesn't support type="module".

Oh! That probably comes from this code:
https://github.com/loganfsmyth/parse-script-tags/blob/master/customParse.js#L39-L42

Depends on D182665

https://hg.mozilla.org/mozilla-central/rev/f15cc86278f2
https://hg.mozilla.org/mozilla-central/rev/b0453b60b7d7

== Change summary for alert #39041 (as of Tue, 18 Jul 2023 00:03:34 GMT) ==

Improvements:

For up to date results, see: https://treeherder.mozilla.org/perfherder/alerts?id=39041

Reproducible on a 2023-07-13 Nightly build on Windows 10.
Verified as fixed on Firefox 117.0b5(build ID: 20230808215502) and Nightly 118.0a1(build ID: 20230809213044) on Windows 10, macOS 12. Ubuntu 22.