Remember my blog about IE and Portal which covered many scenarios that exposed rendering issues when running Portal in IE browsers? Just when we thought we’d covered all the possibilities, we discovered we hadn’t…
This blog covers another rendering issue we found in IE11 when running an iView in standalone mode.
What’s standalone mode?
Standalone mode means opening a Portal iView by navigating directly to the PCD path of the iView without using the Portal APIs, or in other words, without any Portal framework page. This is in contrast to opening a Portal iView by navigating to the content area, where the target is displayed in place.
Here’s an example of what a direct call to an iView looks like:
Navigation can be triggered by either of the following:
- Navigating to the Portal and adding the target iView as a parameter:
http://myportal:50000/irj/portal?NavigationTarget=ROLES:// aportal_content/Folder1/Folder2/MyWorksets/MyRole/UWL_MOBILE& username_field=auser&password_field=apasswork&login_submit=on&login_do_redirect=1&
Navigating to the Portal calls the content area and passes the “NavTarget” (the target iView) as a parameter in the post data. For example:
In the HTTPWatch snapshot below, you see the call to the content area and to the NavTarget (the iView that the Portal needs to navigate to) parameter in the “Post Data” tab:
(By the way – I published a blog in the past which discusses an interesting issue caused by calling content directly and not via the navigation APIs)
When would an iView run in standalone mode?
Sometimes an application (either an SAP application or a custom application) links directly to Portal iViews instead of calling them via the navigation APIs. BI Launcher is an example of this type of application. They trigger “window.open” and send the “open” method the direct link of the iView.
Another case where iViews run directly is when you preview an iView (you can preview an iView when you edit it in content management).
What’s the problem with running iViews directly?
As long as an iView is running within a Portal framework (full portal/ separate window/ separate portal window/ separate portal window standard mode, and so on), the browser automatically opens with correct document mode (standard/quirks). This occurs because the Portal framework sends a parameter in the response header called “x-ua-compatible” to the browser. For example:
- Running in Ajax framework page – the value is “IE=5,IE=EmulateIE7” (which means quirks).
- Running “Ajax Standard Mode Framework” – the value would be “Edge” (which means standard).
- Running in a separate Portal window standard mode – it would be “Edge”.
In the HTTPWatch snapshot below, we see the property sent in the first call of the Portal (by the way, it will be sent only when running in an IE browser because only IE recognizes the property):
Running an iView directly means that the framework “services” are lost, include sending the parameter for the correct document mode. The new standalone browser window containing the target iView opens in the default document mode of the specific IE version.
Why do most rendering issues arise in IE11?
Recently, a lot of customers upgraded their IE browser to IE11 and this issue emerged for many of them: the iViews opened in a new browser window via direct URL are not rendered well.
When examining the document mode of the browser, we at SAP could see that it was set to “Edge” instead of “IE5 Quirks” or just “Quirks”.
Why did this suddenly arise in IE11 and not in older versions of IE? That’s because up to IE11, new windows open in “quirks” mode by default. However, since IE11, new windows open in “Edge” mode by default. So we need to instruct it explicitly to open in quirks mode.
Of course, there could also be the opposite situation: an iView requiring standard mode rendering (Edge) and running on an IE older then IE11 opens automatically in quirks mode. But this seems to be an infrequent scenario.
What’s the solution?
The solution for this phenomenon is quite simple: add the “x-ua-compatible” property to the iView header.
A new property has been added to the root iView of AI iViews. This property is called “Default Document Rendering Mode”. This property has 2 possible values: “Quirks” or “Standard”. The default value for the property is “quirks”.
When the value is set to quirks – the header that is added is:
<meta http-equiv=”X-UA-Compatible” content=”IE=5, IE=EmulateIE7″/>
And when it’s set to standard – the header is:
<meta http-equiv=”X-UA-Compatible” content=”Edge”/>
In the HTTPWatch snapshot below, you can see that the property is added to the head of the returned HTML:
Note that when the property is returned from the framework – it is set in the response header, and in the iView it is set in the HTML head.
Both methods are valid, but if the value is set to both – the response header overrides the HTML head and its value affects the browser.
At first, the solution was implemented only in BI iViews, because these were the first scenarios we dealt with.
The SAP Note with the solution for BI iViews is:
When we received feedback about other iView types, because the solution for BI iViews had proved a good solution, we extended the solution to all AI iViews. The SAP Note is:
And there’s also SAP Note 2163649 which fixes a regression from SAP Note 2098706
Troubleshooting and workarounds
- If you deployed the fix from one of the above notes and this still doesn’t fix the issue – it might be that the iView was not updated with the new property.
You can check it by opening the iView properties via the “Content administration” tab and checking if the “DefaultDocumentMode” property exists. If it doesn’t, perform the following steps:
- Navigate to Content Administration -> Portal Content Management.
- In Portal Content, expand the Portal Applications folder, and select com.sap.portal.appintegrator.sap.
- From the right-click menu, choose “Update PCD Objects”.
- Go to the iView and check that the “Default Document Rendering Mode” property exists.
- If you have the version with the fix from SAP Note 2012705 and you don’t want to implement the more advanced note – you can use a workaround of adding the “DefaultDocumentMode” property to other iView types manually via the PCD inspector.
If you want to implement this workaround – follow the steps mentioned in this document