ICEfaces
  1. ICEfaces
  2. ICE-8805

Missing DOCTYPE causes browser to revert to Quirks mode and may cause SocketException

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major 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

        Activity

        Hide
        Deryk Sinotte added a comment -

        I'm not seeing any of the reported SocketExceptions running the latest version of showcase app from the trunk, but I do see the formatting issue with IE9 with the subset of component examples.

        The main variable is that this only seems to be a problem in Quirks mode (as set from the IE 9 Developer Tools). When I switch back to IE9 Standards mode, the layout reverts back to normal. I also seems to be related to CSS in that if I modify some of the settings I can get it to layout properly. For example, if I use the IE Developer Tools to modify the following in demo_template.css:

        .container

        { width: 1020px; margin: 0 auto; }

        so that the width is 1200px, the example container renders back into the proper position in Quirks mode.

        Next I reverted to Mojarra 2.1.6 as well the current version of MyFaces and re-ran the showcase, ensuring I cleared the IE cache in between. I saw the same behaviour. Switching to Quirks mode shows the problem, switching back to Standards mode (which is the default when you load the page) allows the layout and rendering to behave as expected.

        I did a quick check of IE8 and IE7 standards modes (using the IE9 Dev Tools) and they render fine as well. So the issue seems to be unrelated to the JSF implementation and related to IE Quirks mode and the showcase application CSS.

        Show
        Deryk Sinotte added a comment - I'm not seeing any of the reported SocketExceptions running the latest version of showcase app from the trunk, but I do see the formatting issue with IE9 with the subset of component examples. The main variable is that this only seems to be a problem in Quirks mode (as set from the IE 9 Developer Tools). When I switch back to IE9 Standards mode, the layout reverts back to normal. I also seems to be related to CSS in that if I modify some of the settings I can get it to layout properly. For example, if I use the IE Developer Tools to modify the following in demo_template.css: .container { width: 1020px; margin: 0 auto; } so that the width is 1200px, the example container renders back into the proper position in Quirks mode. Next I reverted to Mojarra 2.1.6 as well the current version of MyFaces and re-ran the showcase, ensuring I cleared the IE cache in between. I saw the same behaviour. Switching to Quirks mode shows the problem, switching back to Standards mode (which is the default when you load the page) allows the layout and rendering to behave as expected. I did a quick check of IE8 and IE7 standards modes (using the IE9 Dev Tools) and they render fine as well. So the issue seems to be unrelated to the JSF implementation and related to IE Quirks mode and the showcase application CSS.
        Hide
        Deryk Sinotte added a comment -

        I used IE to also hit our online version of showcase:

        http://icefaces-showcase.icesoft.org/showcase.jsf?grp=aceMenu&exp=dateEntry

        and see the same behaviour there so this doesn't appear to be a new behaviour.

        Show
        Deryk Sinotte added a comment - I used IE to also hit our online version of showcase: http://icefaces-showcase.icesoft.org/showcase.jsf?grp=aceMenu&exp=dateEntry and see the same behaviour there so this doesn't appear to be a new behaviour.
        Hide
        Ken Fyten added a comment -

        Art Observes:

        When I started investigating this issue I was using IE9 with browser mode 'Internet Explorer 9' and document mode 'Internet Explorer 9 standards'. Eventually I noticed that the problem started at revision 32182, and that at revision 32181 there was no such problem. After considering Deryk's obvservation that the problem was related to quirks mode. I tested again, and I could see that indeed the problem is only visible in quirks mode, and it disappeared when switching back to standards mode. Then, I wondered why thee browser was switching to quirks mode, since I always have it in standards mode. So, I did some more testing to try to find out.

        I retested everything again, and I could see the exception in the server when using the revision 32182. I switching back and forth from revision 32181 to 32182 a few times, just to make sure it wasn't a coincidence that I started to notice the problem at revision 32182, always clearing the cache and updating the entire code and re-building the full project via 'ant world'. These are some new observations:

        at revision 32181

        • No exceptions happened ever, after navigating to several pages of the ones mentioned in the JIRA (taken from QA's report) and coming back to them.
        • When loading the main page, and opening the IE Developer Tools (by pressing F12), it started in browser mode 'Internet Explorer 9' and document mode 'Internet Explorer 9 standards'. It always stayed like that.
        • When I switched to quirks mode manually, I could see the problem.

        at revision 32182

        • After loading the main page and opening the developer tools, I noticed that the browser automatically switched to quirks mode when navigating to ace:dataTable > Overview. In other words, I opened the showcase main page just after starting the server and then pressed F12 to open the developer tools. I could see that it was in standards mode. Then, after navigating to ace:dataTable > Overview, I noticed that the browser automatically switched to quirks mode. Some times, the browser was already in quirks mode after loading the main page for the first time (while the previous session it was in standards mode)
        • I could see the exception again several times, but it not always happened. If it occurred, it only occurred once. Sometimes it was fired after navigating to ace:dataTable > Overview or other pages, and sometimes it was fired as soon as loading the main page.
        • None of this happened if the first browser to make requests to the server (after it just had been started) was FF or other browser other than IE.

        at the latest revision

        • The exception ever occurred.
        • I could see the browser switching to quirks mode automatically under the same circumstances.

        Can either QA or Deryk confirm this behaviour with these revisions

        I was using tomcat 7.0.14.

        Show
        Ken Fyten added a comment - Art Observes: When I started investigating this issue I was using IE9 with browser mode 'Internet Explorer 9' and document mode 'Internet Explorer 9 standards'. Eventually I noticed that the problem started at revision 32182, and that at revision 32181 there was no such problem. After considering Deryk's obvservation that the problem was related to quirks mode. I tested again, and I could see that indeed the problem is only visible in quirks mode, and it disappeared when switching back to standards mode. Then, I wondered why thee browser was switching to quirks mode, since I always have it in standards mode. So, I did some more testing to try to find out. I retested everything again, and I could see the exception in the server when using the revision 32182. I switching back and forth from revision 32181 to 32182 a few times, just to make sure it wasn't a coincidence that I started to notice the problem at revision 32182, always clearing the cache and updating the entire code and re-building the full project via 'ant world'. These are some new observations: at revision 32181 No exceptions happened ever, after navigating to several pages of the ones mentioned in the JIRA (taken from QA's report) and coming back to them. When loading the main page, and opening the IE Developer Tools (by pressing F12), it started in browser mode 'Internet Explorer 9' and document mode 'Internet Explorer 9 standards'. It always stayed like that. When I switched to quirks mode manually, I could see the problem. at revision 32182 After loading the main page and opening the developer tools, I noticed that the browser automatically switched to quirks mode when navigating to ace:dataTable > Overview. In other words, I opened the showcase main page just after starting the server and then pressed F12 to open the developer tools. I could see that it was in standards mode. Then, after navigating to ace:dataTable > Overview, I noticed that the browser automatically switched to quirks mode. Some times, the browser was already in quirks mode after loading the main page for the first time (while the previous session it was in standards mode) I could see the exception again several times, but it not always happened. If it occurred, it only occurred once. Sometimes it was fired after navigating to ace:dataTable > Overview or other pages, and sometimes it was fired as soon as loading the main page. None of this happened if the first browser to make requests to the server (after it just had been started) was FF or other browser other than IE. at the latest revision The exception ever occurred. I could see the browser switching to quirks mode automatically under the same circumstances. Can either QA or Deryk confirm this behaviour with these revisions I was using tomcat 7.0.14.
        Hide
        Arturo Zambrano added a comment -

        Yes, it seems to me like this could have been an existing condition and it just became visible after the Mojarra upgrade.

        The weird thing is that the switch to quirks mode doesn't always happen, although it happens most of the time. Also, the exception is not always thrown either, but when it is thrown, the switch to quirks mode occurs. However, the switch to quirks mode can happen with or without the exception.

        This only happens if IE is the very first browser to access the application after the browser starts. If another browser accesses the application first, and then you access the application with IE, you won't see these problems in IE nor exceptions in the server console.

        I just attached two screenshots of the network activity in IE under revisions 32181 and 32182. You can see there that in the case of 32182 two requests are made for the same resource, while in 32181, only one request is made. The way I captured this was by clearing the cache, and restarting the server, then accessing the application with IE9. I opened the developer tools window and made sure that when loading the main page it was in standards mode. Then, started to capture the network activity and navigated to ace:dataTable > Overview. In the case of 32182, it switched to quirks mode and you could see that an additional request was made for the same set of resources.

        Show
        Arturo Zambrano added a comment - Yes, it seems to me like this could have been an existing condition and it just became visible after the Mojarra upgrade. The weird thing is that the switch to quirks mode doesn't always happen, although it happens most of the time. Also, the exception is not always thrown either, but when it is thrown, the switch to quirks mode occurs. However, the switch to quirks mode can happen with or without the exception. This only happens if IE is the very first browser to access the application after the browser starts. If another browser accesses the application first, and then you access the application with IE, you won't see these problems in IE nor exceptions in the server console. I just attached two screenshots of the network activity in IE under revisions 32181 and 32182. You can see there that in the case of 32182 two requests are made for the same resource, while in 32181, only one request is made. The way I captured this was by clearing the cache, and restarting the server, then accessing the application with IE9. I opened the developer tools window and made sure that when loading the main page it was in standards mode. Then, started to capture the network activity and navigated to ace:dataTable > Overview. In the case of 32182, it switched to quirks mode and you could see that an additional request was made for the same set of resources.
        Hide
        Deryk Sinotte added a comment -

        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.

        Show
        Deryk Sinotte added a comment - 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.

          People

          • Assignee:
            Deryk Sinotte
            Reporter:
            Arturo Zambrano
          • Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: