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 http://htm.contoso.com/test.htm) that has an iFrame.  This iFrame displays a SharePoint list form (e.g., http://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: http://dev.contoso.com/_layouts/15/init.js?rev=ZCyl%2Bj%2B4NZLoeodWTEXQ0Q%3D%3D
 
Message: Permission denied
Line: 1
Char: 106124
Code: 0
URI: http://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 (http://dev.contoso.com/_layouts/15/init.js?rev=rQHvYUfURJXLBpgKnm0dcA%3D%3D:1:61098)\n   
at GoToPage (http://dev.contoso.com/_layouts/15/init.js?rev=rQHvYUfURJXLBpgKnm0dcA%3D%3D:1:61597)\n   
at _EditItem (http://dev.contoso.com/_layouts/15/core.js?rev=uA2xjCXmuYM5ARP8g3eTSA%3D%3D:1:80530)\n   
at _EditItem2 (http://dev.contoso.com/_layouts/15/core.js?rev=uA2xjCXmuYM5ARP8g3eTSA%3D%3D:1:80482)\n   
at b (http://dev.contoso.com/_layouts/15/init.js?rev=rQHvYUfURJXLBpgKnm0dcA%3D%3D:1:117426)\n   
at EnsureScript (http://dev.contoso.com/_layouts/15/init.js?rev=rQHvYUfURJXLBpgKnm0dcA%3D%3D:1:77871)\n   
at CoreInvoke (http://dev.contoso.com/_layouts/15/init.js?rev=rQHvYUfURJXLBpgKnm0dcA%3D%3D:1:117443)\n   
at EditItem2 (http://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 (http://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.