The so handy < iframe > can be a debugging nightmare. Not anymore.

The beauty of the < iframe >

The way we create and design web apps and sites has changed a lot in the past decade. Today’s user no longer needs to suffer the dreadful usability of frame-based websites where you could easily spend hours finding your way around. Luckily framesets are an archaic layout that’s no longer in use. Yet their successor, the < iframe > HTML tag has gained a lot of popularity for a very good number of reasons.

The inline frame, or iframe, is an excellent tool for embedding various types of content like video, social media, maps, and what not into your web app. It’s a quite simple and easy to learn tag which in essence allows you to show your visitors an isolated web page within your main web page view. So what’s the big deal you may ask? Well, there are a few reasons why you might want to use them:

• Flexibility — fetch any type of 3rd party (or your own!) rich media content and display it on your website without worrying too much about the underlying code and styles. It seamlessly blends with your own web page regardless of technology and CSS rules used.
• Future-proof — your own web page is safely isolated from the ‘iframed’ content item. The 3rd party provider can push fixes and updates to help usability and look-and-feel and if for whatever reason something breaks, the rest of the page will be unaffected.
• Visually pleasing — Most 3rd party owners will do their best to facilitate the seamless integration of their content into your site. The user can’t really tell it’s an external source embedded in your web page.
• Loading times — as you control the ‘iframed’ content with links in the parent page you can also define when and in what sequence each page element will be loading.

Cautions

While iframes can be very useful, they can also cause pain to the very same people who used them to embed various content in the web app. :) How come?

Typical usage of iframes is where they load various complex UI components such as UI builders, rich text editors, commenting systems and interactive maps from another web server. They can also be used for dynamically changing content on a given part of the page. All this can cause developers a lot of trouble trying to reproduce what the user was exposed to and how he interacted with that element.

A common scenario comes to mind:

1. A visitor opens up the chat window on your pricing page to ask for more info about your plans.
2. He types in his message but all that comes out is garbled. He tries closing and opening the chat box again but the window freezes.
3. He then leaves the page.
4. Tech support/developers then get the crash report. They figure out what the error was but have no clue what the user really did.

It’s not always errors. It could be that the user just did something unexpected on the page that you don’t know how to replicate.

There are various crash reporting tools out there that would log the errors that occurred in an iframe. What if you could get the crash report along with a recording of the user actions so that you’d not only see the logged messages of your errors but also be able to replay them as “videos” and see what exactly happened?

How SessionStack is helping

We at SessionStack strive to give you precisely that: we monitor your web app user sessions. When something breaks along with the log you’ll get the user session recording to help you spot the error at a glance.

More importantly, we just added support for iframes too. Now SessionStack not only detects the iframe tag but will also record all user actions inside the iframe and will readily replay these for you.

Below is a snapshot of the SessionStack player: to the left of each screenshot you can see a track record of all the user actions along with details like failed network requests, errors and debug messages, while to the right SessionStack displays a ‘video’ of the interaction that’s taking place. Until now SessionStack only detected iframes on a web page while now you can actually see what’s happening in the iframe tag (the screenshot to the right):

The iframe can display a separate content element, either from the same site or from a 3rd party one. Note that only same-origin iframe user actions will be recorded. This limitation is caused by the browser rather than SessionStack. For security reasons, browsers adopt a same-origin policy which prevents SessionStack from collecting the necessary data to replay the user actions that take place inside the cross-origin iframe.

Another example of SessionStack replaying user actions within an iframe (bottom right part of the screenshot):

Ready to give SessionStack a try? Go for it, it’s free.

..and tell us how you plan on using SessionStack.