Simplified test case (minus the lib directory) that can be run as a web app or portlet

1) Build and deploy as a web app or portlet.
2) Point browser at host:port/calendar_icon/page1.iface
3) Click the button to navigate to page 2
4) Click the button to navigate back to page 1

In IE, when you get back to page 1, the calendar icon is missing and the style of the heading text is no longer correct (back to the default).

Images of the navigation using IE.

1) ie7 calendar 1.png: Initial view of page 1.
2) ie7 calendar 2.png: View of page 2 after navigation.
3) ie7 calendar 3.png: View of page 1 after navigation. Notice that the calendar icon is missing and the style of the heading is no longer correct.

You can run the example as a web app with the ice:portlet tag as it simply renders out as a <div>. You can "fix" the problem in the web app by changing the ice:portlet tags to body tags. Of course, in a portlet, this is not possible. It appears we may not be handling styles properly when they are contained in a portlet tag.

Deryk I have created a war using the application you have attaced, and it works fine with IE 7. May be some changes to the head fixed the problem. Can you please test the attached war.

Thanks,

The war is a web app built for the tomcat 6.

Your case does seem to work properly. But after I compared it to my original case, I noticed that my case used Facelets because the faces-config file has:

<application>
<view-handler>
com.icesoft.faces.facelets.D2DFaceletViewHandler
</view-handler>
</application>

If I took the WEB-INF/lib directory from your working case (ICE-3277.war) and added it to the directory structure of my original case (and included icefaces-facelets.jar as well) then re-ran the test, it fails with the original problem. So it seems to be specific to Facelets.

I have tested it with the Facelets as well, and I can reproduce it.

Adding the <redirect/> to the navigation rules fixes it, so its only happend with :
Facelets + page forward

<navigation-rule>
<navigation-case>
<from-outcome>page2</from-outcome>
<to-view-id>/page2.iface</to-view-id>
<redirect/>
</navigation-case>
</navigation-rule>
<navigation-rule>
<navigation-case>
<from-outcome>page1</from-outcome>
<to-view-id>/page1.iface</to-view-id>
<redirect/>
</navigation-case>
</navigation-rule>

There are couple of findings, but at first let me say that it doesn't have anything to do with the "ice:portlet" tag, if we replace it with the ice:panelGroup, the same problem remains intact.

As we already know that, this problem is not related to the ice:portlet tag and now I am going to add another interesting thing, that this problem is not even related to the Facelets. Seems like a contradictory statement to my last comment, isn't it? Well the attached app manifest the problem with Facelets and the forward, is its not the root cause. We can get same problem in the JSP version as well by just changing the little JSP markup.

What is the root cause?
Apparently IE doesn't like to applying the DOMDiff fragment, which root element is a "div" and that "div" has an immediate child as the css link. It doesn't complain anything but just doesn't respect the css(e.g.)

//Seems like IE doesn't like it, when dynamically being added to the DOM
<div id="j_id1"><link href="/component-showcase/xmlhttp/css/xp/xp.css" rel="stylesheet" type="text/css" />.......</div></form></div>

Why the attached app manifests the problem under the Facelets environment only and works fine with the JSP?
It seems like we have found a little inconsistency in the DOMDiff operation between the Facelets and Non-Facelets environment.

Let say, if we run the following two pages under the Facelets and non-Facelets enviroment. We will get two different DOMDiff results, Whereas it should be the same.

• Page1 JSP
  <ice:portlet>
  <ice:outputStyle href="/xmlhttp/css/xp/xp.css" />
  <ice:form>
  ..............
  </ice:form>
  </ice:portlet>

• Page2 JSP
  <ice:portlet>
  <ice:outputStyle href="/xmlhttp/css/xp/xp.css" />
  <ice:form>
  ...............
  </ice:form>
  </ice:portlet>

• Under Facelets if we navigate from Page1 to Page2, we will get the following markup as a result of a DOMDiff operation
  <div id="j_id1"><link href="/component-showcase/xmlhttp/css/xp/xp.css" rel="stylesheet" type="text/css" />.......</div></form></div>

• Under Facelets now if we navigate from Page2 to Page1, we will get the following markup as a result of a DOMDiff operation
  <div id="j_id1"><link href="/component-showcase/xmlhttp/css/xp/xp.css" rel="stylesheet" type="text/css" />.......</div></form></div>

Whereas in the JSP version we get the differnt DOMDiff result for the same JSP document.

• Under JSP if we navigate from Page1 to Page2, we will get the following markup as a result of a DOMDiff operation
  <form action="javascript:;" class="iceFrm" enctype="application/x-www-form-urlencoded" method="post" onsubmit="return false;">....</form>

• Under JSP now if we navigate from Page2 to Page1, we will get the following markup as a result of a DOMDiff operation
  <form action="javascript:;" class="iceFrm" enctype="application/x-www-form-urlencoded" method="post" onsubmit="return false;">....</form>

As we can see that in the JSP version, we are getting the "form" level update, and that makes IE happy.

To proof the finding I modified the markup of the JSP pages, so we can get the DOMDiff result, that would contain a "div" as root element and a "link" as immediate child. (e.g.)

• JSP Page 1
  <ice:form>
  <ice:panelGroup>
  <ice:outputStyle href="/xmlhttp/css/xp/xp.css" />
  <ice:commandButton action="page2" immediate="true" value="Go to Page 2"/><br/>
  <ice:selectInputDate value="# {dateBean.date}

  " renderAsPopup="true" />
  </ice:panelGroup>
  </ice:form>

-JSP Page 2
<ice:form>
<ice:panelGroup>
<ice:outputStyle href="/xmlhttp/css/xp/xp.css" />
<ice:commandButton action="page1" immediate="true" value="Go to Page 1"/><br/>
</ice:panelGroup>
</ice:form>

It above snippet would show the same problem even under the JSP environment.

Conclusion:
----------------

Framework Level:
Inconsistency in the result of the DOMDiff between Facelets and Non-Facelets environment.

Browser level issue (IE only):
According to the observation the external css link only works as a result of the DOMDiff, if the root element of the DOMDiff result is either one of a following element:

• html
• head
• body
• form

Attached plain html test, manifests the problem.

Mircea,

Please pick this up where Adnan left off. He's simplified the test case significantly.

Links referencing CSS rules are supposed to be inserted into the HEAD element of the document. Although most of the browsers are forgiving where the links are inserted, I don't think we should rely on this kind of behavior.

I believe a good way to fix the issue of CSS linking is to refactor ice:outputStyle component to use the ResourceRegistry API to insert the links directly into the HEAD.

I prototyped a version of ice:outputStyle component that uses the ResourceRegistry API but the results were not the greatest. The ResourceRegistry API is meant for serving up a resource while ice:outputStyle component just needs to reference one, regardless of how it will get materialized (sent over the wire). Also, as Deryk mentioned, we don't want to force a full page load on too often, especially in a portlet environment.

I attached a version of the plain HTML test case that mirrors better what the bridge does when an element is updated. The test case runs fine in IE, event with a CSS reference nested within the updated 'DIV'.

I also deployed the war file to try reproducing the described issue but I could still see the background-image of the button after the redirect.

I'm marking this INVALID for now. I really need a well defined test case that can prove clearly that there really is an issue.