47 bytes, text/x-phabricator-request
|Details | Review|
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
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.
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
I am going use this bug to make us display the error in the web console.
Assignee: nobody → evilpies
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
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.
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
Attachment #9030156 - Attachment is obsolete: true
Pushed by firstname.lastname@example.org: https://hg.mozilla.org/integration/autoland/rev/28a22fe89004 Proxy HttpChannel MIME blocking message to the child process. r=flod,dragana
You need to log in before you can comment on or make changes to this bug.