iFrame support in SharePoint 2013

Recently I worked on a support case related to iFrame and SharePoint 2013.  What I learnt was an eye opener so I wanted to share this with the developer community just in case it helps.

Long story short, SharePoint does not support iFraming of editable pages in cross-domain scenario.  If you are developing something where you would be opening up an editable page (e.g., new/edit forms) within an iFrame, you will end up with a JavaScript access denied error.  Here’s some more details on this with steps to reproduce/test.

Consider you have a simple HTML page in an IIS web site (let’s say https://htm.contoso.com/test.htm) that has an iFrame.  This iFrame displays a SharePoint list form (e.g., https://dev.contoso.com/Lists/WFList2013/AllItems.aspx).  When you browse to the HTML page, the list form will render fine.  But when you click some option which involves associated JavaScript files (e.g., clicking the Edit Properties for a List Item ribbon action), it will throw a JavaScript error similar to what’s shown below and the form will not be loaded.

 Webpage error details
  
 User Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; Trident/4.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; .NET4.0C; .NET4.0E; MS-RTC LM 8; InfoPath.3)
 Timestamp: Fri, 27 Jun 2014 11:27:43 UTC
  
 Message: Access is denied.
  
 Line: 1
 Char: 60838
 Code: 0
 URI: https://dev.contoso.com/_layouts/15/init.js?rev=ZCyl%2Bj%2B4NZLoeodWTEXQ0Q%3D%3D
  
 Message: Permission denied
 Line: 1
 Char: 106124
 Code: 0
 URI: https://dev.contoso.com/_layouts/15/init.js?rev=ZCyl%2Bj%2B4NZLoeodWTEXQ0Q%3D%3D

NOTE: This problem only happens in cross-domain scenario as shown above.

The JavaScript error and the call stack will look like the below:

 stack:
 "Error: Access is denied.\r\n\n   
 at STSNavigate (https://dev.contoso.com/_layouts/15/init.js?rev=rQHvYUfURJXLBpgKnm0dcA%3D%3D:1:61098)\n   
 at GoToPage (https://dev.contoso.com/_layouts/15/init.js?rev=rQHvYUfURJXLBpgKnm0dcA%3D%3D:1:61597)\n   
 at _EditItem (https://dev.contoso.com/_layouts/15/core.js?rev=uA2xjCXmuYM5ARP8g3eTSA%3D%3D:1:80530)\n   
 at _EditItem2 (https://dev.contoso.com/_layouts/15/core.js?rev=uA2xjCXmuYM5ARP8g3eTSA%3D%3D:1:80482)\n   
 at b (https://dev.contoso.com/_layouts/15/init.js?rev=rQHvYUfURJXLBpgKnm0dcA%3D%3D:1:117426)\n   
 at EnsureScript (https://dev.contoso.com/_layouts/15/init.js?rev=rQHvYUfURJXLBpgKnm0dcA%3D%3D:1:77871)\n   
 at CoreInvoke (https://dev.contoso.com/_layouts/15/init.js?rev=rQHvYUfURJXLBpgKnm0dcA%3D%3D:1:117443)\n   
 at EditItem2 (https://dev.contoso.com/_layouts/15/init.js?rev=rQHvYUfURJXLBpgKnm0dcA%3D%3D:1:138408)\n   
 at eval code (eval code:1:76)\n   
 at SP.Ribbon.NativeUtility.executeECBCommand (https://dev.contoso.com/_layouts/15/sp.ribbon.js?rev=d4Y4E0ghdo65Uz4tti0FZw%3D%3D:2:222153)"

This is an intentional security measure put in place to mitigate clickjacking vulnerability and it is documented in IFraming SharePoint-hosted pages in apps.

Just wanted to call this out explicitly in the hope that this information helps you in better designing and architecting your SharePoint 2013 solutions.