Closed
Bug 1311424
Opened 8 years ago
Closed 7 years ago
Sourcemap retrieved files in debugger use wrong URL when a hyphen exists in the URL
Categories
(DevTools :: Debugger, defect, P2)
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: drew.town+github, Assigned: tromey)
References
(Blocks 1 open bug)
Details
Attachments
(1 file)
|
(deleted),
application/x-zip-compressed
|
Details |
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
|
||
Comment 1•8 years ago
|
||
@Drew: Can you try this out with the debugger in Nightly? http://nightly.mozilla.org/
Thanks
Flags: needinfo?(drew.town+github)
Priority: -- → P2
@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?(drew.town+github)
|
|
||
Comment 3•8 years ago
|
||
Thanks Drew! This is great.
Can you help me with a sample test case?
// http://server-qa/index.html
<html>
<head>
<script src="http://server-qa/test.js"></script>
</head>
</html>
// http://server-qa/test.js
function test() { debugger; }
test();
//# sourceMappingURL=/test.map
* With this test case the `test.map` file will be loaded from http://server instead of http://server-qa
|
|
||
Comment 4•8 years ago
|
||
I can't seem to reproduce this locally.
I added an alias for my localhost
# /etc/hosts
127.0.0.1 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 /test.map HTTP/1.1" 404 206
::1 - - [11/Jan/2017:12:58:44 +0800] localhost-qa "GET /test.map 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?(drew.town+github)
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?(drew.town+github)
|
|
||
Comment 6•8 years ago
|
||
> 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.
Hello,
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: https://github.com/bgrins/devtools-demos
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.
Thanks.
Up, any people on this issue please ?
We cannot work with less files on Firefox anymore.
Thanks.
|
|
||
Comment 9•8 years ago
|
||
Adding jryans who is working on source maps right now and might know something about this.
Adding this to my tracking bug of various source map issues. I'll try it out soon.
Blocks: source-maps
Flags: needinfo?(jryans)
|
Assignee | |
Comment 12•7 years 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?(drew.town+github)
|
Reporter | |
Comment 13•7 years ago
|
||
For example one of my .map files has the following contents
{"version":3,"file":"Parameters.js","sourceRoot":"","sources":["Parameters.ts"],"names":[],"mappings":"[[[[[snip]]]]]"}
Flags: needinfo?(drew.town+github)
|
|
Assignee | |
Comment 14•7 years 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:
https://bugzilla.mozilla.org/show_bug.cgi?id=1294036#c3
If you have some idea what is different about that case, that would be helpful.
|
|
Assignee | |
Comment 15•7 years ago
|
||
Drew, can you still reproduce this?
Flags: needinfo?(drew.town+github)
|
|
Assignee | |
Comment 16•7 years 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: https://github.com/mozilla/source-map/issues/219
I'll be fixing this there and then importing the fix, perhaps via bug 1401563.
Assignee: nobody → ttromey
Flags: needinfo?(drew.town+github)
|
|
Assignee | |
Comment 17•7 years ago
|
||
Reminder to myself that source-map library changes still need double landing,
because there's a separate bundle in devtools/shared/sourcemap
|
|
Assignee | |
Comment 18•7 years 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.
|
|
Assignee | |
Comment 19•7 years 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.
Status: UNCONFIRMED → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
|
||
Updated•6 years ago
|
Product: Firefox → DevTools
You need to log in
before you can comment on or make changes to this bug.
Description
•