sourcemaps not working if map served with X-Content-Type-Options: nosniff

RESOLVED DUPLICATE of bug 1179820

Status

defect
P3
normal
RESOLVED DUPLICATE of bug 1179820
3 years ago
11 months ago

People

(Reporter: schwarz, Assigned: tromey)

Tracking

(Depends on 2 bugs, Blocks 1 bug)

50 Branch
Firefox 57
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

Reporter

Description

3 years ago
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:50.0) Gecko/20100101 Firefox/50.0
Build ID: 20161208153507

Steps to reproduce:

Generated a sass sourcemap file with the help of codekit app.


Actual results:

Locally the developer tools show me the original source (scss) with line number. In a server envirenment the developer tools show me just the css file.


Expected results:

Both – local and server envirenment – show show me the original source (scss)
A browser doesn't understand sass and should only get the css that the server compiles from the sass file.
When you mean server enviroment I guess that you just open the website that "includes" the sass file but the server should deliver only the compiled css file to the browser and therefore firefox can only show the css file.

Did I misunderstand something ?

Updated

3 years ago
Component: Untriaged → Developer Tools: CSS Rules Inspector
Reporter

Comment 2

3 years ago
(In reply to Matthias Versen [:Matti] from comment #1)
> A browser doesn't understand sass and should only get the css that the
> server compiles from the sass file.
> When you mean server enviroment I guess that you just open the website that
> "includes" the sass file but the server should deliver only the compiled css
> file to the browser and therefore firefox can only show the css file.
> 
> Did I misunderstand something ?

You are right. A browser only understands a css-file. Totally agree. But. The css-file was compiled from several scss-files. With the help of a sourcemap i am able to debug my code and get the original source (scss) info of the inspected element. 

When i include the css-file plus the sourcemap on the server firefox only shows the info of the inspected element in the compiled css-file. I am not able to get the original source info (scss). It is working in Chrome, Safari, Opera but not in FireFox. Shall i post a link?
Assignee

Comment 3

3 years ago
(In reply to Matthias Versen [:Matti] from comment #1)

> Did I misunderstand something ?

Yeah -- the devtools have support for "source maps":
https://developer.mozilla.org/en-US/docs/Tools/Debugger/How_to/Use_a_source_map
These let the tools correlate what the browser sees with what the user wrote.

(In reply to Daniel Schwarz from comment #2)

> Shall i post a link?

Yes, please.
Reporter

Comment 4

3 years ago
(In reply to Tom Tromey :tromey from comment #3)
> (In reply to Matthias Versen [:Matti] from comment #1)
> 
> > Did I misunderstand something ?
> 
> Yeah -- the devtools have support for "source maps":
> https://developer.mozilla.org/en-US/docs/Tools/Debugger/How_to/
> Use_a_source_map
> These let the tools correlate what the browser sees with what the user wrote.
> 
> (In reply to Daniel Schwarz from comment #2)
> 
> > Shall i post a link?
> 
> Yes, please.

On this page:
http://www.triografie.de/arbeiten/

the css file is located here:
www.triografie.de/typo3conf/ext/triografie_templates/Resources/Public/styles/css/main.css

and the sourcemap is located here:
www.triografie.de/typo3conf/ext/triografie_templates/Resources/Public/styles/css/main.css.map

When i try to inspect an element all i get is the css file. But when you open that page in Chrome it is working as expected. I get the information from the original (scss) source. What’s wrong? FireFox, my server environment?

Best wishes …
Inspector bug triage (filter on CLIMBING SHOES).
Status: UNCONFIRMED → NEW
Component: Developer Tools: CSS Rules Inspector → Developer Tools: Style Editor
Ever confirmed: true
Priority: -- → P2
We apparently fail to fetch the map file.

> The resource from “http://www.triografie.de/typo3conf/ext/triografie_templates/Resources/Public/styles/css/main.css.map” 
> was blocked due to MIME type mismatch (X-Content-Type-Options: nosniff).

cf: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Content-Type-Options

The X-Content-Type option nosniff prevents us from checking mime types here.

The failing fetch() is probably in _fetchSourceMap in the stylesheets actor:
http://searchfox.org/mozilla-central/rev/30fcf167af036aeddf322de44a2fadd370acfd2f/devtools/server/actors/stylesheets.js#554-594
For reference you can check a basic page using a SASS sourcemap at: http://bgrins.github.io/devtools-demos/inspector/sourcemap

Which works fine with the rule-view of Firefox 50.
Priority: P2 → P3
Summary: SASS Sourcemaps not working in FF 50 → sourcemaps not working if map served with X-Content-Type-Options: nosniff
(In reply to Julian Descottes [:jdescottes] from comment #6)
> We apparently fail to fetch the map file.
> 
> > The resource from “http://www.triografie.de/typo3conf/ext/triografie_templates/Resources/Public/styles/css/main.css.map” 
> > was blocked due to MIME type mismatch (X-Content-Type-Options: nosniff).
> 
> cf:
> https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Content-Type-
> Options
> 
> The X-Content-Type option nosniff prevents us from checking mime types here.
> 
> The failing fetch() is probably in _fetchSourceMap in the stylesheets actor:
> http://searchfox.org/mozilla-central/rev/
> 30fcf167af036aeddf322de44a2fadd370acfd2f/devtools/server/actors/stylesheets.
> js#554-594

I think changing that block to use TYPE_OTHER instead of TYPE_INTERNAL_STYLESHEET when loading the source map would get around this check.  (After all, it's not a stylesheet anyway...)
(In reply to J. Ryan Stinnett [:jryans] (use ni?) from comment #8)
> 
> I think changing that block to use TYPE_OTHER instead of
> TYPE_INTERNAL_STYLESHEET when loading the source map would get around this
> check.  (After all, it's not a stylesheet anyway...)

Great call! This does fix the initial sourcemap issue. After trying this out, the underlying .scss file also had the same nosniff option and another fetch call failed ([1]). I had to switch this other fetch call to TYPE_OTHER as well as force useCache: false to get it to 'work'.

[1] http://searchfox.org/mozilla-central/rev/30fcf167af036aeddf322de44a2fadd370acfd2f/devtools/server/actors/stylesheets.js#83-99

Comment 10

2 years ago
Just wanted to add in I think this issue is of fairly high importance because anyone using the rather popular HTML5Boilerplate htaccess file will by default have X-Content-Type-Options "nosniff" enabled. As such I would have figured though more people would be encountering this issue. 

Also if it helps, I do believe this bug cropped up in Firefox 50. I'm fairly certain of this as I've been using the same base htaccess file for quite some time, but only discovered my source maps failing to work for my SCSS once I updated to FF50.
Assignee

Updated

2 years ago
Blocks: source-maps
Assignee

Comment 11

2 years ago
I think this will be automatically fixed once everything is using the client-side service,
as that does a plain XHR.
Depends on: 1314057, 1364992

Comment 12

2 years ago
FWIW, it doesn't make much sense to me that a normal fetch() would trigger this, since a normal fetch() wouldn't have a script-like destination (Fetch Standard terminology). That is, fetch() should be the same as XMLHttpRequest here. Christoph, any idea?
Flags: needinfo?(ckerschb)
Assignee

Comment 13

2 years ago
(In reply to Anne (:annevk) from comment #12)
> FWIW, it doesn't make much sense to me that a normal fetch() would trigger
> this, since a normal fetch() wouldn't have a script-like destination (Fetch
> Standard terminology). That is, fetch() should be the same as XMLHttpRequest
> here. Christoph, any idea?

The code in question isn't using a normal fetch yet.
Instead the stylesheets actor gets the map here:

https://dxr.mozilla.org/mozilla-central/rev/93dd2e456c0ecca00fb4d28744e88078a77deaf7/devtools/server/actors/stylesheets.js#565

... which says "fetch" but is actually calling:

https://dxr.mozilla.org/mozilla-central/rev/93dd2e456c0ecca00fb4d28744e88078a77deaf7/devtools/shared/DevToolsUtils.js#433

which calls NetUtil.fetch.

Anyway the issue is probably that stylesheets.js is using TYPE_INTERNAL_STYLESHEET, per comment #8.

However, we're moving all this code to the client side, and there we are using the ordinary fetch,
and so don't anticipate a problem.  That said, changing the inspector to use the client-side service
is proving to be tricky, so maybe an interim fix for this would be alright.
(In reply to Tom Tromey :tromey from comment #13)
> Anyway the issue is probably that stylesheets.js is using
> TYPE_INTERNAL_STYLESHEET, per comment #8.

Yes, that's definitely the issue here. It's confusing that stylesheets.js is not only loading stylesheets. If one of the peers is fine with changing the content type, then I am fine with that as well. Using TYPE_OTHER will definitely bypass the nosniff checks and will allow the load.
Flags: needinfo?(ckerschb)
Assignee

Comment 15

2 years ago
(In reply to Christoph Kerschbaumer [:ckerschb] from comment #14)
> (In reply to Tom Tromey :tromey from comment #13)
> > Anyway the issue is probably that stylesheets.js is using
> > TYPE_INTERNAL_STYLESHEET, per comment #8.
> 
> Yes, that's definitely the issue here. It's confusing that stylesheets.js is
> not only loading stylesheets. If one of the peers is fine with changing the
> content type, then I am fine with that as well. Using TYPE_OTHER will
> definitely bypass the nosniff checks and will allow the load.

If you feel like doing it, I can review it.
Otherwise I think I will probably deprioritize this for a while and see if I can
land client-side source maps for the inspector instead.
Assignee

Updated

2 years ago
Duplicate of this bug: 1399570
Assignee

Comment 17

2 years ago
Changing my mind about this.
Client-side maps for the inspector are being tricky and it's better to
ship something working now than wait, especially because the bug is
diagnosed and the fix is simple.
Assignee: nobody → ttromey
Comment hidden (mozreview-request)

Comment 19

2 years ago
mozreview-review
Comment on attachment 8907775 [details]
Bug 1330383 - fetch original style sheet text using TYPE_OTHER;

https://reviewboard.mozilla.org/r/179452/#review184638
Attachment #8907775 - Flags: review?(gl) → review+

Comment 20

2 years ago
Pushed by ttromey@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/90bdf871a8d1
fetch original style sheet text using TYPE_OTHER; r=gl
https://hg.mozilla.org/mozilla-central/rev/90bdf871a8d1
Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 57
Reporter

Comment 22

Last year
unfortunately this bug is not solved or was re-introduced with FF Quantum.

When setting »Header set X-Content-Type-Options "nosniff"« all i get is the CSS-information. But when i turn »Header set X-Content-Type-Options "nosniff"« off the inspector shows me the .scss-information. 

Is it just me? Can someone confirm my behaviour?
Reporter

Comment 23

Last year
unfortunately this bug is not solved or was re-introduced with FF Quantum.

When setting »Header set X-Content-Type-Options "nosniff"« all i get is the CSS-information. But when i turn »Header set X-Content-Type-Options "nosniff"« off the inspector shows me the .scss-information. 

Is it just me? Can someone confirm my behaviour?
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Assignee

Comment 24

Last year
Can you look in the browser toolbox to see what is happening with the source map requests?
Flags: needinfo?(schwarz)
Reporter

Comment 25

Last year
(In reply to Tom Tromey :tromey from comment #24)
> Can you look in the browser toolbox to see what is happening with the source
> map requests?

I don’t know what to do. What shall i do? Do you need a refernce URL?
Flags: needinfo?(schwarz)
Assignee

Comment 26

Last year
A reference URL would help.

Or, follow these directions to get to the browser toolbox:
https://developer.mozilla.org/en-US/docs/Tools/Browser_Toolbox

Then go to the network monitor there -- that one monitors all requests,
not just the ones for your page.  Finally, do the failing operation
and see what shows up.

Comment 27

Last year
Just thought I'd confirm that indeed this bug still exists / has returned. 

I just did a quick test with enabling/disabling "nosniff" and with it enabled, my CSS sourcemap points only to my main.css file. A quick edit to my htaccess file to disable "nosniff" and all is good again, I see the source CSS files.
Reporter

Comment 28

Last year
So i am not the only one facing this issue. :-) Here’s a reference URL:
http://www.triografie.de/arbeiten/

Thanks for helping.
Daniel
I believe this would be a good idea to file a separate bug, it makes things easier to track.
The fix was missing an update to _fetchSourceMap, which was still fetching sourcemaps with TYPE_INTERNAL_STYLESHEET. So this was not completely fixed in 57. Source maps are now fetched differently starting with Firefox 58, and the bug no longer occurs.

Firefox 58 is supposed to be released tomorrow (but you can preview it using Beta today). Can you check and report if the issue is fixed in version 58?
Flags: needinfo?(schwarz)
Logged Bug 1432122 to catch regressions linked to nosniff for the map file.
Sourcemap handling was removed from the stylesheets actor in Bug 1179820, you can dupe this one on it if Daniel confirms 58 fixes the issue.
See Also: → 1179820
Reporter

Comment 33

Last year
Hi Julian, i can confirm FF 58 fixes the issue described above. Sourcemap (SASS/SCSS) handling is working again.
Flags: needinfo?(schwarz)
Great, thanks for checking! Closing as dupe of 1179820.
Status: REOPENED → RESOLVED
Closed: 2 years agoLast year
Resolution: --- → DUPLICATE
Duplicate of bug: 1179820

Updated

Last year
Product: Firefox → DevTools

Updated

11 months ago
You need to log in before you can comment on or make changes to this bug.