Show error message when script execution is blocked because of wrong MIME type in the web console

RESOLVED FIXED in Firefox 66

Status

()

defect
P2
normal
RESOLVED FIXED
9 months ago
7 months ago

People

(Reporter: sebo, Assigned: evilpie)

Tracking

(Blocks 1 bug)

Trunk
mozilla66
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox65 wontfix, firefox66 fixed)

Details

(Whiteboard: [domsecurity-active], )

Attachments

(1 attachment, 2 obsolete attachments)

When the script execution is blocked because a script is served with the wrong MIME type, you get the following error:

Loading failed for the <script> with source “...”.

This message doesn't explain the reason for this, though, or how this can be fixed.
Here's a test case: http://zartner.bplaced.net/test/bug1510241.html

FWIW, the Chrome DevTools are more informative in this case saying this:

> Refused to execute script from 'http://zartner.bplaced.net/test/bug1510241.php' because its MIME type ('text/plain') is not executable, and strict MIME type checking is enabled.

Sebastian
Component: JavaScript Engine → DOM: Security
You should look in the browser console, for some reason this message doesn't show up in the web console.
No longer blocks: jserror
I noticed the same issue in bug 1510223.
Blocks: 1333995
Thanks for the extremely fast answer, Tom! Looks like a duplicate of bug 1510223 then, or doesn't that cover exposing the message to the Web Console?

Sebastian
Flags: needinfo?(evilpies)
I am going use this bug to make us display the error in the web console.
Assignee: nobody → evilpies
Flags: needinfo?(evilpies)
Blocks: 1510223
Summary: Improve error message when script execution is blocked because of wrong MIME type → Show error message when script execution is blocked because of wrong MIME type in the web console
Posted patch Not working patch (obsolete) — Splinter Review
I thought just using the InnerWindowId instead of GetLoadingDocument, which is null here, would be enough. Sadly it still doesn't work. I think there might be some problem with retrieving the outerWindowID from the ScriptError instance?
Actually the outerWindowID doesn't seems to be even accessed for my ScriptError. I suspect this is a devtools problem somewhere.
So the most likely explanation is that the code for this runs in the parent process, but we need the error in the child. I am not sure if the devtools code is prepared to handle this. Brian already did some digging into this yesterday.
Flags: needinfo?(bgrinstead)
Apparently we have nsHttpChannel::AddSecurityMessage and nsHttpChannel::LogBlockedCORSRequest, which send other errors from the parent to the child. So we can probably do something similar for this error. A general solution involving the devtools would still be useful.
And(In reply to Tom Schuster [:evilpie] from comment #9)
> Apparently we have nsHttpChannel::AddSecurityMessage and
> nsHttpChannel::LogBlockedCORSRequest, which send other errors from the
> parent to the child. So we can probably do something similar for this error.
> A general solution involving the devtools would still be useful.

I seem to remember we have a mechanism in devtools for sending network request information down to the content process actors (for either network messages in the console, in the netmonitor, or both). Maybe something like that could be expanded to work for console messages as well, if needed. I can't find it right now though - Honza, do you know about this?
Flags: needinfo?(bgrinstead) → needinfo?(odvarko)
Attachment #9028296 - Attachment is obsolete: true
This is based on LogBlockedCORSRequest. I think it would useful for https://searchfox.org/mozilla-central/rev/9abd7f512c9b29071776e7ba3f991d5b5fd59ff6/netwerk/protocol/http/nsHttpChannel.cpp#1253-1266 and bug 1510223 to actually make the parameter array that we pass to nsContentUtils::ReportToConsole come over IPC as well.
Status: NEW → ASSIGNED
Priority: -- → P2
Whiteboard: [domsecurity-active]
Attachment #9030156 - Attachment is obsolete: true
Pushed by evilpies@gmail.com:
https://hg.mozilla.org/integration/autoland/rev/28a22fe89004
Proxy HttpChannel MIME blocking message to the child process. r=flod,dragana
https://hg.mozilla.org/mozilla-central/rev/28a22fe89004
Status: ASSIGNED → RESOLVED
Closed: 8 months ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla66
Flags: needinfo?(odvarko)
You need to log in before you can comment on or make changes to this bug.