Working with Adobe Flex and iframes

As part of the upcoming Active Wizard 4.0 release, and as a result of a client’s requirement, we recently added a new input type: WYSIWYG. The WYSIWYG input type allows users to style and format text just like in a word processing application. After evaluating some of the popular HTML/JavaScript based editors we finally decided on FCKEditor (now CKEditor.) Another new feature of Active Wizard 4.0 is an Adobe Flex based Active Form component. Integrating these two new features proved to be quite the challenge.

At the end of the day, Flex is Flash; an HTML or JSP page will have a swf file embedded in it and the Flash Player plug-in will be used to render it. Until now, most of our Flex and Flash projects have consisted of either small components within a page, or the entire page itself. In both cases the default “wmode” parameter value has always been used: “window.” Integrating the WYSIWYG control within our Flex component required using a different wmode value: opaque.

In order to integrate the WYSIWYG control into our Flex component we had to use iframes and this is what necessitated the use of the opaque wmode value. A quick Google search for “Flex iframes” turns up quite an interesting selection. One of the top hits is a project on Google Code called flex-iframe. We actually wound up using this component as it’s quite robust and works well. However, the first hit is an article titled “Don’t Use IFrames for HTML in Flex” and lists reasons why using iframes and Flex/Flash is a bad idea. One of the reasons is specifically because it requires the use of the opaque wmode value and lists the following three reasons:

1. Speed: There is no big surprise here, but when you force Flash to composite the HTML layers above and below, you are adding additional processor load.
2. Accessibility: wmode makes your movie invisible to screen readers
3. Inconsistent Performance

At various points during development, issues 1 and 3 came up and were quite problematic. Regarding the speed issue, we noticed that the more complicated content an iframe contained the slower the performance was. Surely this could be expected to some degree, however, given that we were embedding complex JavaScript based WYSIWYG controls, our iframe content sometimes became all but unusable. Inconsistent performance also left us scratching our heads: two separate views that shared quite a bit of code wound up performing differently when their content was scrolled, but only in Internet Explorer. Fortunately, Adobe’s JIRA system already had that bug logged. Unfortunately the bug was still listed as open with no plans from Adobe to be fixed anytime soon.

So what did we end up doing? Several things:

• To address the performance issue we wound up not embedding FCK in our form multiple times. Instead we embedded a simple html page that we updated when the user changed content. The WYSIWYG only appears when the user clicks in the html area, via a modal popup.
• The scrolling issue fix was easy to implement, however, thinking of it took a bit of time. We initially tried some of the suggested fixes posted on the JIRA page, but they didn’t seem to work us. Since the issue only affected the UI while the user was scrolling the page, we decided to simply disable “live scrolling.” That is, the user can move the scrollbar normally but the rest of the UI won’t update until the user lets go of the scrollbar.

In the end we wound up with a rather elegant solution that’s transparent to the end-user; they don’t know that they’re using a combination of Flash, HTML and JavaScript, it just works. While we hope Adobe eventually addresses the issue with wmode we would rather they create a better rich text editor (RTE.) We only went with the HTML/JavaScript RTE because the built-in Flex RTE wasn’t robust enough for our requirements. Had it been able to support superscript and subscript, copying and pasting from MS Word and the ability to output XHTML we would have gladly used it. While there are hacks to achieve some of those requirements, copy and pasting from MS Word doesn’t appear to be possible at this time. Hopefully Adobe will either enhance the built in RTE or offer official support for integrating HTML/JavaScript (via iframes or something else.) In the meantime all we can do is come up with creative solutions that work as best as possible given these limitations.