Skip to Content
Author's profile photo Former Member

Rendering Issues when Running Portal iViews in Standalone Mode in Internet Explorer (IE)

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:

  • Calling an “EPCM.doNavigate” JavaScript method to get the target as a parameter (there are other parameters to this method but I won’t discuss them here).
  • 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 “” 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.

Solution evolution

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:

2012705 – BI iView’s are not render correctly when using Internet Explorer 10 and above

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:

2098706 – iView rendered corruptly when using IE10 and above when executing it directly or from headerless window

And there’s also SAP Note 2163649 which fixes a regression from SAP Note 2098706

2163649 – More scenarios of opening an iView directly (standalone) with IE10 and above causes rendering issues (continuation of 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:

  1. Navigate to Content Administration -> Portal Content Management.
  2. In Portal Content, expand the Portal Applications folder, and select
  3. From the right-click menu, choose “Update PCD Objects”.
  4. 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

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Former Member
      Former Member

      Thank you for the new blog

      it will be helpfull

      Author's profile photo Sven Kannengiesser
      Sven Kannengiesser

      Great! Just last week I came across this issue at the customer site. I was puzzled. Now it is all explained. IE11's different handling of the document mode in newly opened windows is the culprit!

      Author's profile photo XAVIER RICHARD

      Thank you very much, it solved my problem !

      Author's profile photo Vincent Noiset
      Vincent Noiset

      Nice... but time to time a nightmare...

      --> I "just" want to open a standard KM navigation iView in Standards mode.  Up to know I did'nt find the solution...  Except this note 2163649 that is... complex a brings me to apply a new patch...

      Best regards.