FPM in standards mode in EP

[maartenf]

Hello,

We are experiencing problems when trying to start a FPM application in standards mode in the enterprise portal. (7.40 SP11)

Error:

The FPM we are trying to start contains HTML islands. Currently when we try to start the view with the HTML islands we are getting shortdump: 'To use a UI element of type HTML_ISLAND, the application must be executed in the "Standards" browser mode'. However our portal runs in standards mode and at the moment we don't see why this application isn't handled as such.

Flow:

- FPM application is started in our portal. When starting the portal, the HTTP response header x-ua-compatible with value IE=edge is visible in Fiddler. IE Developer tools indicates 'Standards' mode is the default rendering mode.

- When clicking on a specific button inside this FPM, another FPM is opened in a new browser window. This application is also embedded in the portal and is started via a Quick Link.

- The new window is started and again the HTTP header x-ua-compatible: IE=edge is visible in Fiddler. However when navigating to the view with the HTML island, the short dump occurs.

After consulting lots of documentation, we changed the configuration on diverse levels but for now without success:

- FPM application parameter WDPREFERREDRENDERING to "standards"

- iView config:

     - Hand over Browser Document Mode Parameter: checked

     - added application parameter: sap-ie=EDGE

     - Default Document Rendering Mode: Standards

     - Launch in new Window: Display in separate headerless portal window (standards mode) (although I don't think this will affect the behaviour since it's started via a Quick Link?)

I guess we overlook something... Please let me know if something is not clear!

Any help is greatly appreciated!

Kind regards,

Maarten

[former_member21160 · Accepted solution]

Hi Marteen,

Many thanks for using SCN Discussions Forum

I have done a quick search regarding this issue and have you configured the application itself to standard browser mode?

From what I understand you are using the Portal and it is rendering in IE=Edge according to the Browser Document Mode of the current Framework Page you are using?

I have checked this FPM application you mentioned and a note shows up for configuring the FPM application for Standards Mode 1987004 - Adjust FPM config to standard browser mode.

Best Regards,
Jinnyre Malazarte - Enterprise Portal Support Engineer

Follow Jinnyre Malazarte

[maartenf · Accepted solution]

Hi Jinnyre,

Thank you for your quick response.

 I have done a quick search regarding this issue and have you configured the application itself to standard browser mode?

the FPM application parameter WDPREFERREDRENDERING is set to STANDARDS (W3C Standards mode). What i forgot to mention in the initial post, the application runs fine when running directly from SAP GUI.

From what I understand you are using the Portal and it is rendering in IE=Edge according to the Browser Document Mode of the current Framework Page you are using?

As I mentioned, our current framework page of the portal indeed runs in standards mode.

I have checked this FPM application you mentioned and a note shows up for configuring the FPM application for Standards Mode 1987004 - Adjust FPM config to standard browser mode.

I checked the note but it looks like it solves another issue than the one we are experiencing. The FPM applications are custom developed using HTML islands. I checked the solution however and the solution is adding the parameter WDPREFERREDRENDERING, but as stated before, this is already configured.

Best regards,

Maarten

[nickrankin · Accepted solution]

Hi Maarten,

Are you using the Standards Ajax FWP? If so you do not need to use the NavMode10/Launch in new Window: Display in separate headerless portal window (standards mode) method.

Additionally would it be possible to post a screenshot of the error you are getting?

Finally I'd recommend checking the Fiddler HTTP trace again for any non-standards "x-ua-compatible" headers (e.g: EmulateIE7, EmulateIE8 etc.). This should indicate if there is a Quirks parameter set somewhere which is interfering with the application rendering.

Best regards,

Nick

[maartenf · Accepted solution]

Hi Nick,

We indeed use the Standards Ajax FWP (only the masthead is changed with a custom developed one).

The screenshot of the error:

I also replayed the scenario and rechecked with Fiddler for the x-ua-compatible response headers. For all the /irj/ (portal) requests the x-ua-compatible is present with value IE=edge (no other values found). Since the FPM is running inside the portal, I would think the inner frame would also run in standards mode... (also configured via the "Hand over Browser Document Mode Paramater" attribute in the iview)

Thanks!

Best regards,

Maarten

[nickrankin · Accepted solution]

Hi Maarten,

That is quite strange. When calling the FPM application ouside of the Portal are there any problems? Also when you preview the FPM iView under Content Administration does the error message also occur?

Nick

[maartenf · Accepted solution]

Hi Nick,

Strange problem indeed... The suggestion of testing it via Content Administration was really good, I didn't think of that in the first place. So I did some extra tests:

As already stated, the scenario consists of 2 fpm application where FPM A opens FPM B. FPM B is where the problem occurs.

So when directly opening the applications via application configuration in SAP GUI everything works:

- open A, press button, B is opened in new portal window, everything works

- directly open B, everything works

Also tried via Content Administration preview:

- open A, press button, B is opened in new portal window, everything works

- directly open B, everything works (however a rendering error is displayed for a split second when opening the application, see error below)

I don't really understand why this error is shown only in this case...

Best regards,

Maarten

[LutzR · Accepted solution]

Hi Follon, so there is obwiously something wrong with the way FPM A opens FPM B. There are some URL parameters to force correct document mode to a WD4A application. The portal correctly inserts theses parameters and FPM A does not when calling FPM B.

Did you already try to add parameter sap-ie=Edge to the URL that FPM A generates to call FPM B?

Regards,

Lutz

[maartenf · Accepted solution]

Hi Lutz,

Thank you for your reply.

When FPM A opens FPM B, this is done via a EP Quick Link. On the 'Application Parameters' attribute of the FPM B iview, we configured the parameter 'sap-ie=EDGE'. I guess this is sufficient since the portal will add the parameter to the application URL?

Best regards,

Maarten

[nickrankin · Accepted solution]

Hi Maarten,

Are you using compatibility view on your web browser? If you do, disable it and test the preview again. Although the x-ua-compatible headers should take priority over this.

I do think Notes: 2021994 or 1969004 may be of relevance here and the x-ua-compatible is not getting passed at some stage. Can you check if these notes are suitable for your system? If so do apply the latest patches (not SP) for your Portal/EPPSERV or EP-RUNTIME components depending on version, and any dependencies.

Best regards,

Nick

[maartenf · Accepted solution]

Hi Nick,

Our centrally-managed laptops indeed push compatibility view for intranet websites, but disabling this option doesn't change anything about the problem. Which is (as you stated) normal since the x-ua-compatible headers have a higher priority.

Unfortunately the notes don't apply for our system. Our EP-RUNTIME version is NW 7.40 SP11 patch 17, so these notes should already be included.

Best regards,

Maarten

[nickrankin · Accepted solution]

Hi Maarten,

I do still think these two Notes are relevant to the current problem. I would suggest redeploying your EP-RUNTIME (the SP11/PL17 sca) as per SAP KBA: 2155414. You can use telnet to do this (localhost connection is required for telnet).

It's possible the fixes were not deployed properly when the system was previously upgraded.

Best regards,

Nick

[maartenf · Accepted solution]

Hi Nick,

We tried redeploying the EP-RUNTIME, but it did not solve the problem. However our system admin applied a patch (from patch 17 to 33) and now it looks like it works! Strange issue...

Thank you for all the useful suggestions!

Best regards,

Maarten