1954215 - sourceMappingUrl does not seem to follow 302 (sourcemap URL should be constructed from URL after the redirect)

Status: RESOLVED DUPLICATE of bug 1823809

(DevTools :: Debugger, defect, P3)

Description

[William Li]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:135.0) Gecko/20100101 Firefox/135.0

Steps to reproduce:

Visited a website that uses "https://unpkg.com/popper.js@1" with the inspector open.

Actual results:

Firefox warning:

Source map error: request failed with status 404
Resource URL: https://unpkg.com/popper.js@1
Source Map URL: popper.min.js.map

Expected results:

https://unpkg.com/popper.js@1 returned a HTTP 302 that links to https://unpkg.com/popper.js@1.16.1/dist/umd/popper.min.js. Trying to resolve the source map url from there would've been successful.

Comment 1

[Iain Ireland [:iain]]

Redirecting to DevTools.

Comment 2

[Nicolas Chevobbe [:nchevobbe]]

This works fine to me if I have a page like data:text/html,<meta charset=utf8><script src="https://unpkg.com/popper.js@1.16.1/dist/umd/popper.min.js"></script><h1>Hello

In the Debugger, I can see the original files and access the source map file (view-source:https://unpkg.com/popper.js@1.16.1/dist/umd/popper.min.js.map)

We're not accessing https://unpkg.com/popper.js@1 , but the sourcemap file directly, and doing fetch("https://unpkg.com/popper.js@1.16.1/dist/umd/popper.min.js.map") ends up with a 200, not a 302

The error you're seeing comes from https://searchfox.org/mozilla-release/rev/e21e386e9ba789cebb5ce20d4e6de1ca451615ba/devtools/client/shared/source-map-loader/utils/network-request.js#23-24,27-29,43

const response = await fetch(url, {
  cache: opts.loadFromCache ? "default" : "no-cache",
...
  credentials: "same-origin",
  redirect: opts.allowRedirects ? "follow" : "error",
});
...
throw new Error(`request failed with status ${response.status}`);

This is called from https://searchfox.org/mozilla-release/rev/e21e386e9ba789cebb5ce20d4e6de1ca451615ba/devtools/client/shared/source-map-loader/source-map.js#426-430

const response = await networkRequest(url, {
  sourceMapBaseURL: map.sourceMapBaseURL,
  loadFromCache: false,
  allowsRedirects: false,
});

where we can see that we indeed don't allow redirects (for security reasons)

The question now is why it's working fine for me and not for you.
Do you see the error message with my simple page? If not, could you share a link to the page where you are seeing the issue?

Comment 3

[Nicolas Chevobbe [:nchevobbe]]

This might be a duplicate of Bug 1828376

Comment 4

[William Li]

I believe my current project at work is relying the redirect from https://unpkg.com/popper.js@1 to https://unpkg.com/popper.js@1.16.1/dist/umd/popper.min.js.

Try using the test page
data:text/html,<meta charset=utf8><script src="https://unpkg.com/popper.js@1"></script><h1>Hello

My question is how is map.sourceBaseUrl calculated? So far, I've been speculating that map.sourceBaseUrl is the url in the returned file in relation to the url in the script tag, maybe something like https://unpkg.com/popper.js.min.map. That's how I believe a 404 is happening.

Let me try to reproduce with your test when I have more time later in a few hours.

Comment 5

[Nicolas Chevobbe [:nchevobbe]]

Thanks for the details William

(In reply to William Li from comment #4)

Try using the test page
data:text/html,<meta charset=utf8><script src="https://unpkg.com/popper.js@1"></script><h1>Hello

Ah yes, I do reproduce with this example, thanks!

My question is how is map.sourceBaseUrl calculated? So far, I've been speculating that map.sourceBaseUrl is the url in the returned file in relation to the url in the script tag, maybe something like https://unpkg.com/popper.js.min.map. That's how I believe a 404 is happening.

Yes, you're right, the url we try to fetch is indeed https://unpkg.com/popper.min.js.map , which is a 404 (so that's different than Bug 1828376 I think).