OK, here’s a technical problem to solve. I’ve been chatting with one of the administrators of a very large website (if you guess, keep it to yourself) which, as part of its function, displays user-provided content in the middle of site-provided pages. For historical reasons, the user-provided content needs to allow scripts, Flash and other dynamic content. However, they want to prevent such content affecting “their” part of the page, above and below the user content, and performing malicious actions. Currently, this can be done using either script or CSS-positioning or both.
I suggested that in general, their problem was unsolvable, but that the industrial-strength way of getting such separation was to use an <iframe>. He told me that they’d tried that, but as scrollbars internal to the page were unacceptable, they’d had to try resizing the iframe dynamically using JS to eliminate the bars. This solution had run into technical difficulties, as explained in the following saga, some of which I don’t quite follow.
Currently in Gecko, as far as I can tell, if you don’t set a width and a height, <object> tags of type e.g. image/png size to their content. So why can’t (or why don’t) <object> tags of type text/html?
Here’s the story:
Here was the general process under which we went through to implement iframes:
The Problem: The users enter malicious content on the page that can overwrite our page content as well as steal cookies since it’s in the same domain.
Our proposed solution: We want to separate the user data on the page from our site content. The most esthetically clean way to do this was inside of an iframe that is automatically resized to avoid having embedded scrollbars which our user community would never be okay with.
- Any items with links, when clicked on only redirected the main page. We solved this issue for the most part, except for Applets, objects, etc… We would be willing to take this hit and force our developer community to change their code to support this. This is somewhere around 10-30% (the number is hard to calculate since it isn’t a part of the page, it’s a part of the code hosted elsewhere).
You don’t support JS
</noscript> <— at this point it breaks our <noscript> block
More user content with tables, etc which breaks our code…
- It broke save-as in IE, which we don’t care about that much, but it was a big deal in certain countries, as users really like to save data to their desktops to prove that they saw it and agreed to whatever was said on the page. We can get around this issue by allowing a save-as friendly version that can only be linked to from our own page, but it’s less than ideal.
- Certain forms of popups still allowed some forms of overwriting (both Netscape and IE verified – although SP2 has fixed some of these issues since that time).
- When users resized during render time it became an issue because of the weird way in which the JS was written… it would be making assumptions about a size that was no longer accurate.
- It caused JS errors with pages that attempted to resize themselves.
- Browser support – with iframes and JS required for this to work it only supported ~90% of browsers.
Based on our discussion the right idea would be to have a different form of iframe that resizes to the size of the page it is calling to avoid the embedded scrollbar issue. If we could make this a standard we might even be able to get higher than the ~90% we found in #7 of the problems list.