In order to resolve this issue you will need to change the master-page and add the following tags, which allows the page content to be presented inside an Iframe element.
This solution is simple, yet strange. You also need to take into consideration that when using this approach you are exposing any pages that are driven by the changed master page to ClickJacking.
So why is it simple? all you need to bypass Microsoft Sharepoint build in security restriction, is to insert the following tag : <WebPartPages:AllowFraming runat=”server” /> on your Master Page.
So why is it strange? Because unless you put the tag in two different locations on the master page it won’t work when the publishing feature is turned on. Really?… mmhhmm… you bet! Black magic indeed. Thanks to my friends in Microsoft support (scroll down please) and their patience and perseverance handling my nervous breakdowns, we were able to resolve the issue by placing the tag in these strategic places on the master page. And if this doesn’t work maybe you also need to kick the tires on your SharePoint servers. Hopefully this will resolve any mysterious behaviors.
You will need to place the tags here (look for the above tags as the location indicator):
Location I:
Search the master page for PlaceHolderPageTitle as your location indicator and place the tag under it.
<asp:ContentPlaceHolder id=”PlaceHolderPageTitle” runat=”server”>
<!– custom tag –>
<WebPartPages:AllowFraming runat=”server” />
Location II:
Search the master page for WebPartAdder as your location indicator and place the tag under it.
<WebPartPages:WebPartAdder ID=”WebPartAdder” runat=”server” />
<!– custom tag –>
<WebPartPages:AllowFraming runat=”server” />
A warm thank you to my friends in Microsoft support that helped resolve this issue:
Manoj Sompalli, Deepak Varma, Anil Maharana, and Viraj Agarwal .
Thanks to their help we are still alive after this adventure.