It would really help if you cold provide some explanation what this does and how to test it. The easier it is to test the quicker it will get merged

As described in #3838, inline JS prevents admins to use a restrictive CSP on their site. So I moved this JS snippet, that controls the height of an iframe, to a file.

@J0WI Thanks for coding this
Can I ask you why you decided not to use this:

JFactory::getApplication()->getDocument()->addScriptDeclaration("
CODE GOES HERE
");

This way there is no need for the 2 extra javascript files, and also no extra request on the rendered file.
The weight is small only 12 lines of code…
You can also see that in my attempt to do the same thing here: #5117

This function would create a <script> element, isn't it? So it prevents you from using CSP without unsafe-inline.
https://developer.mozilla.org/en-US/docs/Web/Security/CSP/CSP_policy_directives#Keywords

@J0WI It will add a <script>***</script> in the head of the document, so CSP should be fine with it!

Nope, referring to spec all <script> elements are blocked, even if they are created in head. Just verified using nginx and Firefox 37.

@J0WI WOW really? Joomla then needs more tweaks to comply with this ????

That would be great! The backed is actually unusable with CSP. D:
JFYI: eval is evil #3837

@J0WI And I proposed few days ago something that uses evil() #5652 ????

@J0WI Just out of curiosity the 'self' will reject the inline scripts from the same source? Documentation is not very clear...

self => allowed only from exact same url/protocol (e.g. https://github.com/* but nothing else, relative paths are allowed)
unsafe-inline => allow creepy inline stuff (e.g. <script> element or javascript: values in href)
unsafe-eval => allow evil eval() stuff

The same restrictions are available for nearly every resource, so inline CSS is also a problem. But you can't do that much damage as with JS.

You may be interested in https://developer.mozilla.org/en-US/docs/Web/Security/CSP/Using_Content_Security_Policy#Examples.3A.C2.A0Common_use_cases

This is the right way

@brianteeman Do you need any additional information from me to merge this? Is it already to late to push this to 3.4?

@J0WI There where some proposals for wrapper by Hannes #5117 (see the last comments). Do you think you can implement these in this PR?

Done.

This still waits for a review/merge

Adding test Instructions.

@zero-24 This needs to be tested also for the module
#test ok here!

Thanks @dgt41 just tested with the component and module works good here. Thanks @J0WI moving to RTC

Thank you @J0WI! Merged with 5e44e0a