Zipped war file to reproduce the problem

Full unzipped war

I tried the test case myself and have some comments. I'll need feedback as to whether or not I have done the right steps to see the issue in question.

1) I wasn't able to replicate the issue in any browser if I started with the URL:

http://localhost:8080/testIcefaces2/

This would first request the index.jsp file which would in turn do a jsp:forward:

<jsp:forward page="faces/ICEfacesPage1.xhtml" />

and worked in all browsers, including IE9, for me.

2) If I started with the following URL (bypassing the index.jsp):

http://localhost:8080/testIcefaces2/faces/ICEfacesPage1.xhtml

then it would fail to find the button image. However it failed in all browsers for me.

In case #1, because the original URL does not actually contain the /faces/ mapping, the URL used to get the button is:

http://localhost:8080/testIcefaces2/btn_ok_en.jpg

In case#2, because the original URL does contain the /faces/ mapping, then it tries to resolve the button as:

http://localhost:8080/testIcefaces2/faces/btn_ok_en.jpg

Since this maps to the FacesServlet, the resource is not found. I was able to work around the issue but doing the same thing that we do in the component showcase examples and simply specify a non-relative path to the resource. So in the test case I changed this:

<ice:commandButton
image="btn_ok_en.jpg"
action="/ICEfacesPage1.xhtml" />

to:

<ice:commandButton
image="/btn_ok_en.jpg"
action="/ICEfacesPage1.xhtml" />

And that helped it work in all browsers for both initial URLs (case #1 and case #2).

I would like to add here that when I moved sample code into a separate project in Netbeans by copy + pasting it. Everything worked on my side as well. And I was not able to reproduce the problem either. Then I took this .war file and deployed it in Tomcat 7.
Opened Chrome with the following URL:
http://localhost:8084/testIcefaces2/ (you should not see changes in this URL when you go from one page to another via link or button),
all works as described.

Tested the same thing in IE9 after clearing the browser's cache:
http://localhost:8084/testIcefaces2/ -
and it failed to load the button image after moving to the second page via application link.

Please see the screenshot attached which I did a couple of minutes ago.

Screenshot demonstrating the issue

I was able to see this only when the cache is cleared. After the resource has been loaded at least once, navigation works fine and the resource always appears to render successfully.

From what I see in the IE Developer tools, the request that causes the navigation triggers a ViewRoot update (updating the entire page) but the expected request for the src of the <input> that has the src image is never made. So it appears that IE is not re-evaluating that part of the update which would fire the request.

To try and verify this, I ran the same test but added the following into the markup for page 1 to ensure IE had a cached version of the image.

<img src="btn_ok_en.jpg"/>

Then when it goes to page 2, it works fine because IE can get it out of the cache.

This may be related to changes in the caching mechanisms in IE (http://blogs.msdn.com/b/ie/archive/2010/07/14/caching-improvements-in-internet-explorer-9.aspx). Since an Ajax "forward" navigation doesn't actually change the URL, it may behave somewhat similar to Back/Forward history navigation.

Assuming this is the case, then it shouldn't matter whether or not ICEfaces is involved so I modified the case to remove any reference to ICEfaces (remove stylesheet links, changed ice: components to h:components, removed namespace references) and the behaviour is the same.

The bottom-line is that this is an IE-specific issue, unrelated to what ICEfaces is actually doing. The workaround requires some sort of way to tell IE that, just because the URL hasn't changed. There's a discussion to that effect here: http://stackoverflow.com/questions/367786/prevent-caching-of-ajax-call.

Quickly confirmed with Mircea that there wasn't something going on. The best advice would be to pre-load (but not display) the image(s) or other resources you need on the original request so that they are available in IE's cache when you need them. Or perhaps one of the strategies mentioned in the link I provided above will suffice.

Re-opening this JIRA. A different customer has been able to show that this is not an issue with a basic JSF test case. Using the exact same code using ICEfaces cases the issue.

As per the conversation in the support meeting, I tested with using a commandButton with a f:ajax tag to display the image. Testing in IE9, the image is displayed upon clicking of the button. It is not displayed if navigation occurs.

Attached test cases for a non-ICEfaces JSF app and an ICEfaces app. The ICEfaces app includes the commandButton/f:ajax test.

I don't think the recent test cases are equivalent. The non-ICEfaces test doesn't use Ajax so:

• a ViewRoot style update is not done
• the URL in the browser changes (which bypasses the issue)

The problem is related to ViewRoot updates via Ajax where the URL doesn't change. In those cases, IE simply tries to use the cache and will not send a request to retrieve the resource. I suspect that if you change the JSF only test to use f:ajax (or remove ICEfaces libs from the ICEfaces test), it will behave the same way as the ICEfaces test.

This issue is definitely not caused by ICEfaces. After running a modified test case that was not using ICEfaces at all and the navigation was triggered by Ajax enabled h:commandLink the issue could still be reproduced. It seems that IE9 will not make a request for the image referenced by the 'input' element that is inserted dynamically into the document.

Beside the workaround offered by Deryk on could create a servlet filter for the served images, filter that would return a different combination of caching headers to hopefully make IE9 retrieve the referenced images.