CInlineFrame and IE7 Workaround

What is the issue?

In non-latest releases of uPortal, CInlineFrame instances do not render as inline frames in Internet Explorer 7.

How can I resolve the issue via normal maintenance releases of uPortal?

Latest patch releases of uPortal resolve the CInlineFrame IE7 issue. The issue is that CInlineFrame helpfully maintains a list of browsers it expects to support inline frames and browsers not on this preset list (like IE7) aren't given the opportunity to display the frame.

One approach to address this is to patch up. The patch removes the not-useful-on-sober-second-thought CInlineFrame.java behavior of trying to make this distinction among browsers, instead adopting a defacto web-standard approach in the XSLT to include the hyperlink inside the <iframe> tags. Modern browsers display the inline frame, browsers that don't cope with IFrames display the link, everyone wins.

I don't want to do a full patch. What's the absolute minimum change I can make to make this problem go away?

1) Locate CInlineFrame.ssl in your uPortal as deployed. It lives in /WEB-INF/classes/org/jasig/portal/channels/CInlineFrame/CInlineFrame.ssl

2) Replace that file with the CInlineFrame.ssl attached to this wiki page.

3) When you next restart your uPortal, the IE7 inline frame issue will be gone.

I'm running Academus, Unicon's productized uPortal, rather than the basic opensource uPortal. Will this fix work for me?

Yes. In Academus, the typical path to this file is:

/portal-tomcat-a/webapps/portal/WEB-INF/classes/org/jasig/portal/channels/CInlineFrame/CInlineFrame.ssl

I'm running Luminis, Sungard's product built on uPortal. Will this fix work for me?

Yes.You will need to edit $CP_WEBINF/uPortal/org/jasig/portal/channels/CInlineFrame/CInlineFrame.ssl, as well as com/sct/pipeline/uportal/channels/cpip/stylesheets/CpipInlineFrameChannel.ssl located inside $CP_WEBINF/cars/cpip.car

Should I back up my portal before I make this change?

Absolutely. It is best to back up both the filesystem and the database of your uPortal or Academus before making any change to the filesystem resources underlying the portal. In this specific case, it's hard to see how this change could harm the portal database, but extra care in applying changes to production systems is a good idea.

Discussion of this workaround

It turns out you can fix this issue by deleting four characters.

In your deployed portal, edit /WEB-INF/classes/org/jasig/portal/channels/CInlineFrame/CInlineFrame.ssl

The change is illustrated by the strikeout here. Note that whitespace characters were added before and after the strikeout for the purposes of wiki formatting. The file attached to this page demonstrates exactly what the fixed file should look like.

<?xml version="1.0"?>

<?xml-stylesheet title="IFrameSupport" href="CInlineFrame/Iframe.xsl" type="text/xsl" media="explorer"?>
<?xml-stylesheet title="IFrameSupport" href="CInlineFrame/Iframe.xsl" type="text/xsl" media="netscape"?>
<?xml-stylesheet title="noIFrameSupport" href="CInlineFrame/ no Iframe.xsl" type="text/xsl" media="explorer"?>
<?xml-stylesheet title="noIFrameSupport" href="CInlineFrame/ no Iframe.xsl" type="text/xsl" media="netscape"?>

<document>
</document>

This will map all renders, both those the channel code intends to do IFrames and those it intends to supress IFrames, to the xsl that will render IFrames.

Besides fixing my deployed uPortal, I want to fix this when I next build from source too

Apply the change or replace the file at /webpages/stylesheets/org/jasig/portal/channels/CInlineFrame/CInlineFrame.ssl in your build environment.