Use of iFrame to avoid IE oddities

Question

I'm working with a team on an ASP.NET MVC C# EF application that needs extensive Help materials. The Help materials will be stored on a helpdesk site (FreshDesk) so they can be accessed as a Knowledge Base and so we don't have to duplicate the Help materials both there and inside the app.

In a proof of concept test, we have code that will translates href links from different points in the application into urls to the Freshdesk pages, with anchors if needed. The Help material opens in a separate window so people can keep using the app. Generally that works fine.

Per the requirements it needs to work for Chrome and IE.

Using Chrome, the separate Help window opens nicely from inside the app, and the same window is re-used each time a new Help link is clicked. If you move the separate Help window it doesn't matter.

Using IE, we ran into a problem where a new window opens each time a new Help link is clicked. We figured that one out, however, the current solution has some remaining issues. One is that the solution requires closing the Help window and re-opening it each time. It reopens in a fixed position, which will be frustrating for users, because they will want to move the Help window. So now we're capturing the position of the Help window before it closes, and re-using that info when it is re-opened. It works, sort of, but has more issues.

Here's the problem for me. I'm concerned that the IE solution is not robust and reliable; and that the more special handling we need to add for IE the more it will run into problems in the field.

An alternative is to make the Help page a separate cshtml page and fetch and display the FreshDesk page in an iFrame. The desired outcome is that through the cshtml/iFrame the user could arrive at a specific Freshdesk Help page based on the application Help link, and from there if they wanted to they could navigate around the Freshdesk knowledge base using a table of contents and search function, all through the iFrame.

My question is, why would using an iFrame NOT be the better solution for this use case, or, what might go wrong with using an iFrame, compared to the special handling required for IE?

Answer 1

Here are some potential issues with an iFrame-style integration:

• The FreshDesk application may not support the display of its pages within an iFrame, e.g. if it has anti-clickjacking measures that can't be turned off.

• If you run into any IE issues where the resolution requires compatibility mode to be turned on, you will also have to turn on compatibility mode for your own application.

• Depending on browser settings, the browser may not allow cookies from iFramed content, which could interfere with FreshDesk session management.

• There may be cosmetic issues with the iFrame, e.g. an annoying small whitespace that causes two sets of scrollbars. You can usually figure out a way around this sort of thing but it is a PITA.

• End users will not be able to bookmark any of the FreshDesk pages, or use the navigation buttons such as back, forward, and history. Also they will not be able to cut and paste the address into an email if they wish to share something with a colleague.

• By concealing the address of the iFramed content, you may make yourself vulnerable to a MITM attack, since the end user can't tell if the content is served over HTTP or HTTPS.

• If the user hits the browser's refresh button, it may reset the iframe content back to its original landing page. This could be very frustrating if your network connections are not 100% reliable.

In my opinion, if you already have a new window solution with IE, and it works, stick with that. After all, you know what the issues are with your current solution; if you switch to something totally different, you never know if there are going to be even worse problems with it and IE.