The process of getting custom JavaScript to work with Minimal Download Strategy is quite cumbersome and especially in the prototyping phase I like to write my (smaller) scripts inline in a Content or Script Editor Webpart. As we all know, this won't be very successful when MDS is activated.

I added a little piece of code to my development environment Masterpage:

    jQuery("#DeltaPlaceHolderMain script.MDSeval")
    .not("div.ms-rtestate-field script.MDSeval")
        //console.debug("Attempting to eval() Script")

As you can see it will look for <script>-tags with class 'MDSeval' in #DeltaPlaceHolderMain and evaluates them, and that's actually working pretty nice. And even though <script>-tags are not allowed in RTE fields, I have another check just to make sure.

Now I'm wondering how this would fare in a production environment. Do you see any major or potential problems with this approach? Are there still ways left a user could use to smuggle in malicious code even though he has no permission to design pages?

  • Something like this: sharepointannoyances.wordpress.com/2014/04/09/… Commented Jun 24, 2016 at 13:30
  • That comment is totally unrelated to my question. Commented Jun 24, 2016 at 15:08
  • I thought you were looking for a better way to check for MDS without having to run an eval, this shows how to check for MDS and act accordingly. Commented Jun 24, 2016 at 15:13
  • No problem whatsoever to run scripts with MDS. But the process (for example as described in the blog post you posted) is what I would call cumbersome. So my question is: instead of going though this process, how about just eval() tiny inline scripts? What are the concerns? Are there any? Are there still ways that users smuggle in malicious code? Not talking about massive scripts here, but those tiny "please make a slideDown animation for this list"-requests. Would be way easier just to be able to do it inline than to add a custom action etc.. Commented Jun 24, 2016 at 18:48
  • Alrighty, I misunderstood what you were getting at. Commented Jun 24, 2016 at 19:01

2 Answers 2


Eval is Evil

Oh My! Then you have to stop using SharePoint; as its code uses eval() in several places:

sp.js uses it once:

   $v_0.MenuItems = eval($p1.get_executor().get_responseData());

core.js ... uses it 20 times !!!

I will let you explore the other 15+ JavaScript libraries SharePoint loads into your browser yourself.

The phrase Eval is Evil is about its ability to execute JavaScript from a String...
So if you let users enter a String and pass it to eval()

You COULD be in deep shit... it is all up to you as a developer.

Note: JavaScript Client-Side users can do whatever they want, it's server-side code where the 'issues' with Eval occur

Among real JavaScript developers the phrase Eval is Evil is at the same level as Godwin's Law or Scopie's Law

If someone refers to Eval is Evil, he/she does not understand JavaScript <period>

  • Yep, that's why I put it into quotation marks. It's not my own oppinion and I know that it is used approx. 200 times throughout SharePoints JS codebase. My question is aimed at whether there are any potentially bad side effects of the way I use it in the snippet above. I don't want to start a general discussion about eval() itself. Commented Jun 24, 2016 at 19:04

If you want to hook into MDS you might want use the official way with the asyncDeltaManager

There are all kind of MDS events like:

asyncDeltaManager.add_beginRequest( function(){} );
asyncDeltaManager.add_pageLoaded( function(){} );
asyncDeltaManager.add_endRequest( function(){} );

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.