Update: There is a hotfix available for this, see Per’s comment further down.
We noticed a weird problem on one of our test servers in my current project some time ago. For some reason there was a massive output of JavaScript in the EPiServer ActionWindow, in addition to the normal functionality making it impossible to use the file manager. Us not experiencing anything like it on our local developer machines, nor on any of the production / staging servers, made things even more interesting.
The only error that was available in the browser’s error console was a syntax error not really helping; SyntaxError: unterminated string literal – wdoc.write( ‘<script type=”text/javascript”>var NREUMQ=NREUMQ||[];NREUMQ.
After a bit of detective work it turned out that the JavaScript being rendered onto the page was in fact starting in the middle of EPiServer’s OpenSaveAsDialog function, breaking it completely (lines 7-20 below).
Broken JavaScript function OpenSaveAsDialog
function OpenSaveAsDialog(path)
{
var w = window.open('about:blank','saveAsWin', 'width=600,height=500,scrollbars=yes');
wdoc = w.document;
wdoc.open();
wdoc.write('<html><head>');
wdoc.write('<META HTTP-EQUIV="refresh" content=".5; URL=' + path + '">');
wdoc.write('<script type="text/javascript"> var NREUMQ=
NREUMQ||[];NREUMQ.push(["mark","firstbyte",new Date()
.getTime()]); </script></head><body> <script type=
"text/javascript"> if (!NREUMQ.f) {NREUMQ.f=function()
{NREUMQ.push(["load",new Date().getTime()]);var
e=document.createElement("script"); e.type="text/javascript";
e.src=(("http:"===document.location.protocol)?"http:":"https:")
+ "//" + "js-agent.newrelic.com/nr-100.js"; document.body
.appendChild(e);if(NREUMQ.a)NREUMQ.a();};NREUMQ.a=window
.onload;window.onload=NREUMQ.f;};NREUMQ.push(["nrfj",
"beacon-2.newrelic.com","eac2da8b09","2198192",
"ZgBaYEZUXURZU0ReXF9KeWdkGkZeF1NdRBxUAVFAG1RQQ1FfXkBaXwFXQxpUQEdA"
,2,45,new Date().getTime(),"95166E75FE9E690A","","","",""]);
</script></body>');
wdoc.close();
}
This JavaScript is located in EPiServer’s DhtmlSupport.ascx user control (\EPiServer\CMS\6.1.379.0\Application\UI\CMS\Hosting\DhtmlSupport.ascx) quite a bit down, and it should definently not look like above; which of course it did not. Not in the EPiServer installation that is. The faulty JavaScript was being injected in the middle of EPiServer’s code for some reason, and the script pointed to our New Relic installation.
According to New Relic’s Troubleshooting real user monitoring page, it injects two JavaScripts into the page; one at the very top really close to the header, and one at the very bottom near the end of the page. Having another look at EPiServer’s OpenSaveAsDialog function, the real one from the DhtmlSupport.ascx file, gives us a clue to what might have gone wrong.
DhtmlSupport.ascx
function OpenSaveAsDialog(path)
{
var w = window.open('about:blank','saveAsWin', 'width=600,height=500,scrollbars=yes');
wdoc = w.document;
wdoc.open();
wdoc.write( '<html><head>' );
wdoc.write( '<META HTTP-EQUIV="refresh" content=".5; URL=' + path + '">' );
wdoc.write( '</head><body></body>' );
wdoc.close();
}
As you can see, this OpenSaveAsDialog contains everything that we could possible wish for when about to inject the scripts. A rather likely guess is that the New Relic software finds the head and body tags in the above snippet, and uses them to locate the points of insertion instead of the real ones even though these are inside EPiServer’s JavaScript.
Luckily for us, we had no need for the Real User Monitoring in our testing environment, so we solved this issue by simply uninstalling the agent.
Hi!
I think that there is a hotfix available for this. At least I know that we have made and applied a fix for our hosting.
Hi Linus!
I see, thanks for the information :) I also submitted a support ticket to New Relic in case they’d want to have a look at it, but they haven’t gotten back to me about it yet.
Hi
Great post, there is a hotfix available or you can easily implement it on your own. In the file DhtmlSupport.ascx as mentioned above, find the following part:
Change it to:
Then empty Temporary ASP.Net Files and you should be good to go.
Thanks for the fix Per! I’ve updated the post with a reference to your comment.
Per,
Where I can get this hotfix?
I also run into problems with New Relic’s Real User Monitoring Script but with a total corruption of the output.
This can happen when you use an output filter (like RequestReduce does in our case).
The solution is to turn it off and insert scripts manually where you want them:
https://docs.newrelic.com/docs/dotnet/real-user-monitoring-in-net#manual_instrumentation