Sourcemap retrieved files in debugger use wrong URL when a hyphen exists in the URL



2 years ago
10 days ago


(Reporter: Drew, Assigned: tromey)


(Blocks: 1 bug)

49 Branch

Firefox Tracking Flags

(Not tracked)



(1 attachment)

1.91 KB, application/x-zip-compressed


2 years ago
User Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:49.0) Gecko/20100101 Firefox/49.0
Build ID: 20160922113459

Steps to reproduce:

We have 2 environments. QA on "server-qa" using a DNS alias and the production server on server "server" using another DNS alias.

These are internal only DNS aliases pointing to 2 separate IIS instances hosted on separate servers.

Actual results:

The js debugger seems to be truncating the host URL after a hyphen (-) and returns the source files from the main production site when viewing the debugger information for the QA site.

Expected results:

To further test this I created a new alias "serverqa" that points to the same host as "server-qa" and the debugger loaded the correct sourcemap files.

I would expect when browsing to server-qa that it would load the sourcemap files from the correct URL


2 years ago
Component: Untriaged → Developer Tools: Debugger
@Drew: Can you try this out with the debugger in Nightly?

Flags: needinfo?(
Priority: -- → P2

Comment 2

2 years ago
@Bryan Clark I just downloaded the nightly version and I am seeing the exact same behavior.  The dev tools are going to http://server to unminify the js files even though http://server-qa uses a relative sourcemap of "//# sourceMappingURL=/bundles/jquerymap"

So the debugger will show the minified js file from the qa site but the source mapped files from the production site.
Flags: needinfo?(
Thanks Drew!  This is great.  

Can you help me with a sample test case?

// http://server-qa/index.html
<script src="http://server-qa/test.js"></script>

// http://server-qa/test.js
function test() { debugger; }
//# sourceMappingURL=/

* With this test case the `` file will be loaded from http://server instead of http://server-qa
I can't seem to reproduce this locally.

I added an alias for my localhost

# /etc/hosts	localhost localhost-qa

And I loaded that test case in `localhost-qa` but according to the apache logs I'm seeing requests to `localhost-qa` as expected.

Here are my logs:
::1 - - [11/Jan/2017:12:58:44 +0800] "GET / HTTP/1.1" 404 206
::1 - - [11/Jan/2017:12:58:44 +0800] localhost-qa "GET / HTTP/1.1" 404 206 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:53.0) Gecko/20100101 Firefox/53.0"
Flags: needinfo?(

Comment 5

2 years ago
The mapping file does go to the correct URL like you are describing but when it tries to utilize the source files that is when it is going to the non-qa site.

2017-01-11 12:57:15 *.*.*.150 GET /bundles/jquerymap - 80 - [truncated] Mozilla/5.0+(Windows+NT+10.0;+WOW64;+rv:50.0)+Gecko/20100101+Firefox/50.0 - 200 0 0 158

So then when I open the debugger and look under sources I see some non-mapped sources appearing in http://server-qa section and all of the mapped files appear under http://server.  Now if I click on common.js I see it hit the http://server IIS logs

2017-01-11 13:03:57 *.*.*.11 GET /Scripts/common.js - 80 [truncated] Mozilla/5.0+(Windows+NT+10.0;+WOW64;+rv:50.0)+Gecko/20100101+Firefox/50.0 - 200 0 0 147

It appears whatever is doing the translation of the compressed minified file to the original source files is what is utilizing the wrong url.
Flags: needinfo?(
> but when it tries to utilize the source files that is when it is going to the non-qa site.

Ok, I've setup that scenario now but I still can't reproduce this behavior.  ¯\_(ツ)_/¯

If you can create something reproducible I can look into this further.  Feel free to email me directly, you don't have to post things into the bug if they are private.

Comment 7

a year ago
Created attachment 8837351 [details]


I got exactly the same problem.

To reproduce it:
unzip the following file localy in a document root of a domain with hyphen (ex: www.mynamed-domain.local), and open http://www.mynamed-domain.local/sourcemap.html.

Firefox complain about www.mynamed/... (message in red) and don't resolve the map. Chrome works ok.
This test case is taked from:
I changed in the map file, the url is absolute instead of relative (../). Problem occurs only with absolute it seems (so begining with /). [see inside the sourcemap\sourcemap-css directory please and compare the two file if needed]

Actually we cannot use firefox tools because of this bug.I hope it will be fastly corrected as my team like firefox ;) Thanks a lot for your work on it.


Comment 8

a year ago
Up, any people on this issue please ?
We cannot work with less files on Firefox anymore.
Adding jryans who is working on source maps right now and might know something about this.
Meant to NI jryans about this.
Flags: needinfo?(jryans)
Adding this to my tracking bug of various source map issues.  I'll try it out soon.
Blocks: 1339970
Flags: needinfo?(jryans)

Comment 12

a year ago
With the zip file I see the same problem whether or not the host has a "-".
I think it's the absolute URL bug.

I wonder whether the original bug is also this?
I think just seeing the value of the 'sources' property in the .map file would be enough.
Flags: needinfo?(

Comment 13

a year ago
For example one of my .map files has the following contents

Flags: needinfo?(

Comment 14

a year ago
> With the zip file I see the same problem whether or not the host has a "-".

Trying again I can't seem to reproduce the failure at all.
I see the correct source in the style editor every time, and my server reports
that the devtools are asking for the correct URLs.

I also tried a typescript test over here:

If you have some idea what is different about that case, that would be helpful.

Comment 15

9 months ago
Drew, can you still reproduce this?
Flags: needinfo?(

Comment 16

9 months ago
I don't know why I could never reproduce this, but I found an open upstream source-map bug that
shows exactly the bad behavior:
I'll be fixing this there and then importing the fix, perhaps via bug 1401563.
Assignee: nobody → ttromey
Flags: needinfo?(

Comment 17

9 months ago
Reminder to myself that source-map library changes still need double landing,
because there's a separate bundle in devtools/shared/sourcemap

Comment 18

8 months ago
I think this was fixed upstream, and then the fix landed in one of the bundle drops.
It would still be nice to get confirmation.

Comment 19

4 months ago
It's been 5 months with no activity, and I'm reasonably sure this was fixed
by the source-map patch mentioned in comment #16.
Last Resolved: 4 months ago
Resolution: --- → FIXED


10 days ago
Product: Firefox → DevTools
You need to log in before you can comment on or make changes to this bug.