Details
-
Type: Bug
-
Status: Closed
-
Priority: Major
-
Resolution: Fixed
-
Affects Version/s: 3.3
-
Fix Version/s: EE-3.2.0.BETA, EE-3.2.0.GA, 3.3
-
Component/s: None
-
Labels:None
-
Environment:IE Quirks mode and Mojarra 2.1.8+
-
Assignee Priority:P1
-
Workaround Exists:Yes
-
Workaround Description:As per the solution noted in the Mojarra JIRAs, adding the appropriate DOCTYPE entries to your page or template should prevent the browser from switching to Quirks mode.
Description
The following pages of the ICEfaces showcase application show some styling issues on IE browsers:
DataTable - Overview, Grouping, Sortiing, Table Configuration: page content renders bellow the left-side links
DateTimeEntry - all pages: page content renders bellow the left-side links
Dialog - Effects & Size, Modal & Movable: page content renders bellow the left-side links
FileEntry - Overview: page content renders bellow the left-side links
GMap: Layers, Map Markers, Map Options, Overlays - map does not render (greyed out content); js error non-existent as retested in IE8
LinkButton - Overview & PushButton - Overview: render issue
List - MultiList: page content renders below the left-side links
MaskedEntry -all pages: page content renders below the left-side links
Menu - Layout: page content renders below the left-side links
MenuBar - Effects: page content renders below the left-side links
Menu - Layout: page content renders below the left-side links
Printer - Overview: page content renders below the left-side links
ProgressBar - Overview, Push: page content renders below the left-side links
TextEntry - all pages: page content renders below the left-side links
TextAreaEntry - page content renders below the left-side links
After a binary search of revisions, it was found that the problem starts at revision 32182, with an update of the file lib/mojarra/javax.faces.jar (a 2.1.15 snapshot).
The showcase was tested with MyFaces, using the same revision, and the problem does not occur.
The following exception appears in the server console when trying to load any of the pages mentioned above (only happens with Mojarra):
ClientAbortException: java.net.SocketException: Software caused connection abort: socket write error
at org.apache.catalina.connector.OutputBuffer.realWriteBytes(OutputBuffer.java:369)
at org.apache.tomcat.util.buf.ByteChunk.flushBuffer(ByteChunk.java:437)
at org.apache.tomcat.util.buf.ByteChunk.append(ByteChunk.java:351)
at org.apache.catalina.connector.OutputBuffer.writeBytes(OutputBuffer.java:392)
at org.apache.catalina.connector.OutputBuffer.write(OutputBuffer.java:381)
at org.apache.catalina.connector.CoyoteOutputStream.write(CoyoteOutputStream.java:93)
at java.nio.channels.Channels$WritableByteChannelImpl.write(Channels.java:296)
at com.sun.faces.application.resource.ResourceHandlerImpl.handleResourceRequest(ResourceHandlerImpl.java:283)
at org.icefaces.impl.push.servlet.ICEpushResourceHandler$ICEpushResourceHandlerImpl.handleResourceRequest(ICEpushResourceHandler.java:238)
at org.icefaces.impl.push.servlet.ICEpushResourceHandler.handleResourceRequest(ICEpushResourceHandler.java:128)
at org.icefaces.impl.push.DynamicResourceDispatcher.handleResourceRequest(DynamicResourceDispatcher.java:77)
at org.icefaces.application.ResourceRegistry.handleResourceRequest(ResourceRegistry.java:131)
at org.icefaces.impl.application.WindowScopeManager.handleSessionAwareResourceRequest(WindowScopeManager.java:69)
at org.icefaces.impl.application.SessionAwareResourceHandlerWrapper.handleResourceRequest(SessionAwareResourceHandlerWrapper.java:40)
at javax.faces.application.ResourceHandlerWrapper.handleResourceRequest(ResourceHandlerWrapper.java:125)
at org.icefaces.impl.application.SessionTimeoutMonitor.handleSessionAwareResourceRequest(SessionTimeoutMonitor.java:71)
at org.icefaces.impl.application.SessionAwareResourceHandlerWrapper.handleResourceRequest(SessionAwareResourceHandlerWrapper.java:40)
at javax.faces.application.ResourceHandlerWrapper.handleResourceRequest(ResourceHandlerWrapper.java:125)
at javax.faces.application.ResourceHandlerWrapper.handleResourceRequest(ResourceHandlerWrapper.java:125)
at javax.faces.application.ResourceHandlerWrapper.handleResourceRequest(ResourceHandlerWrapper.java:125)
at javax.faces.application.ResourceHandlerWrapper.handleResourceRequest(ResourceHandlerWrapper.java:125)
at javax.faces.application.ResourceHandlerWrapper.handleResourceRequest(ResourceHandlerWrapper.java:125)
at javax.faces.application.ResourceHandlerWrapper.handleResourceRequest(ResourceHandlerWrapper.java:125)
at org.icefaces.impl.application.AuxUploadResourceHandler.handleResourceRequest(AuxUploadResourceHandler.java:82)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:591)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:304)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:240)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:164)
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:462)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:164)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:100)
at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:563)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:399)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:317)
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:204)
at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:311)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
Caused by: java.net.SocketException: Software caused connection abort: socket write error
at java.net.SocketOutputStream.socketWrite0(Native Method)
at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:92)
at java.net.SocketOutputStream.write(SocketOutputStream.java:136)
at org.apache.coyote.http11.InternalOutputBuffer.realWriteBytes(InternalOutputBuffer.java:218)
at org.apache.tomcat.util.buf.ByteChunk.flushBuffer(ByteChunk.java:437)
at org.apache.tomcat.util.buf.ByteChunk.append(ByteChunk.java:351)
at org.apache.coyote.http11.InternalOutputBuffer$OutputStreamOutputBuffer.doWrite(InternalOutputBuffer.java:243)
at org.apache.coyote.http11.filters.ChunkedOutputFilter.doWrite(ChunkedOutputFilter.java:119)
at org.apache.coyote.http11.AbstractOutputBuffer.doWrite(AbstractOutputBuffer.java:190)
at org.apache.coyote.Response.doWrite(Response.java:533)
at org.apache.catalina.connector.OutputBuffer.realWriteBytes(OutputBuffer.java:364)
... 40 more
DataTable - Overview, Grouping, Sortiing, Table Configuration: page content renders bellow the left-side links
DateTimeEntry - all pages: page content renders bellow the left-side links
Dialog - Effects & Size, Modal & Movable: page content renders bellow the left-side links
FileEntry - Overview: page content renders bellow the left-side links
GMap: Layers, Map Markers, Map Options, Overlays - map does not render (greyed out content); js error non-existent as retested in IE8
LinkButton - Overview & PushButton - Overview: render issue
List - MultiList: page content renders below the left-side links
MaskedEntry -all pages: page content renders below the left-side links
Menu - Layout: page content renders below the left-side links
MenuBar - Effects: page content renders below the left-side links
Menu - Layout: page content renders below the left-side links
Printer - Overview: page content renders below the left-side links
ProgressBar - Overview, Push: page content renders below the left-side links
TextEntry - all pages: page content renders below the left-side links
TextAreaEntry - page content renders below the left-side links
After a binary search of revisions, it was found that the problem starts at revision 32182, with an update of the file lib/mojarra/javax.faces.jar (a 2.1.15 snapshot).
The showcase was tested with MyFaces, using the same revision, and the problem does not occur.
The following exception appears in the server console when trying to load any of the pages mentioned above (only happens with Mojarra):
ClientAbortException: java.net.SocketException: Software caused connection abort: socket write error
at org.apache.catalina.connector.OutputBuffer.realWriteBytes(OutputBuffer.java:369)
at org.apache.tomcat.util.buf.ByteChunk.flushBuffer(ByteChunk.java:437)
at org.apache.tomcat.util.buf.ByteChunk.append(ByteChunk.java:351)
at org.apache.catalina.connector.OutputBuffer.writeBytes(OutputBuffer.java:392)
at org.apache.catalina.connector.OutputBuffer.write(OutputBuffer.java:381)
at org.apache.catalina.connector.CoyoteOutputStream.write(CoyoteOutputStream.java:93)
at java.nio.channels.Channels$WritableByteChannelImpl.write(Channels.java:296)
at com.sun.faces.application.resource.ResourceHandlerImpl.handleResourceRequest(ResourceHandlerImpl.java:283)
at org.icefaces.impl.push.servlet.ICEpushResourceHandler$ICEpushResourceHandlerImpl.handleResourceRequest(ICEpushResourceHandler.java:238)
at org.icefaces.impl.push.servlet.ICEpushResourceHandler.handleResourceRequest(ICEpushResourceHandler.java:128)
at org.icefaces.impl.push.DynamicResourceDispatcher.handleResourceRequest(DynamicResourceDispatcher.java:77)
at org.icefaces.application.ResourceRegistry.handleResourceRequest(ResourceRegistry.java:131)
at org.icefaces.impl.application.WindowScopeManager.handleSessionAwareResourceRequest(WindowScopeManager.java:69)
at org.icefaces.impl.application.SessionAwareResourceHandlerWrapper.handleResourceRequest(SessionAwareResourceHandlerWrapper.java:40)
at javax.faces.application.ResourceHandlerWrapper.handleResourceRequest(ResourceHandlerWrapper.java:125)
at org.icefaces.impl.application.SessionTimeoutMonitor.handleSessionAwareResourceRequest(SessionTimeoutMonitor.java:71)
at org.icefaces.impl.application.SessionAwareResourceHandlerWrapper.handleResourceRequest(SessionAwareResourceHandlerWrapper.java:40)
at javax.faces.application.ResourceHandlerWrapper.handleResourceRequest(ResourceHandlerWrapper.java:125)
at javax.faces.application.ResourceHandlerWrapper.handleResourceRequest(ResourceHandlerWrapper.java:125)
at javax.faces.application.ResourceHandlerWrapper.handleResourceRequest(ResourceHandlerWrapper.java:125)
at javax.faces.application.ResourceHandlerWrapper.handleResourceRequest(ResourceHandlerWrapper.java:125)
at javax.faces.application.ResourceHandlerWrapper.handleResourceRequest(ResourceHandlerWrapper.java:125)
at javax.faces.application.ResourceHandlerWrapper.handleResourceRequest(ResourceHandlerWrapper.java:125)
at org.icefaces.impl.application.AuxUploadResourceHandler.handleResourceRequest(AuxUploadResourceHandler.java:82)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:591)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:304)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:240)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:164)
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:462)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:164)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:100)
at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:563)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:399)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:317)
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:204)
at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:311)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
Caused by: java.net.SocketException: Software caused connection abort: socket write error
at java.net.SocketOutputStream.socketWrite0(Native Method)
at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:92)
at java.net.SocketOutputStream.write(SocketOutputStream.java:136)
at org.apache.coyote.http11.InternalOutputBuffer.realWriteBytes(InternalOutputBuffer.java:218)
at org.apache.tomcat.util.buf.ByteChunk.flushBuffer(ByteChunk.java:437)
at org.apache.tomcat.util.buf.ByteChunk.append(ByteChunk.java:351)
at org.apache.coyote.http11.InternalOutputBuffer$OutputStreamOutputBuffer.doWrite(InternalOutputBuffer.java:243)
at org.apache.coyote.http11.filters.ChunkedOutputFilter.doWrite(ChunkedOutputFilter.java:119)
at org.apache.coyote.http11.AbstractOutputBuffer.doWrite(AbstractOutputBuffer.java:190)
at org.apache.coyote.Response.doWrite(Response.java:533)
at org.apache.catalina.connector.OutputBuffer.realWriteBytes(OutputBuffer.java:364)
... 40 more
I had a process that sometimes works to recreate the problem:
1) Start Tomcat with showcase fresh - that is, no requests have been made to it yet from any browser.
2) Start IE fresh with cache cleared etc. and open the Developer Tools. If not already, ensure the browser is in Standard document mode (not Quirks mode). Click on the Console panel to view the output.
3) Open the first page of the showcase application (host:port/showcase/showcase.jsf). You should note at this point that the Dev Tools should be showing that you are in Standard document mode as the default for this application.
4) Using the appropriate button in the Dev Tools console, clear the cache. This will ensure that the next request tries to load all the resources from the server again.
5) Click the link for any example example.
At this point, the navigation to the example does a new GET that looks something like this:
showcase.jsf;jsessionid=B2772369057AB2E0B62D66AA02D020EA?grp=aceMenu&exp=dataTableBean
And the Dev Tools console report:
HTML1113: Document mode restart from IE9 Standards to Quirks ->
showcase.jsf;jsessionid=B2772369057AB2E0B62D66AA02D020EA?grp=aceMenu&exp=dataTableBean
So IE is switching to Quirks mode on the fly because the incoming content has no DOCTYPE specified. When it switches to Quirks mode, it aborts all the requests for resources that are currently loading and re-requests everything. It's during this changeover from Standard to Quirks mode that the exceptions can occur. It doesn't happen every time, just depends on the timing. The one thing we do know is that when it does switch to Quirks mode, the layout is no longer acceptable.
So why is the DOCTYPE missing? Good question. My suspects were:
http://java.net/jira/browse/JAVASERVERFACES-2453
http://java.net/jira/browse/JAVASERVERFACES-2575
They fit our profile in that the work was done after 2.1.6 and would show up our current build but not with the old Mojarra.
Bottom line: It's a known bug that's been introduced since around 2.1.8 and is still open. Until it's fixed, we need to sprinkle some DOCTYPEs around our sample app to avoid IE dropping into Quirks mode when we don't want it to. To that end, I've added DOCTYPE entries into the showcase.xhtml and content-template.xhtml files so that during navigation, IE doesn't inadvertently slip into Quirks mode.