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. File
              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

              Ascending order - Click to sort in descending order
              Cruz Miraback created issue -
              Cruz Miraback made changes -
              Field Original Value New Value
              Salesforce Case []
              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


              		 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
              Cruz Miraback made changes -
              Summary Unable to clear dateTimeEntry popup calendar input ACE:DateTimeEntry - Unable to clear popup calendar input
              Salesforce Case []
              Cruz Miraback made changes -
              Summary ACE:DateTimeEntry - Unable to clear popup calendar input REGRESSION: ACE:DateTimeEntry - Unable to clear popup calendar input
              Salesforce Case []
              Ken Fyten made changes -
              Salesforce Case []
              Fix Version/s EE-3.0.0.GA_P01 [ 10327 ]
              Assignee Priority P1
              Assignee Mircea Toma [ mircea.toma ]
              Hide
              Permalink
              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.
              Mircea Toma made changes -
              Status Open [ 1 ] Resolved [ 5 ]
              Resolution Invalid [ 6 ]
              Mircea Toma made changes -
              Resolution Invalid [ 6 ]
              Status Resolved [ 5 ] Reopened [ 4 ]
              Mircea Toma made changes -
              Status Reopened [ 4 ] Resolved [ 5 ]
              Resolution Invalid [ 6 ]
              Ken Fyten made changes -
              Salesforce Case []
              Assignee Mircea Toma [ mircea.toma ] yip.ng [ yip.ng ]
              Hide
              Permalink
              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).
              Ken Fyten made changes -
              Resolution Invalid [ 6 ]
              Status Resolved [ 5 ] Reopened [ 4 ]
              Hide
              Permalink
              yip.ng added a comment -

              Same problems in icefaces3/trunk.

              Show
              yip.ng added a comment - Same problems in icefaces3/trunk.
              Ken Fyten made changes -
              Salesforce Case []
              Fix Version/s 3.2 [ 10338 ]
              Hide
              Permalink
              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
              Ken Fyten made changes -
              Salesforce Case []
              Affects Version/s 3.1 [ 10312 ]
              Repository Revision Date User Message
              ICEsoft Public SVN Repository #30544 Fri Aug 17 10:31:01 MDT 2012 yip.ng ICE-8467: REGRESSION: ACE:DateTimeEntry - Unable to clear popup calendar input.
              Files Changed
              Commit graph MODIFY /icefaces3/trunk/icefaces/ace/component/src/org/icefaces/ace/component/datetimeentry/DateTimeEntryMeta.java
              Repository Revision Date User Message
              ICEsoft Public SVN Repository #30545 Fri Aug 17 10:32:25 MDT 2012 yip.ng ICE-8467: REGRESSION: ACE:DateTimeEntry - Unable to clear popup calendar input.
              Files Changed
              Commit graph MODIFY /icefaces3/branches/icefaces-3.0.x-maintenance/icefaces/ace/component/src/org/icefaces/ace/component/datetimeentry/DateTimeEntryMeta.java
              Hide
              Permalink
              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
              Permalink
              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 .
              yip.ng made changes -
              Attachment screenshot-01.png [ 14812 ]
              yip.ng made changes -
              Attachment screenshot-02.png [ 14813 ]
              Hide
              Permalink
              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
              Permalink
              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.
              Repository Revision Date User Message
              ICEsoft Public SVN Repository #30586 Thu Aug 23 09:43:50 MDT 2012 ken.fyten ICE-8467 - Isolate the ace:dateTimeEntry from the singleSubmit tag so that expected behavior is observed when editing the input field directly.
              Files Changed
              Commit graph MODIFY /icefaces3/branches/icefaces-3.0.x-maintenance/icefaces/samples/showcase/showcase/src/main/webapp/resources/examples/ace/date/datepopup.xhtml
              Hide
              Permalink
              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).
              Ken Fyten made changes -
              Status Reopened [ 4 ] Resolved [ 5 ]
              Resolution Fixed [ 1 ]
              Repository Revision Date User Message
              ICEsoft Public SVN Repository #30658 Fri Aug 31 16:01:23 MDT 2012 yip.ng Reverted ICE-8467. Caused regression ICE-8508.
              Files Changed
              Commit graph MODIFY /icefaces3/trunk/icefaces/ace/component/src/org/icefaces/ace/component/datetimeentry/DateTimeEntryMeta.java
              Repository Revision Date User Message
              ICEsoft Public SVN Repository #30659 Fri Aug 31 16:02:31 MDT 2012 yip.ng Reverted ICE-8467. Caused regression ICE-8508.
              Files Changed
              Commit graph MODIFY /icefaces3/branches/icefaces-3.0.x-maintenance/icefaces/ace/component/src/org/icefaces/ace/component/datetimeentry/DateTimeEntryMeta.java
              Hide
              Permalink
              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
              yip.ng made changes -
              Resolution Fixed [ 1 ]
              Status Resolved [ 5 ] Reopened [ 4 ]
              Hide
              Permalink
              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.
              yip.ng made changes -
              Attachment screenshot-03.png [ 14858 ]
              Hide
              Permalink
              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
              Permalink
              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
              Permalink
              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.
              Ken Fyten made changes -
              Attachment calendarAttribute.xhtml [ 14863 ]
              Ken Fyten made changes -
              Status Reopened [ 4 ] Resolved [ 5 ]
              Resolution Fixed [ 1 ]
              Ken Fyten made changes -
              Status Resolved [ 5 ] Closed [ 6 ]
              Assignee Priority P1 [ 10010 ]

                People

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

                  Dates

                  • Created:
                    Updated:
                    Resolved: