ICEfaces
  1. ICEfaces
  2. ICE-8467

REGRESSION: ACE:DateTimeEntry - Unable to clear popup calendar input

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 3.1, EE-3.0.0.GA_P01
    • Fix Version/s: EE-3.0.0.GA_P01, 3.2
    • Component/s: ACE-Components
    • Labels:
      None
    • Environment:
      icefaces-3.0.x-maintenance revision# 30501
      Last passing revision# 30469
      Browser: IE, Chrome, Firefox

      Description

      Clearing the dateTimeEntry input of a popup calendar and submitting the field causes the input to automatically repopulate it's value with the value that was present before clearing the field.

      Tests are located at: http://server.ice:8888/svn/repo/qa/trunk/Regression-Icefaces2/Sparkle/Nightly/dateTimeEntry

      To reproduce:
      1. Build / deploy test app
      2. Navigate to '/calendarAttribute.jsf'
      3. Clear the dateTimeEntry input field and push enter
      Notice the value of the dateTimeEntry returns
      1. calendarAttribute.xhtml
        6 kB
        Ken Fyten
      1. screenshot-01.png
        203 kB
      2. screenshot-02.png
        204 kB
      3. screenshot-03.png
        152 kB

        Activity

        Hide
        Mircea Toma added a comment -

        I can see a difference in behaviour between IE+Chrome+Safari versus Firefox. In Firefox the cleared value is put back after enter key is pressed while in the other browsers the input remains empty.

        On the other hand I don't see any difference in behaviour between revision 30469 and current trunk, when using the same browser.

        Show
        Mircea Toma added a comment - I can see a difference in behaviour between IE+Chrome+Safari versus Firefox. In Firefox the cleared value is put back after enter key is pressed while in the other browsers the input remains empty. On the other hand I don't see any difference in behaviour between revision 30469 and current trunk, when using the same browser.
        Hide
        Cruz Miraback added a comment -

        Something to note...

        Even though the field clears in IE / Chrome...If setting the 'required' attribute to true and submitting the empty field, the required message is never displayed. If submitting the empty field again the text date returns (just like in Firefox).

        Show
        Cruz Miraback added a comment - Something to note... Even though the field clears in IE / Chrome...If setting the 'required' attribute to true and submitting the empty field, the required message is never displayed. If submitting the empty field again the text date returns (just like in Firefox).
        Hide
        yip.ng added a comment -

        Same problems in icefaces3/trunk.

        Show
        yip.ng added a comment - Same problems in icefaces3/trunk.
        Hide
        yip.ng added a comment - - edited

        Firefox issue:
        Submit with empty value is done (by framework?) when ENTER key pressed, but it seems setValue() is never called. Seems you need to override setValue (by adding value property in meta class) in order for it to be called.

        Modified: C:\svn\ossrepo\icefaces3\trunk\icefaces\ace\component\src\org\icefaces\ace\component\datetimeentry\DateTimeEntryMeta.java
        Completed: At revision: 30544

        Modified: C:\svn\ossrepo\icefaces3\branches\icefaces-3.0.x-maintenance\icefaces\ace\component\src\org\icefaces\ace\component\datetimeentry\DateTimeEntryMeta.java
        Completed: At revision: 30545

        Show
        yip.ng added a comment - - edited Firefox issue: Submit with empty value is done (by framework?) when ENTER key pressed, but it seems setValue() is never called. Seems you need to override setValue (by adding value property in meta class) in order for it to be called. Modified: C:\svn\ossrepo\icefaces3\trunk\icefaces\ace\component\src\org\icefaces\ace\component\datetimeentry\DateTimeEntryMeta.java Completed: At revision: 30544 Modified: C:\svn\ossrepo\icefaces3\branches\icefaces-3.0.x-maintenance\icefaces\ace\component\src\org\icefaces\ace\component\datetimeentry\DateTimeEntryMeta.java Completed: At revision: 30545
        Hide
        yip.ng added a comment - - edited

        When required is true, FF displays required message when submitting empty field, but if submitting empty field again has the same problem as IE: text date returns.

        Show
        yip.ng added a comment - - edited When required is true, FF displays required message when submitting empty field, but if submitting empty field again has the same problem as IE: text date returns.
        Hide
        yip.ng added a comment - - edited

        Problem "If submitting the empty field again the text date returns":

        This is intended behavior. Date picker listens to the Enter key event. When input is changed from something to nothing. It deselects the selected date.

        Otherwise when you press Enter while the popup is showing, it will select the highlighted date. The highlighted date can be changed by keyboard shortcuts. When a popup opens on an empty field, the highlighted date is preset by a config. param or the default of today. In all cases a date will be selected when you press Enter. The only way to not select a date is close the popup first.

        See this minimalistic example without any framework interference: http://screencast.com/t/uYKicbqfy7eD.

        Show
        yip.ng added a comment - - edited Problem "If submitting the empty field again the text date returns": This is intended behavior. Date picker listens to the Enter key event. When input is changed from something to nothing. It deselects the selected date. Otherwise when you press Enter while the popup is showing, it will select the highlighted date. The highlighted date can be changed by keyboard shortcuts. When a popup opens on an empty field, the highlighted date is preset by a config. param or the default of today. In all cases a date will be selected when you press Enter. The only way to not select a date is close the popup first. See this minimalistic example without any framework interference: http://screencast.com/t/uYKicbqfy7eD .
        Hide
        yip.ng added a comment - - edited

        Problem "required message is never displayed":

        Two causes:

        1. render attribute of ajax event should include component itself and message component as well. See screenshot-01.png.

        Modified: C:\svn\repo\qa\trunk\Regression-Icefaces2\Sparkle\Nightly\dateTimeEntry\web\calendarAttribute.xhtml
        Completed: At revision: 32084

        2. "SEVERE" error in DOM diff. See screenshot-02.png.

        Show
        yip.ng added a comment - - edited Problem "required message is never displayed": Two causes: 1. render attribute of ajax event should include component itself and message component as well. See screenshot-01.png. Modified: C:\svn\repo\qa\trunk\Regression-Icefaces2\Sparkle\Nightly\dateTimeEntry\web\calendarAttribute.xhtml Completed: At revision: 32084 2. "SEVERE" error in DOM diff. See screenshot-02.png.
        Hide
        Mark Collette added a comment -

        I updated all my code and ran the test and duplicated the problem where the DOM differencing complains about the severe error. I then turned on source and debugAB diff debugging.

        source:

        Aug 22, 2012 10:28:09 AM org.icefaces.impl.util.DOMUtils debugNameDifference
        INFO: <#document>[0]<html>[1]<body>[5]<form id="calForm2">[10]<div id="calForm2:calendar3Msgs">[0]<div id="calForm2:calendar3Msgs">[0]<ul id="calForm2:calendar3Msgs"> :: Name changed from 'div' to 'ul'. Examine attributes:
        Old: Attributes: 1
        [0] id="calForm2:calendar3Msgs"
        New: Attributes: 1
        [0] id="calForm2:calendar3Msgs"

        We can see that there are several levels of markup all using the same id of "calForm2:calendar3Msgs", and in this case one of the levels has changed from a div tag to a ul tag.

        debugAB:

        element[tag: div; attributes: id=calForm2:calendar3Msgs ]
        element[tag: div; attributes: id=calForm2:calendar3Msgs ]
        element[tag: ul; attributes: id=calForm2:calendar3Msgs ]
        element[tag: li; attributes: ]
        text[ ]
        text[Validator message from validatorMessage attribute: ***validation failed***]
        text[ ]
        ---------
        element[tag: div; attributes: id=calForm2:calendar3Msgs ]
        element[tag: ul; attributes: id=calForm2:calendar3Msgs ]
        element[tag: li; attributes: ]
        text[ ]
        text[Validator message from validatorMessage attribute: ***validation failed***]
        text[ ]

        Here we get the full picture, of the multiple levels of elements all with the same id. And the levels seem to change over time, in this case losing a level of div.

        Checking the application there is no panelGroup with a duplicate id to the h:messages, so that leaves a bug in either our overriding of the h:messages rendering, or in DOMResponseWriter's cursor management.

        Show
        Mark Collette added a comment - I updated all my code and ran the test and duplicated the problem where the DOM differencing complains about the severe error. I then turned on source and debugAB diff debugging. source: Aug 22, 2012 10:28:09 AM org.icefaces.impl.util.DOMUtils debugNameDifference INFO: <#document> [0] <html> [1] <body> [5] <form id="calForm2"> [10] <div id="calForm2:calendar3Msgs"> [0] <div id="calForm2:calendar3Msgs"> [0] <ul id="calForm2:calendar3Msgs"> :: Name changed from 'div' to 'ul'. Examine attributes: Old: Attributes: 1 [0] id="calForm2:calendar3Msgs" New: Attributes: 1 [0] id="calForm2:calendar3Msgs" We can see that there are several levels of markup all using the same id of "calForm2:calendar3Msgs", and in this case one of the levels has changed from a div tag to a ul tag. debugAB: element [tag: div; attributes: id=calForm2:calendar3Msgs ] element [tag: div; attributes: id=calForm2:calendar3Msgs ] element [tag: ul; attributes: id=calForm2:calendar3Msgs ] element [tag: li; attributes: ] text[ ] text [Validator message from validatorMessage attribute: ***validation failed***] text[ ] --------- element [tag: div; attributes: id=calForm2:calendar3Msgs ] element [tag: ul; attributes: id=calForm2:calendar3Msgs ] element [tag: li; attributes: ] text[ ] text [Validator message from validatorMessage attribute: ***validation failed***] text[ ] Here we get the full picture, of the multiple levels of elements all with the same id. And the levels seem to change over time, in this case losing a level of div. Checking the application there is no panelGroup with a duplicate id to the h:messages, so that leaves a bug in either our overriding of the h:messages rendering, or in DOMResponseWriter's cursor management.
        Hide
        Ken Fyten added a comment - - edited

        The original reported issues are resolved. The apparent DOM diff issue will be further analyzed under a new JIRA (ICE-8502).

        Show
        Ken Fyten added a comment - - edited The original reported issues are resolved. The apparent DOM diff issue will be further analyzed under a new JIRA (ICE-8502).
        Hide
        yip.ng added a comment -

        Reverted adding value property to meta class. Caused regression in ICE-8508. Need to find another fix. Re-opened.

        Modified: C:\svn\ossrepo\icefaces3\trunk\icefaces\ace\component\src\org\icefaces\ace\component\datetimeentry\DateTimeEntryMeta.java
        Completed: At revision: 30658

        Modified: C:\svn\ossrepo\icefaces3\branches\icefaces-3.0.x-maintenance\icefaces\ace\component\src\org\icefaces\ace\component\datetimeentry\DateTimeEntryMeta.java
        Completed: At revision: 30659

        Show
        yip.ng added a comment - Reverted adding value property to meta class. Caused regression in ICE-8508. Need to find another fix. Re-opened. Modified: C:\svn\ossrepo\icefaces3\trunk\icefaces\ace\component\src\org\icefaces\ace\component\datetimeentry\DateTimeEntryMeta.java Completed: At revision: 30658 Modified: C:\svn\ossrepo\icefaces3\branches\icefaces-3.0.x-maintenance\icefaces\ace\component\src\org\icefaces\ace\component\datetimeentry\DateTimeEntryMeta.java Completed: At revision: 30659
        Hide
        yip.ng added a comment - - edited

        Not working as claimed at rev. 30469, neither trunk nor maintenance branch.

        Works if I minimalize the test page to just contain the calendar itself. See video: http://screencast.com/t/NvQggYPvn. Something else on the page (lots of other things on the page) is causing the problem?

        It's caused by another input field on the test page. See screenshot-03.png.

        Show
        yip.ng added a comment - - edited Not working as claimed at rev. 30469, neither trunk nor maintenance branch. Works if I minimalize the test page to just contain the calendar itself. See video: http://screencast.com/t/NvQggYPvn . Something else on the page (lots of other things on the page) is causing the problem? It's caused by another input field on the test page. See screenshot-03.png.
        Hide
        yip.ng added a comment -

        From Cruz:

        Behaviour In Firefox 3.6 at revision# 30469 with required = true:
        Clearing the calendar input field and pushing enter causes the required message to be displayed and the field to be cleared.

        Behaviour In Firefox 3.6 at revision# 30514 with required = true:
        Clearing the calendar input field and pushing enter does not cause the required message to be displayed because the field is not cleared.

        Show
        yip.ng added a comment - From Cruz: Behaviour In Firefox 3.6 at revision# 30469 with required = true: Clearing the calendar input field and pushing enter causes the required message to be displayed and the field to be cleared. Behaviour In Firefox 3.6 at revision# 30514 with required = true: Clearing the calendar input field and pushing enter does not cause the required message to be displayed because the field is not cleared.
        Hide
        Ken Fyten added a comment -

        Behaviour In Firefox 3.6 at revision# 30514 with required = true:
        Clearing the calendar input field and pushing enter does not cause the required message to be displayed because the field is not cleared.

        This is fine. It's not possible to remove a previously entered value in JSF on a "required" value.

        Does it clear okay if required=false?

        Show
        Ken Fyten added a comment - Behaviour In Firefox 3.6 at revision# 30514 with required = true: Clearing the calendar input field and pushing enter does not cause the required message to be displayed because the field is not cleared. This is fine. It's not possible to remove a previously entered value in JSF on a "required" value. Does it clear okay if required=false?
        Hide
        Ken Fyten added a comment -

        Attached fixed calendarAttribute.xhtml file.

        The fixes for this test are to include the "output" outputText component in the form with the ace:dateTimeEntry, and to limit the execution of the ace:dateTimeEntry on top to itself, to avoid constantly failing due to the empty "required=true" ace:dateTimeEntry at the bottom.

        Might want to consider removing the bottom ace:dateTimeEntry altogether, or moving into a page of it's own.

        Show
        Ken Fyten added a comment - Attached fixed calendarAttribute.xhtml file. The fixes for this test are to include the "output" outputText component in the form with the ace:dateTimeEntry, and to limit the execution of the ace:dateTimeEntry on top to itself, to avoid constantly failing due to the empty "required=true" ace:dateTimeEntry at the bottom. Might want to consider removing the bottom ace:dateTimeEntry altogether, or moving into a page of it's own.

          People

          • Assignee:
            yip.ng
            Reporter:
            Cruz Miraback
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: