hello

Obscenity...........

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

for more information visit the below link:

https://bugzilla.mozilla.org/show_bug.cgi?id=1296027

tell me its help.

thank you!

That's quite a quick response, I also submitted an actual bug report as well since this seems to be the community sourced support section.

From what I can understand about what you are saying, the behavior is expected, but the response given is not?

EDIT: Ah crap, it's a bot.

I only see one screenshot, from Chrome. Could you provide a fuller picture of the problem?

In case the inline script message is related to a change to the page made by an extension or user script, you might consider testing in Firefox's Safe Mode. In its Safe Mode, Firefox temporarily deactivates extensions, hardware acceleration, any userChrome.css/userContent.css files, and some other advanced features to help you assess whether these are causing the problem.

If Firefox is not running: Hold down the Shift key when starting Firefox. (On Mac, hold down the option/alt key instead of the Shift key.)

If Firefox is running: You can restart Firefox in Safe Mode using either:

• "3-bar" menu button > "?" Help button > Restart with Add-ons Disabled
• (menu bar) Help menu > Restart with Add-ons Disabled

and OK the restart.

Both scenarios: A small dialog should appear. Click "Start in Safe Mode" (not Refresh).

Any change in the way your site runs?

Oops, I see now, the attached screenshots are very narrow so I missed the first target.

Is there any reason for jQuery to be injecting script into the page? If you compare in Chrome, can you find any injected (inline) scripts added to the DOM?

I only see one screenshot, from Chrome. Could you provide a fuller picture of the problem? .... Any change in the way your site runs?

can you not see them all? 2 are white, all of them are small on my screen.

Hopefully it lets me show you the links it takes me to: https://user-media-prod-cdn.itsre-sumo.mozilla.net/uploads/images/2020-07-11-07-56-56-404cf8.png https://user-media-prod-cdn.itsre-sumo.mozilla.net/uploads/images/2020-07-11-07-57-00-c15ebc.png https://user-media-prod-cdn.itsre-sumo.mozilla.net/uploads/images/2020-07-11-07-57-05-38828f.png

... can you find any injected (inline) scripts added to the DOM?

I have no idea if chrome can even show runtime changes.

also the only change to my website, since last checking the CSP works, was changing bootstrap themes, so I hashed those new inline styles and scripts, and they work fine.

Okay, now I'm looking at the third screenshot.

Can you test with a non-minified version of jQuery to see whether that e.setAttribute() call in the third screenshot is creating an onclick event handler on an element? Firefox considers onclick event handler attributes to be a kind of inline script source, regardless of how they are created. https://developer.mozilla.org/docs/Web/HTTP/Headers/Content-Security-Policy/script-src

If that's what jQuery is doing, then I wonder why you don't see the same error in Chrome? Do Chrome and Firefox have a different approach to CSP enforcement for onclick, or does the jQuery library creates event handlers differently in the two browsers?

... Can you test with a non-minified version of jQuery to see whether that e.setAttribute() call in the third screenshot is creating an onclick event handler on an element? ...

Heres a picture of the same section but formatted a bit better.

I'm not very good with debuggers, but I think there is a way to force Firefox to pause on that line so you can see what c is (i.e., is c really onclick) and which e is it being added to. then you could compare the Inspector in Chrome to see whether the attribute is added without incident, or isn't added. But if this code is used for every kind of attribute, that may be a very painful experience having to keep resuming over and over umpteen times.

I suppose you could temporary suspend enforcement of CSP on your Firefox, let the script run to completion, and then check the DOM for any added onclick attributes. Here's where you can find that setting:

(1) In a new tab, type or paste about:config in the address bar and press Enter/Return. Click the button accepting the risk.

(2) In the search box in the page, type or paste csp and pause while the list is filtered

(3) Double-click the security.csp.enable preference to switch the value from true to false -- ONLY FOR TEMPORARY USE, NOT SAFE AS A GENERAL SETTING

More info on about:config: Configuration Editor for Firefox.

Screenshots attached in the question section (.question-attachments) are broken and do not show inline like in a reply (.ans-attachments) and in this case it is hard to notice that there are actually three images attached.
The question creator will see delete X buttons between the images instead of overlaying the images.

The first screenshot shows how it should be displayed with fixed CSS code.

...I suppose you could temporary suspend enforcement of CSP on your Firefox... ...and then check the DOM for any added onclick attributes...

There are no onclick events in any of the sources, the only close matches were `concat` and `Decorative Clicker`

...

Newlines in blockquotes also dont work.

Is the site online so you could share a link to it? Links in posts diverts them to moderation, so don't be alarmed if the post seems to disappear after you submit it.

Is the site online so you could share a link to it? Links in posts diverts them to moderation, so don't be alarmed if the post seems to disappear after you submit it.

Yes its online, but access to it will have to be given per ip, since ill have to allow it through my firewall. It's only me allowed at the moment, so I don't have the whole of china banging on my door 24/7 while I'm still setting up.