I recently had the opportunity to work on a project for a large company that was implementing an extensive federated search. In addition to having the search be accessible through their CRM, they wanted this search to be available on their two intranets by way of an iframe. Suffice it to say these intranets were run on pretty outdated platforms because they had to work on much older versions of Internet Explorer, which was the company standard.
My role in this project was the front-end development of the search interface. With this particular issue, I worked with the company’s back-end developers to implement the iframe into the individual intranets. We ran into a few issues, of course, when testing older versions of Internet Explorer including 9 & 10. What happened was that the meta tag on the parent page (the intranet) that sets the document mode was forcing IE to render the web page as IE8, therefore messing with the styles on the search page in the iframe.
A little research found that “If the top-level page is not in IE9 mode, the iframe element cannot render its contents in IE9 mode, even if the web developer specifies it.” So, since the company wasn’t ready to update their intranet to the latest IE version and therefore force the intranet to render as a newer version of IE, we had to find a work around to force the styles to appear correctly when rendered in an iframe, but not affect the original page.
However that wasn’t the only wrinkle: because this search platform was built using the Salesforce platform, it would be accessed on mobile devices using Salesforce1, which renders its pages using iframes, too. So not only did we need to target the search page styles when they were rendered in an iframe on a desktop, but also AVOID adjusting styles when the search was rendered on the Salesforce1 mobile app.
Javascript to the rescue!
Well, logic would dictate that at this point, we’d need logic, and not just magical CSS. The logic worked itself out:
IF page renders in an IFRAME in an INTERNET EXPLORER but not a mobile device, THEN change these styles…
So as you can see in the code snippet below, lines 3-9 use the try and catch statements to return the isPageInframe function as true if the page is rendered in an iframe. Then, lines 12-18 show an if else if statement that asks if the page is rendered in an Internet Explorer browser. If it is, then the style changes execute (line 13). Otherwise (else if), if the page is rendered in an iframe and is not being rendered on any mobile platform, then it will execute a different set of style changes (line 17).
<script>// <![CDATA[ // FOR WHEN PAGE IS LOADED IN AN IFRAME… function isPageInframe(){ try { return window.self !== window.top; } catch(e) { return true; } } $( document ).ready(function() { // IF PAGE IS IN AN IFRAME AND AN IE BROWSER… if(isPageInframe () && (navigator.appName == ‘Microsoft Internet Explorer’)) { document.getElementById(‘container’).style.display=”none”; } // IF PAGE IS IN AN IFRAME AND NOT AN IE BROWSER AND NOT MOBILE PLATFORM… else if (isPageInframe () && (navigator.appName == ‘Netscape’) && (navigator.platform !== ‘iPhone’) && (navigator.platform !== ‘iPad’) && (navigator.platform !== ‘Android’) && (navigator.platform !== ‘iPhone Simulator’) && (navigator.platform !== ‘iPad Simulator’) && (navigator.platform !== ‘Linux armv7l’) && (navigator.platform !== ‘iPod’) && (navigator.platform !== ‘iPod touch’)){ document.getElementById(‘container’).style.display=”none”; }; }); // ]]></script>
This effectively solved the targeting problem as this code lived on the page that was being rendered in an iframe, and no changes needed to be made on the parent page on the intranet. It worked well on Internet Explorer versions 9, 10, and 11, without affecting the original page, pages rendered on mobile devices, or rendered on other browsers on the desktop.
Did you have a similar problem? How did you solve it?