MyFaces Trinidad
  1. MyFaces Trinidad
  2. TRINIDAD-1171

A failing client-side validator while using PPR causes a page hang with hourglass in IE when clicking in a empty spot on the page

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Won't Fix
    • Affects Version/s: 1.0.7-core, 1.0.8-core, 1.0.9-core
    • Fix Version/s: None
    • Component/s: Components
    • Labels:
      None
    • Environment:
      Windows IE6 and IE7

      Description

      Code to reproduce:

      <tr:form id="testValidationForm">
      <tr:inputDate value="#

      {test.myDate}

      " id="myDate" partialTriggers="validate">
      <tr:convertDateTime pattern="dd-MM-yyyy" />
      </tr:inputDate>
      <tr:commandButton text="Validate" partialSubmit="true" id="validate" />
      </tr:form>

      Steps to reproduce:
      1. fill in something in the date field so the (date) validation will fail (eg. "hello")
      2. press "Validate"
      3. Now click on a spot on the page (but within the body area)

      Now the hourglass shows in IE. The only way to get rid of it is to click outside the body of the page of on the toolbar of IE.

      I traced the problem back to bug TRINIDAD-952 whose fix is causing the problem, after reverting the change everything works ok in 1.0.8 .

      1. TrinidadJira1171Validation.war
        6.51 MB
        Mark van den Boomen
      2. Trinidad-1.0.8_revert_TRINIDAD-952
        0.9 kB
        Mark van den Boomen

        Issue Links

          Activity

          Hide
          Mark van den Boomen added a comment - - edited

          Added a patch for reverting the change from TRINIDAD-952

          Show
          Mark van den Boomen added a comment - - edited Added a patch for reverting the change from TRINIDAD-952
          Hide
          Mark van den Boomen added a comment -

          The patch for TRINIDAD-952 causes the problem.

          Show
          Mark van den Boomen added a comment - The patch for TRINIDAD-952 causes the problem.
          Hide
          Mark van den Boomen added a comment -

          Looks like TRINIDAD-1029 is related and maybe even the same problem

          Show
          Mark van den Boomen added a comment - Looks like TRINIDAD-1029 is related and maybe even the same problem
          Hide
          Andrew Robinson added a comment -

          I cannot reproduce this problem with 1.2.10-SNAPSHOT. I tested on IE7 on windows and IE6 on WINE. I never got the hourglass to appear. Can the reported please verify that it does not work still in 1.2.10, and if so, please either (1) submit a diff file to reproduce the issue in the trinidad-demo or (2) submit a simple test project to reproduce the issue? Here the my test page that I used and ran it inside of jetty with the trinidad-demo project:

          <?xml version='1.0' encoding='UTF-8'?>
          <jsp:root xmlns:jsp="http://java.sun.com/JSP/Page" version="2.1"
          xmlns:f="http://java.sun.com/jsf/core"
          xmlns:h="http://java.sun.com/jsf/html"
          xmlns:trh="http://myfaces.apache.org/trinidad/html"
          xmlns:tr="http://myfaces.apache.org/trinidad">
          <jsp:output omit-xml-declaration="true" doctype-root-element="HTML"
          doctype-system="http://www.w3.org/TR/html4/loose.dtd"
          doctype-public="-//W3C//DTD HTML 4.01 Transitional//EN"/>
          <jsp:directive.page contentType="text/html;charset=UTF-8"/>
          <f:view>
          <html>
          <head>
          <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
          <title>untitled1</title>
          </head>
          <body>
          <tr:form id="testValidationForm">
          <tr:inputDate value="#

          {requestScope.myDate}

          " id="myDate" partialTriggers="validate">
          <tr:convertDateTime pattern="dd-MM-yyyy"/>
          </tr:inputDate>
          <tr:commandButton text="Validate" partialSubmit="true" id="validate"/>
          </tr:form>
          </body>
          </html>
          </f:view>
          </jsp:root>

          Show
          Andrew Robinson added a comment - I cannot reproduce this problem with 1.2.10-SNAPSHOT. I tested on IE7 on windows and IE6 on WINE. I never got the hourglass to appear. Can the reported please verify that it does not work still in 1.2.10, and if so, please either (1) submit a diff file to reproduce the issue in the trinidad-demo or (2) submit a simple test project to reproduce the issue? Here the my test page that I used and ran it inside of jetty with the trinidad-demo project: <?xml version='1.0' encoding='UTF-8'?> <jsp:root xmlns:jsp="http://java.sun.com/JSP/Page" version="2.1" xmlns:f="http://java.sun.com/jsf/core" xmlns:h="http://java.sun.com/jsf/html" xmlns:trh="http://myfaces.apache.org/trinidad/html" xmlns:tr="http://myfaces.apache.org/trinidad"> <jsp:output omit-xml-declaration="true" doctype-root-element="HTML" doctype-system="http://www.w3.org/TR/html4/loose.dtd" doctype-public="-//W3C//DTD HTML 4.01 Transitional//EN"/> <jsp:directive.page contentType="text/html;charset=UTF-8"/> <f:view> <html> <head> <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/> <title>untitled1</title> </head> <body> <tr:form id="testValidationForm"> <tr:inputDate value="# {requestScope.myDate} " id="myDate" partialTriggers="validate"> <tr:convertDateTime pattern="dd-MM-yyyy"/> </tr:inputDate> <tr:commandButton text="Validate" partialSubmit="true" id="validate"/> </tr:form> </body> </html> </f:view> </jsp:root>
          Hide
          Mark van den Boomen added a comment -

          Hi Andrew,

          Here's a test project resulting in the bug. The problem happens when a client-side validator triggers and shows his message, when you try to correct the wrong value the hourglass shows. Just deploy and navigate to /faces/testValidation.jsp. The java source in the 'Test'-class is of no importance it just contains a getter and a (dummy) setter for a date.

          I also tried to use 1.0.10-SNAPSHOT but the bug is still present.

          Btw sorry for the late response.

          Show
          Mark van den Boomen added a comment - Hi Andrew, Here's a test project resulting in the bug. The problem happens when a client-side validator triggers and shows his message, when you try to correct the wrong value the hourglass shows. Just deploy and navigate to /faces/testValidation.jsp. The java source in the 'Test'-class is of no importance it just contains a getter and a (dummy) setter for a date. I also tried to use 1.0.10-SNAPSHOT but the bug is still present. Btw sorry for the late response.
          Hide
          Richard added a comment - - edited

          Hello
          This is a recurring problem in our environment on IE. I can reliably reproduce this error using the sample JSP provided. @see TRINIDAD-1029 and TRINIDAD-1061 as well.

          Show
          Richard added a comment - - edited Hello This is a recurring problem in our environment on IE. I can reliably reproduce this error using the sample JSP provided. @see TRINIDAD-1029 and TRINIDAD-1061 as well.
          Hide
          Mark van den Boomen added a comment -

          Another way of reproducing the problem by using the live demo's:

          1. open http://www.irian.at/trinidad-demo/faces/components/inputDate.jspx in Internet Explorer 6 or 7
          2. check the 'autosubmit' from the properties pane and press 'update'
          3. fill in a non valid value for the date in the upper most inputDate (eg. 'hang!')
          4. tab out of the field or click next to it.
          5. because of the autosubmit a error message is shown
          6. now click in the textfield of the inputDate (to fix the wrong date)

          The IE should now show a hourglass as pointer and the application doesn't respond anymore. The only way to get rid of the hourglass is to click on the titlebar, menu- or statusbar of IE.

          Show
          Mark van den Boomen added a comment - Another way of reproducing the problem by using the live demo's: 1. open http://www.irian.at/trinidad-demo/faces/components/inputDate.jspx in Internet Explorer 6 or 7 2. check the 'autosubmit' from the properties pane and press 'update' 3. fill in a non valid value for the date in the upper most inputDate (eg. 'hang!') 4. tab out of the field or click next to it. 5. because of the autosubmit a error message is shown 6. now click in the textfield of the inputDate (to fix the wrong date) The IE should now show a hourglass as pointer and the application doesn't respond anymore. The only way to get rid of the hourglass is to click on the titlebar, menu- or statusbar of IE.
          Hide
          Markus Krätzig added a comment -

          I guess the reason for the blocking is the following:

          Taking off _doPprStartBlocking from the current thread via

          a0._pprTimeoutFunc=a0.setTimeout("_doPprStartBlocking(window);",1);

          in function _pprStartBlocking leads in function _submitPartialChange to the situation
          where

          _pprStartBlocking(window);
          var a3=submitForm(a0,a1,a2,true);
          _pprStopBlocking(window);

          is not called in the order expected, instead, startBlocking is called after stopBlocking due
          to the timeout. The only way to release the blocking is then via _pprConsumeClick, for which the user
          must click outside the body area.

          The simplest way to fix this is to revert TRINIDAD-952. If the timeout should be kept in, then
          the threads must somehow be synchronized. But as far as I know there's not much provided by
          javascript to do this.

          I think fixing this issue should be prioritized, because it renders TRINIDAD pretty useless on all IE versions.

          Show
          Markus Krätzig added a comment - I guess the reason for the blocking is the following: Taking off _doPprStartBlocking from the current thread via a0._pprTimeoutFunc=a0.setTimeout("_doPprStartBlocking(window);",1); in function _pprStartBlocking leads in function _submitPartialChange to the situation where _pprStartBlocking(window); var a3=submitForm(a0,a1,a2,true); _pprStopBlocking(window); is not called in the order expected, instead, startBlocking is called after stopBlocking due to the timeout. The only way to release the blocking is then via _pprConsumeClick, for which the user must click outside the body area. The simplest way to fix this is to revert TRINIDAD-952 . If the timeout should be kept in, then the threads must somehow be synchronized. But as far as I know there's not much provided by javascript to do this. I think fixing this issue should be prioritized, because it renders TRINIDAD pretty useless on all IE versions.
          Hide
          komarios added a comment -

          Hello Markus,
          For our organization it is an important issue and easily reproducible, though we were not able to pinpoint the exact conditions on which it occurs. Some pcs do it, some don't.
          I would appreciate it if you could fix this bug once again in the current version, or at least provide a workaround.
          Thanks a lot for the good job you are doing.

          Show
          komarios added a comment - Hello Markus, For our organization it is an important issue and easily reproducible, though we were not able to pinpoint the exact conditions on which it occurs. Some pcs do it, some don't. I would appreciate it if you could fix this bug once again in the current version, or at least provide a workaround. Thanks a lot for the good job you are doing.
          Hide
          Wojciech Górski added a comment -

          Unfortunatelly this problem still exists in version 1.0.13. We have successfully applied the enclosed patch and it works, but it reverts the TRINIDAD-952 bugfix, which is also regarded as a blocker. Also, deploying a patched jar file which is not officially released is not acceptable for our client.
          As Markus already said, this issue should be given a higher priority, because it is a blocker on all IE versions. When are you planning to release a fix or at least a workaround for this bug?

          Show
          Wojciech Górski added a comment - Unfortunatelly this problem still exists in version 1.0.13. We have successfully applied the enclosed patch and it works, but it reverts the TRINIDAD-952 bugfix, which is also regarded as a blocker. Also, deploying a patched jar file which is not officially released is not acceptable for our client. As Markus already said, this issue should be given a higher priority, because it is a blocker on all IE versions. When are you planning to release a fix or at least a workaround for this bug?
          Hide
          Scott O'Bryan added a comment -

          MyFaces 1.0.13 is no longer an active development branch. Furthermore, if this reverts another fix, I'm not sure that we can use it. People currently working with already released branches count on the fix being there.

          Is it possible to code this patch so that it works with BOTH versions?

          Show
          Scott O'Bryan added a comment - MyFaces 1.0.13 is no longer an active development branch. Furthermore, if this reverts another fix, I'm not sure that we can use it. People currently working with already released branches count on the fix being there. Is it possible to code this patch so that it works with BOTH versions?
          Hide
          Scott O'Bryan added a comment -

          Trinidad Version 1.0.x branches are no longer maintained and this patch reverts a previous fix which has already been released. My suggestion for applying this fix to 1.0.13 is to take the branch and apply the fix manually.

          Show
          Scott O'Bryan added a comment - Trinidad Version 1.0.x branches are no longer maintained and this patch reverts a previous fix which has already been released. My suggestion for applying this fix to 1.0.13 is to take the branch and apply the fix manually.
          Hide
          Scott O'Bryan added a comment -

          This issue is now closed

          Show
          Scott O'Bryan added a comment - This issue is now closed

            People

            • Assignee:
              Unassigned
              Reporter:
              Mark van den Boomen
            • Votes:
              7 Vote for this issue
              Watchers:
              8 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development