New Relic’s Real User Monitoring (RUM) breaks the EPiServer’s File Manager in Edit Mode

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.

EPiServer's edit mode file manager broken by New Relic's JavaScript.

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.

Error Console showing syntax error unterminated string literal caused by New Relic in EPiServer's edit mode file manager.

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 ='about:blank','saveAsWin', 'width=600,height=500,scrollbars=yes');
  wdoc = w.document;;
  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"; 
 + "//" + ""; document.body
,2,45,new Date().getTime(),"95166E75FE9E690A","","","",""]);

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.


function OpenSaveAsDialog(path)
  var w ='about:blank','saveAsWin', 'width=600,height=500,scrollbars=yes');
  wdoc = w.document;;
  wdoc.write( '<html><head>' );
  wdoc.write( '<META HTTP-EQUIV="refresh" content=".5; URL=' + path + '">' );
  wdoc.write( '</head><body></body>' );

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.


  1. Linus Ekström January 17, 2014
    • Mathias Kunto January 17, 2014
  2. Per Nilsson January 17, 2014
    • Mathias Kunto January 17, 2014
    • Pradip April 8, 2015
  3. Fredrik Haglund January 20, 2014

Leave a Reply