1556120 - Firefox Debugger steps through compiled JavaScript even when sourcemaps are available

Status: RESOLVED INVALID

(DevTools :: Debugger, defect, P2)

Description

[John Karahalis [:openjck]]

Steps to reproduce

1. Clone this repository
2. Run npm install
3. Run npm start
4. Visit http://localhost:1234
5. Set a breakpoint on line 3 of src/main.js, which is the line const firefoxCompany = getFirefoxCompany();
6. Refresh the page
7. Wait for the debugger to pause on line 3
8. Press the step in button twice

Expected result

The debugger jumps to line 2 of get-firefox-company.js, the only line of the getFirefoxCompany function.

Actual result

The debugger jumps to a line in main.[hash].js, the compiled source. Upon successive presses to the step in button, the debugger continues to jump around the compiled source rather than the original source.

Comment 1

[John Karahalis [:openjck]]

For the record, I copied David because we were talking about this earlier, not because I think he introduced the bug or anything. :-)

Comment 2

[John Karahalis [:openjck]]

FYI: My original Expected result was wrong, so I modified the demo and updated comment 0 accordingly. I think the Expected result is now correct. I think this is what the debugger should do.

Comment 3

[Jason Laster [:jlast]]

Honza, could you try to reproduce?

Comment 4

[Jan Honza Odvarko [:Honza] (always need-info? me)]

Thanks for the report, John!

I've been following the STRs in comment #0 and I am seeing an exception when trying to step into the getFirefoxCompany function call.

TypeError: _getFirefoxCompany.getFirefoxCompany is not a functionmain.js:3:23

Do you see that too?
Is that expected in the use case?

Honza

Comment 5

[John Karahalis [:openjck]]

Hm. I'm not seeing that. And that's not the issue that I'm reporting.

On the latest Nightly, I'm still seeing the behavior described in the Actual Results section. After pressing step in twice, the debugger highlights line 47 of main.[hash].js, which is the following:

modules[name][0].call(module.exports, localRequire, module, module.exports, this);

That said, I do see the TypeError you're describing if I stop the development server after setting the breakpoint and then refresh. That's not the bug I'm reporting, but perhaps it is a bug. To see this bug, be sure to keep the development server running the whole time.

Comment 6

[Jan Honza Odvarko [:Honza] (always need-info? me)]

The example works for me if I fix the main.js file as follows:

Original version:

import { getFirefoxCompany } from './get-firefox-company';

const firefoxCompany = getFirefoxCompany();
const firefoxLicense = "MPL";

My fixed version:

import getFirefoxCompany from './get-firefox-company';

const firefoxCompany = getFirefoxCompany();
const firefoxLicense = "MPL";

This is because the get-firefox-company module uses default.

As soon as the main.js file is fixed I can step into the getFirefoxCompany(); function call (ending up at line 2 in get-firefox-company.js).
So, it looks just fine for me.

Btw. my server runs all the time.

Does that make sense?

Honza

Comment 7

[John Karahalis [:openjck]]

That works. Thanks for catching that. I'm surprised I made that mistake.

I've seen the debugger step through compiled code before while working on real projects, but it's possible that it has only happened in situations like this where the bundler runtime is executed.

If I come across some unexpected behavior in the future and can reproduce it with a simple example, I'll open a new bug. Thanks!