Firefox console emits a CSP unsafe-inline warning, but there is no unsafe-inline script

RESOLVED FIXED in Firefox 52

Status

()

defect
P2
normal
RESOLVED FIXED
3 years ago
3 years ago

People

(Reporter: April, Assigned: ckerschb)

Tracking

unspecified
mozilla52
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox52 fixed)

Details

(Whiteboard: [domsecurity-active], )

Attachments

(1 attachment, 2 obsolete attachments)

Reporter

Description

3 years ago
Firefox's console emits this error:

Content Security Policy: The page’s settings blocked the loading of a resource at self (“script-src https://phonebook.mozilla.org”)

It has no line number or any obvious way to track down where it might be coming from.  Neither Chrome nor Safari have any CSP errors, and whatever is happening doesn't seem to be breaking anything at all.
The problem is that the script ["https://phonebook.mozilla.org/js/prototype.js":2771]:

>  var PROBLEMATIC_ATTRIBUTE_READING = (function() {
>    DIV.setAttribute('onclick', []);
>    var value = DIV.getAttribute('onclick');
>    var isFunction = Object.isArray(value);
>    DIV.removeAttribute('onclick');
>    return isFunction;
>  })();

tries to register an onclick() event handler. Since the page has a CSP, our implementation prohibits this registration of an event handler [1] and reports an error message to the console [2].

One thing I don't quite understand is the following, our CSP implementation generates an nsIScriptError [3] with the following values:

> cspMsg: Content Security Policy: The page’s settings blocked the loading of a resource at self (“script-src https://phonebook.mozilla.org”).
> aSourceName: https://phonebook.mozilla.org/
> aSourceLine: onclick attribute on DIV element
> aLineNumber: (null)
> aCategory: CSP

and tries to log it to the console. Even within nsConsoleService::LogMessageWithMode() [4] when I call aMessage->ToString(msg) and then print msg, I see:

> [JavaScript Error: "Content Security Policy: The page’s settings blocked the loading of a resource at self (“script-src https://phonebook.mozilla.org”)." {file: "https://phonebook.mozilla.org/" line: 0 column: 0 source: "onclick attribute on DIV element"}]

but in the browser console we don't get the 'file:' information and also not the 'source: "onclick attribute on DIV element"' which would be really useful. We only see what April reported in comment 0. I tried to trace down the fundamental problem, but I am stuck.

Nathan, any idea what might go wrong and why we don't print that additional information to the browser console?


[1] https://dxr.mozilla.org/mozilla-central/source/dom/events/EventListenerManager.cpp#859
[2] https://dxr.mozilla.org/mozilla-central/source/dom/security/nsCSPContext.cpp#502
[3] https://dxr.mozilla.org/mozilla-central/source/dom/security/nsCSPUtils.cpp#94
[4] https://dxr.mozilla.org/mozilla-central/source/xpcom/base/nsConsoleService.cpp#211



%-----snip----

#3  0x00007fffe879d303 in nsCSPContext::GetAllowsInline (this=0x7fffc0315420, aContentType=2, aNonce=..., aContent=..., aLineNumber=0, 
    outAllowsInline=0x7fffffffa7d3) at /home/ckerschb/moz/mc/dom/security/nsCSPContext.cpp:508
#4  0x00007fffe80f69ed in mozilla::EventListenerManager::SetEventHandler (this=0x7fffc01bfb80, aName=0x7fffd4fcaac0, aBody=..., aDeferCompilation=true, 
    aPermitUntrustedEvents=true, aElement=0x7fffc01bf550) at /home/ckerschb/moz/mc/dom/events/EventListenerManager.cpp:880
#5  0x00007fffe6e07b21 in mozilla::dom::Element::SetEventHandler (this=0x7fffc01bf550, aEventName=0x7fffd4fcaac0, aValue=..., aDefer=true)
    at /home/ckerschb/moz/mc/dom/base/Element.cpp:2214
#6  0x00007fffe82bc393 in nsGenericHTMLElement::AfterSetAttr (this=0x7fffc01bf550, aNamespaceID=0, aName=0x7fffd4fcaac0, aValue=0x7fffffffab70, aNotify=true)
    at /home/ckerschb/moz/mc/dom/html/nsGenericHTMLElement.cpp:649
#7  0x00007fffe6e08be2 in mozilla::dom::Element::SetAttrAndNotify (this=0x7fffc01bf550, aNamespaceID=0, aName=0x7fffd4fcaac0, aPrefix=0x0, aOldValue=..., 
    aParsedValue=..., aModType=2 '\002', aFireMutation=false, aNotify=true, aCallAfterSetAttr=true) at /home/ckerschb/moz/mc/dom/base/Element.cpp:2487
#8  0x00007fffe6e08240 in mozilla::dom::Element::SetAttr (this=0x7fffc01bf550, aNamespaceID=0, aName=0x7fffd4fcaac0, aPrefix=0x0, aValue=..., aNotify=true)
    at /home/ckerschb/moz/mc/dom/base/Element.cpp:2365
#9  0x00007fffe82bd05e in nsGenericHTMLElement::SetAttr (this=0x7fffc01bf550, aNameSpaceID=0, aName=0x7fffd4fcaac0, aPrefix=0x0, aValue=..., aNotify=true)
    at /home/ckerschb/moz/mc/dom/html/nsGenericHTMLElement.cpp:828
#10 0x00007fffe6e241dc in mozilla::dom::Element::SetAttr (this=0x7fffc01bf550, aNameSpaceID=0, aName=0x7fffd4fcaac0, aValue=..., aNotify=true)
    at /home/ckerschb/moz/mc-obj-ff-dbg/dist/include/mozilla/dom/Element.h:482
#11 0x00007fffe6e04bde in mozilla::dom::Element::SetAttribute (this=0x7fffc01bf550, aName=..., aValue=..., aError=...)
    at /home/ckerschb/moz/mc/dom/base/Element.cpp:1243
#12 0x00007fffe7c897cf in mozilla::dom::ElementBinding::setAttribute (cx=0x7fffdbec3000, obj=..., self=0x7fffc01bf550, args=...)
    at /home/ckerschb/moz/mc-obj-ff-dbg/dom/bindings/ElementBinding.cpp:722
#13 0x00007fffe7e916dd in mozilla::dom::GenericBindingMethod (cx=0x7fffdbec3000, argc=2, vp=0x7fffd4f64418)
    at /home/ckerschb/moz/mc/dom/bindings/BindingUtils.cpp:2812
#14 0x00007fffeb4e5d92 in js::CallJSNative (cx=0x7fffdbec3000, native=0x7fffe7e914ad <mozilla::dom::GenericBindingMethod(JSContext*, unsigned int, JS::Value*)>, 
    args=...) at /home/ckerschb/moz/mc/js/src/jscntxtinlines.h:235
#15 0x00007fffeb4ad2e9 in js::InternalCallOrConstruct (cx=0x7fffdbec3000, args=..., construct=js::NO_CONSTRUCT)
    at /home/ckerschb/moz/mc/js/src/vm/Interpreter.cpp:453
#16 0x00007fffeb4ad607 in InternalCall (cx=0x7fffdbec3000, args=...) at /home/ckerschb/moz/mc/js/src/vm/Interpreter.cpp:498
#17 0x00007fffeb4ad631 in js::CallFromStack (cx=0x7fffdbec3000, args=...) at /home/ckerschb/moz/mc/js/src/vm/Interpreter.cpp:504
#18 0x00007fffeb4ba8a7 in Interpret (cx=0x7fffdbec3000, state=...) at /home/ckerschb/moz/mc/js/src/vm/Interpreter.cpp:2881
#19 0x00007fffeb4acf67 in js::RunScript (cx=0x7fffdbec3000, state=...) at /home/ckerschb/moz/mc/js/src/vm/Interpreter.cpp:399
#20 0x00007fffeb4ae341 in js::ExecuteKernel (cx=0x7fffdbec3000, script=..., scopeChainArg=..., newTargetValue=..., evalInFrame=..., result=0x0)
    at /home/ckerschb/moz/mc/js/src/vm/Interpreter.cpp:679
#21 0x00007fffeb4ae60b in js::Execute (cx=0x7fffdbec3000, script=..., scopeChainArg=..., rval=0x0) at /home/ckerschb/moz/mc/js/src/vm/Interpreter.cpp:712
#22 0x00007fffeb2483cb in ExecuteScript (cx=0x7fffdbec3000, scope=..., script=..., rval=0x0) at /home/ckerschb/moz/mc/js/src/jsapi.cpp:4331
#23 0x00007fffeb24860a in ExecuteScript (cx=0x7fffdbec3000, scopeChain=..., scriptArg=..., rval=0x0) at /home/ckerschb/moz/mc/js/src/jsapi.cpp:4350
#24 0x00007fffeb2487ed in JS_ExecuteScript (cx=0x7fffdbec3000, scopeChain=..., scriptArg=...) at /home/ckerschb/moz/mc/js/src/jsapi.cpp:4377
---Type <return> to continue, or q <return> to quit---
#25 0x00007fffe6fc4d06 in nsJSUtils::EvaluateString (aCx=0x7fffdbec3000, aSrcBuf=..., aEvaluationGlobal=..., aCompileOptions=..., aEvaluateOptions=..., 
    aRetValue=..., aOffThreadToken=0x7fffb9d96bd0) at /home/ckerschb/moz/mc/dom/base/nsJSUtils.cpp:201
#26 0x00007fffe6fc50b6 in nsJSUtils::EvaluateString (aCx=0x7fffdbec3000, aSrcBuf=..., aEvaluationGlobal=..., aCompileOptions=..., aOffThreadToken=0x7fffb9d96bd0)
    at /home/ckerschb/moz/mc/dom/base/nsJSUtils.cpp:267
#27 0x00007fffe7001a13 in nsScriptLoader::EvaluateScript (this=0x7fffbd2c2340, aRequest=0x7fffb9d96b80) at /home/ckerschb/moz/mc/dom/base/nsScriptLoader.cpp:2038
#28 0x00007fffe7000a88 in nsScriptLoader::ProcessRequest (this=0x7fffbd2c2340, aRequest=0x7fffb9d96b80) at /home/ckerschb/moz/mc/dom/base/nsScriptLoader.cpp:1836
#29 0x00007fffe6fffd6e in nsScriptLoader::ProcessOffThreadRequest (this=0x7fffbd2c2340, aRequest=0x7fffb9d96b80)
    at /home/ckerschb/moz/mc/dom/base/nsScriptLoader.cpp:1634
#30 0x00007fffe7000044 in (anonymous namespace)::NotifyOffThreadScriptLoadCompletedRunnable::Run (this=0x7fffb31e0df0)
    at /home/ckerschb/moz/mc/dom/base/nsScriptLoader.cpp:1664
#31 0x00007fffe53d6293 in nsThread::ProcessNextEvent (this=0x7ffff6b7b500, aMayWait=true, aResult=0x7fffffffc6bf)
    at /home/ckerschb/moz/mc/xpcom/threads/nsThread.cpp:1058
#32 0x00007fffe543eeed in NS_ProcessNextEvent (aThread=0x7ffff6b7b500, aMayWait=true) at /home/ckerschb/moz/mc/xpcom/glue/nsThreadUtils.cpp:290
#33 0x00007fffe5b95fad in mozilla::ipc::MessagePump::Run (this=0x7fffe1d93040, aDelegate=0x7ffff6b426e0) at /home/ckerschb/moz/mc/ipc/glue/MessagePump.cpp:124
#34 0x00007fffe5b0649b in MessageLoop::RunInternal (this=0x7ffff6b426e0) at /home/ckerschb/moz/mc/ipc/chromium/src/base/message_loop.cc:232
#35 0x00007fffe5b06430 in MessageLoop::RunHandler (this=0x7ffff6b426e0) at /home/ckerschb/moz/mc/ipc/chromium/src/base/message_loop.cc:225
#36 0x00007fffe5b06409 in MessageLoop::Run (this=0x7ffff6b426e0) at /home/ckerschb/moz/mc/ipc/chromium/src/base/message_loop.cc:205
#37 0x00007fffe8e71024 in nsBaseAppShell::Run (this=0x7fffd43162b0) at /home/ckerschb/moz/mc/widget/nsBaseAppShell.cpp:156
#38 0x00007fffe9e218a3 in nsAppStartup::Run (this=0x7fffd4304ba0) at /home/ckerschb/moz/mc/toolkit/components/startup/nsAppStartup.cpp:284
#39 0x00007fffe9ee125c in XREMain::XRE_mainRun (this=0x7fffffffcab0) at /home/ckerschb/moz/mc/toolkit/xre/nsAppRunner.cpp:4302
#40 0x00007fffe9ee17f1 in XREMain::XRE_main (this=0x7fffffffcab0, argc=1, argv=0x7fffffffdea8, aAppData=0x7fffffffccd0)
    at /home/ckerschb/moz/mc/toolkit/xre/nsAppRunner.cpp:4429
#41 0x00007fffe9ee1ac1 in XRE_main (argc=1, argv=0x7fffffffdea8, aAppData=0x7fffffffccd0, aFlags=0) at /home/ckerschb/moz/mc/toolkit/xre/nsAppRunner.cpp:4520
#42 0x0000000000405a71 in do_main (argc=1, argv=0x7fffffffdea8, envp=0x7fffffffdeb8, xreDirectory=0x7ffff6b59780)
    at /home/ckerschb/moz/mc/browser/app/nsBrowserApp.cpp:259
#43 0x0000000000405dd8 in main (argc=1, argv=0x7fffffffdea8, envp=0x7fffffffdeb8) at /home/ckerschb/moz/mc/browser/app/nsBrowserApp.cpp:392
(gdb) print DumpJSStack()
0 PROBLEMATIC_ATTRIBUTE_READING<() ["https://phonebook.mozilla.org/js/prototype.js":2771]
    this = [object Window]
1 anonymous(GLOBAL = [object Window]) ["https://phonebook.mozilla.org/js/prototype.js":2770]
    this = [object Window]
2 <TOP LEVEL> ["https://phonebook.mozilla.org/js/prototype.js":2032]
Flags: needinfo?(nfroyd)
Status: NEW → ASSIGNED
Whiteboard: [domsecurity-active]
Reporter

Comment 2

3 years ago
Removing Mozilla confidential, so I can link into it from Prototype.js and Chromium's bug tracker.
Group: mozilla-employee-confidential
(In reply to Christoph Kerschbaumer [:ckerschb] from comment #1)
> Even within
> nsConsoleService::LogMessageWithMode() [4] when I call
> aMessage->ToString(msg) and then print msg, I see:
> 
> > [JavaScript Error: "Content Security Policy: The page’s settings blocked the loading of a resource at self (“script-src https://phonebook.mozilla.org”)." {file: "https://phonebook.mozilla.org/" line: 0 column: 0 source: "onclick attribute on DIV element"}]
> 
> but in the browser console we don't get the 'file:' information and also not
> the 'source: "onclick attribute on DIV element"' which would be really
> useful. We only see what April reported in comment 0. I tried to trace down
> the fundamental problem, but I am stuck.
> 
> Nathan, any idea what might go wrong and why we don't print that additional
> information to the browser console?

I think what's happening is that we init the script error's message:

http://dxr.mozilla.org/mozilla-central/source/js/xpconnect/src/nsScriptError.cpp#202

and ToString starts with the message, but appends a lot of extra stuff:

http://dxr.mozilla.org/mozilla-central/source/js/xpconnect/src/nsScriptError.cpp#258

so that accounts for what you're seeing in the debugger when you call ToString.  But then in the console service--assuming I'm following this right, I get a little confused about console stuff--we pass the error object off to all the listening nsIConsoleListeners:

http://dxr.mozilla.org/mozilla-central/source/xpcom/base/nsConsoleService.cpp#184

which I think winds up here in devtools:

http://dxr.mozilla.org/mozilla-central/source/devtools/server/actors/utils/webconsole-utils.js#255

which passes things off:

http://dxr.mozilla.org/mozilla-central/source/devtools/server/actors/webconsole.js#1410

and then, since we are an instance of nsIScriptError:

http://dxr.mozilla.org/mozilla-central/source/devtools/server/actors/webconsole.js#1438

and we eventually wind up calling .errorMessage on the error object, not toString:

http://dxr.mozilla.org/mozilla-central/source/devtools/server/actors/webconsole.js#1467

It does look like we gather a lot of extra information in that preparePageErrorForRemote function, though, so it seems like we ought to display it?  Maybe it decides that since the line number and/or column numbers are 0, there's no point in displaying extra information?  Or the source doesn't represent a JS file, so we can't give a useful pointer to the source?
Clearing ni? after bugzilla mid-air.  Christoph, please see comment 3.
Flags: needinfo?(nfroyd)
Reporter

Comment 5

3 years ago
I have filed a bug with the Chromium team; it appears that Firefox is correctly emitting an error upon the event handler being set, as per the CSP specification.  Chromium-based browser are emitting the error upon execution.

This is why we aren't seeing this particular error in the Chrome console: the div node is created outside the DOM and never inserted, so its onclick handler is never executed.  I will be filing a bug with the Prototype team shortly as well.
(In reply to Nathan Froyd [:froydnj] from comment #3)
> Maybe it decides that since the line number and/or column
> numbers are 0, there's no point in displaying extra information?  Or the
> source doesn't represent a JS file, so we can't give a useful pointer to the
> source?

I was thinking about that too, hence I hardcoded the line and column number to see if that has any affect. In the debugger I see:

[JavaScript Error: "Content Security Policy: The page’s settings blocked the loading of a resource at self (“script-src https://phonebook.mozilla.org”)." {file: "https://phonebook.mozilla.org/" line: 22 column: 24 source: "onclick attribute on DIV element"}]

In the console the part about the "onclick attribute on DIV element" is still missing - must be something other than a '0' line number that prevents the additional information from being logged to the console.
Priority: -- → P2
Nathan, I forgot to ask last time (see also comment 6), do we have anyone who could take a look at this problem? Would be nice to log all the info we got to the console. Thanks!
Flags: needinfo?(nfroyd)
(In reply to Christoph Kerschbaumer [:ckerschb] from comment #7)
> Nathan, I forgot to ask last time (see also comment 6), do we have anyone
> who could take a look at this problem? Would be nice to log all the info we
> got to the console. Thanks!

Brian Grinstead and Lin Clark would be the people to call here.
Flags: needinfo?(nfroyd)
Brian, can you have a look at comment 1 and potentially help me fix the console error reporting problem?
Flags: needinfo?(bgrinstead)
(In reply to Christoph Kerschbaumer [:ckerschb] from comment #9)
> Brian, can you have a look at comment 1 and potentially help me fix the
> console error reporting problem?

The steps Nathan outlined in Comment 3 are right - all this information is being sent from the devtools server to the frontend.

We just aren't displaying it on the frontend.  There's a 'reportPageError' function: https://dxr.mozilla.org/mozilla-central/source/devtools/client/webconsole/webconsole.js#1424 that ends up displaying a message where the string is the 'errorMessage'.

The idea I think is that the '{file: "https://phonebook.mozilla.org/" line: 0 column: 0}' information is already within the source link to the right of the error message and adding that would just make the message bigger.  Especially on already long errors like the 'character encoding' error you see when you open: 'data:text/html,'.

Two things I can think of to improve this message:

1) The 'source' field is useful info that we are missing out on now and we could be showing maybe as:
     Content Security Policy: The page’s settings blocked the loading of a resource at self (“script-src https://phonebook.mozilla.org”).  Source: onclick attribute on DIV element.
   To do that we could modify the 'errorMessage' variable to include extra source information at the end of the error message (if it's there).
2) If we set the errorMessageName field on these errors and modified the errordocs actor with a doc link we could have a 'learn more' link show up to point to MDN: https://dxr.mozilla.org/mozilla-central/source/devtools/server/actors/errordocs.js.  Florian (cc'ed) has been working on this for other errors and it could be a nice enhancement.
Flags: needinfo?(bgrinstead)
Freddy, according to Comment 10, the 'source' within an nsIScriptError is ignored when logging to the console, but that 'source' might be really useful to web devs, especially when blocking inline scripts (see detailed comment within the patch).

I suppose there is no need for translation services. The new message looks like:
> Content Security Policy: The page’s settings blocked the loading of a resource at self (“script-src https://phonebook.mozilla.org”). Source: onclick attribute on DIV element.  [phonebook.mozilla.org]
where 'Source' could potentially be subject to translation services, but that would make the coding effort to be substantial. I suppose we can live with no translating 'Source', right?


@Brian: Just making sure this is what you suggested within comment 10, but I suppose it is, right?
Attachment #8782847 - Attachment is obsolete: true
Attachment #8790224 - Flags: review?(fbraun)
Attachment #8790224 - Flags: review?(bgrinstead)
Comment on attachment 8790224 [details] [diff] [review]
bug_1296027_csp_missing_soruce_in_console_message.patch

Review of attachment 8790224 [details] [diff] [review]:
-----------------------------------------------------------------

Not entirely happy with the hardcoded "Source" text.
But r+, if bgrins is OK with it (and assuming you address the consistency issue noted below).

::: dom/security/nsCSPUtils.cpp
@@ +150,5 @@
> +  // information contained within 'aSourceLine' can be really useful for devs.
> +  // E.g. 'aSourceLine' might be: 'onclick attribute on DIV element'.
> +  // In such cases we append 'aSourceLine' directly to the error message.
> +  if (!aSourceLine.IsEmpty()) {
> +    cspMsg.AppendASCII(" Source: ");

This line is using |.AppendAscii("...")|, while the code above does .Append(NS_LITERAL_STRING("..")).

I suggest we try to be consistent here.
Attachment #8790224 - Flags: review?(fbraun) → review+
Depends on: 1255746
Comment on attachment 8790224 [details] [diff] [review]
bug_1296027_csp_missing_soruce_in_console_message.patch

Review of attachment 8790224 [details] [diff] [review]:
-----------------------------------------------------------------

::: dom/security/nsCSPUtils.cpp
@@ +149,5 @@
> +  // For inline violations however, the line and column number are 0 and
> +  // information contained within 'aSourceLine' can be really useful for devs.
> +  // E.g. 'aSourceLine' might be: 'onclick attribute on DIV element'.
> +  // In such cases we append 'aSourceLine' directly to the error message.
> +  if (!aSourceLine.IsEmpty()) {

I believe this sort of textual description should be included in the message argument anyway - I don't think it makes sense in the sourceLine argument: https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XPCOM/Reference/Interface/nsIScriptError#initWithWindowID().

Although looking more closely, as far as I can tell we aren't ever rendering the sourceLine in the frontend anyway (the docs say it should be a line number, but it's treated as a string in the backend and then never rendered in the frontend).  AFAICT there's no reason to use sourceLine when there's the lineNumber param as well.  Going to ni? baku about this, but as far as fixing this particular problem I think your solution looks fine.
Attachment #8790224 - Flags: review?(bgrinstead) → review+
Please make sure to do a try push since the changing messages might cause a test failure.  Also, is aSourceLine only ever used for inline errors or will this cause unnecessary / duplicate info for other types of errors?
(In reply to Brian Grinstead [:bgrins] from comment #13)
> Comment on attachment 8790224 [details] [diff] [review]
> bug_1296027_csp_missing_soruce_in_console_message.patch
> 
> Review of attachment 8790224 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> ::: dom/security/nsCSPUtils.cpp
> @@ +149,5 @@
> > +  // For inline violations however, the line and column number are 0 and
> > +  // information contained within 'aSourceLine' can be really useful for devs.
> > +  // E.g. 'aSourceLine' might be: 'onclick attribute on DIV element'.
> > +  // In such cases we append 'aSourceLine' directly to the error message.
> > +  if (!aSourceLine.IsEmpty()) {
> 
> I believe this sort of textual description should be included in the message
> argument anyway - I don't think it makes sense in the sourceLine argument:
> https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XPCOM/Reference/
> Interface/nsIScriptError#initWithWindowID().
> 
> Although looking more closely, as far as I can tell we aren't ever rendering
> the sourceLine in the frontend anyway (the docs say it should be a line
> number, but it's treated as a string in the backend and then never rendered
> in the frontend).  AFAICT there's no reason to use sourceLine when there's
> the lineNumber param as well.  Going to ni? baku about this, but as far as
> fixing this particular problem I think your solution looks fine.

Hi Andrea, what do you know about nsIScriptErrors?  Looking at the docs I don't understand the distinction between sourceLine and lineNumber, and I also think we aren't doing anything with souceLine at least in the console frontend.
Flags: needinfo?(amarchesini)
Carrying over r+ from bgrins and freddyb.

(In reply to Brian Grinstead [:bgrins] from comment #14)
> Please make sure to do a try push since the changing messages might cause a
> test failure.  Also, is aSourceLine only ever used for inline errors or will
> this cause unnecessary / duplicate info for other types of errors?

Yes, aSourceLine is only used for inline violations. I vaguely remember that we have a test making sure to receive the right message on the console for inline violations, but for some reason I can't find it.

https://treeherder.mozilla.org/#/jobs?repo=try&revision=dc797d5727d0
Attachment #8790224 - Attachment is obsolete: true
Attachment #8791889 - Flags: review+

Comment 17

3 years ago
Pushed by mozilla@christophkerschbaumer.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/cc2cbca41195
CSP: Include 'Source' within error message when logging to the console. r=freddyb,bgrins
Baku, since the merge is coming up, I went ahead and got that landed even before waiting for your ni? to be cleared. If it causes any problems, please feel free to ping me. Also the patch is small enough to be backed out easily, if necessary.
LineNumber is the line number, sourceLine is the content of that line, where the error is, and it's optional (and it seems not really used in our code base).
Flags: needinfo?(amarchesini)

Comment 20

3 years ago
bugherder
https://hg.mozilla.org/mozilla-central/rev/cc2cbca41195
Status: ASSIGNED → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla52
See Also: → 1279894
See Also: → 1267389
(In reply to Brian Grinstead [:bgrins] from comment #10)
> 2) If we set the errorMessageName field on these errors and modified the
> errordocs actor with a doc link we could have a 'learn more' link show up to
> point to MDN:
> https://dxr.mozilla.org/mozilla-central/source/devtools/server/actors/
> errordocs.js.  Florian (cc'ed) has been working on this for other errors and
> it could be a nice enhancement.

Filed bug 1304645 for this.
Duplicate of this bug: 1255746
You need to log in before you can comment on or make changes to this bug.