I'm not seeing the popup in either of the sample applications with IE 8 but it does appear that there may be some issues with the nbsp entities embedded in the page. Removing them from both the basic and the compat-basic pages helps but is not a fix.

The steps for me to recreate this are to navigate to the stock JSF page and click the Stock JSF Page (ajax-all) button. Continuing to investigate as the other browsers don't appear to complain but if it's in stock JSF with IE we may need to open a case in the Mojarra tracking system.

The behaviour only occurs with IE on Glassfish with the   characters in the page. When I run the stock page without icefaces.jar in the WEB-INF/lib, I don't see the problem. Simply adding in icefaces.jar (even though on the stock page ICEfaces is not used) the problem occurs.

I also see this in the logs:

[#|2010-08-09T16:07:58.960-0700|WARNING|glassfishv3.0|org.apache.catalina.connector.Request|_ThreadID=25;_ThreadName=Thread-1;|PWC4011: Unable to set request character encoding to UTF-8 from context /basic, because request parameters have already been read, or ServletRequest.getReader() has already been called|#]

My theory is that we're hooking into JSF some where and reading some request parameters before the encoding gets a chance to be set - even when ICEfaces is not supposed to be active. Still looking where this might be occurring.

So we've run into this before - ICE-5209. When icefaces.jar is included (even if ICEfaces is not used on the page), our ResourceHandlers will run in a chain with isResourceRequest being called for each handler. If that resource handler retrieves a request parameter, it happens before the content encoding is determined which is contrary to the Servlet spec and leads to the logged error message and the undesired behaviour:

Unfortunately, the character encoding is calculated in the ViewHandler AFTER the resource handlers have run:

public void initView(FacesContext context) throws FacesException {
String encoding = calculateCharacterEncoding(context);
if (null != encoding) {
try

catch (UnsupportedEncodingException e) {
// PENDING(edburns): I18N
String message = "Can't set encoding to: " + encoding +
" Exception:" + e.getMessage();
if (log.isLoggable(Level.WARNING))

throw new FacesException(message, e);

}
}
}

The calculation is done this way (although there doesn't seem to be a reason why it couldn't be done before the resource handlers run):

public String calculateCharacterEncoding(FacesContext context) {
ExternalContext extContext = context.getExternalContext();
Map<String,String> headerMap = extContext.getRequestHeaderMap();
String contentType = headerMap.get("Content-Type");
String charEnc = null;

// look for a charset in the Content-Type header first.
if (null != contentType) {
// see if this header had a charset
String charsetStr = "charset=";
int len = charsetStr.length();
int idx = contentType.indexOf(charsetStr);

// if we have a charset in this Content-Type header AND it
// has a non-zero length.
if (idx != -1 && idx + len < contentType.length())

}

// failing that, look in the session for a previously saved one
if (null == charEnc) {
if (null != extContext.getSession(false))

}

return charEnc;
}

Issue filed with mojarra issue tracker:

https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=1767

This was quite a trip. I've now checked in a new resource handler called org.icefaces.impl.util.CharacterEncodingHandler and a new extra.faces-config.xml file that ensures it loads last and runs first. This handler's only responsibility is to run before any other handlers and set the character encoding in much the same way that Mojarra currently does it - just sooner so that the other resource handlers can get request parameters without Glassfish complaining and stopping the setting of the encoding. There doesn't seem to be any unintended consequence on Tomcat with this approach.