Think Twice Before Including Video Content in Office or SharePoint Add-Ins

Let us say, for the sake of discussion, that you, being an enthusiastic SharePoint and Office developer, have just created a shiny new Add-In and you are ready to unleash it to the world. As we live in modern times where everything is on YouTube and selfies have been replaced by live video from smartphones, you decide to include some whiz-bang video content in your super-duper new add-in. Good plan. You drop a simple HTML5 video tag into your code and, because you are one of the cool kids who gets this whole cloud thing, you even include the nifty Azure Media Player, encode your content into multi-bitrate streaming video format, and are all good to go. A quick bit of testing on various browsers in Windows 10 and Mac OS X shows that everything is working as expected so off you go to the Seller Dashboard in hopes that the lives of users all across the globe will soon be enriched by your brilliant bit of coding genius.

Imagine your surprise when, after what seems to be a much longer delay than is really necessary, you receive a crushing rejection email that dashes your hopes of impending global domination. The email states that your add-in cannot be approved because you failed to follow the submission guidelines. Specifically, you are informed that you have violated section 4.12.1, which states "Your app or add-in must be fully functional with the supported operating systems, browsers, and devices for Office 2013, Office 2016, SharePoint 2013 and Office 365". It goes on to say that "Add-ins must be compatible with all versions of Internet Explorer 11 and later, and the latest versions of Chrome, Firefox and Safari (Mac OS)". But, you think to yourself, you did, in fact, test on all the various browsers and everything worked as expected. So what gives? If you are lucky enough to be able to get additional details from the Office Store validation team, which will almost certainly not be included in the initial rejection email, you might just get them to tell you something like the following: "We encountered an error in the Office web app, when using your add-in with Internet Explorer 11 on Windows 7".

Wait, what? Windows 7? That was two full OS releases ago! Add-ins weren’t even around then so how could you be expected to support an OS that shipped in 2009?!? Ridiculous or not, the 2013 versions of Office and SharePoint are both supported on IE 11 in Windows 7, so you dig out an old Windows 7 disc and spin up a virtual machine to discover that, sure enough, an error gets thrown when the player tries to load your video. Obviously, since IE didn’t fully support HTML5 until about the time Windows 10 shipped, the player is trying to fallback to Flash or Silverlight, so you load up both plugins and still get the same error. No matter what you try, you see messages like "One or more blob URLs were revoked by closing the blog for which they were created" or "error: videojs: (CODE:274726913 undefined) [object Object]". And yet, opening the video in a separate tab or window works just dandy, so it MUST be something about trying to play video inside an add-in directly, right?

A quick search through the Office Dev Center produces no results about blocked plugins like Flash or Silverlight. Likewise, no mention whatsoever of any such limitations in the Office Store validation rules. That leads you to think that perhaps it is some sort of security limitation, so you dig up the URL for the Privacy and Security of Office Add-Ins​. Scanning down the page, in a section innocently titled "Web clients", you come across the following text: 

"In supported Web clients, such as Excel Online and Outlook Web App, Office Add-ins are hosted in an iframe that runs using the HTML5 sandbox attribute."

And there’s even an image to go along with it:

And that’s when it hits you. Due to the lack of support for the HTML 5 video tag in IE 11 on Windows 7, the player is trying to load your video content in a plugin, which is blocked inside of an IFRAME that only has the raw "sandbox" attribute. But, you think to yourself, surely the smart folks at Microsoft included the "allow-plugins" parameter in their code, right? After all, it’s been around for years already, and backwards compatibility almost demands its inclusion. So you pop open an Office web app in your browser, click your add-in link and inspect the source, only to find the following markup in the parent IFRAME:

… sandbox="allow-scripts allow-forms allow-same-origin ms-allow-popups allow-popups" …

You stare at it in disbelief. Surely, those whiz kids at Microsoft did not make a conscious decision to allow scripts, popups and forms while blocking plugins? And then fail to clearly mention this in the Office Store validation rules documentation? And further fail to point it out in the rejection email when the testers obviously knew your plugin included videos and they were trying to test it in IE 11 on Windows 7? That just couldn’t happen, right? 

Welcome to the new way, my friend. They say it’s much better than the old way. In the new way, you get to add exclusionary scripts and either block key portions of your content or add a sad little text box telling users on older platforms that they have to manually open a new browser window and copy a hyperlink to view said content. And such things will be poorly documented and excluded from test results so you can spend endless hours trying to decipher vague emails, wondering why you aren’t allowed to commercialize your applications in a store where it takes weeks to get any kind of response, strict naming and style conventions are applied to you but not to "official" apps, purchase options are limited, marketing is non-existent, value is arbitrarily decided, and licensing is a complete catastrophe. 

Are we having fun yet???

 

SmartTrack Operational Analytics for SharePoint​​ ​