Details
-
Type:
Bug
-
Status: Closed
-
Priority:
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
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
Activity
- All
- Comments
- History
- Activity
- Remote Attachments
- Subversion
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?
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.
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.
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
The original reported issues are resolved. The apparent DOM diff issue will be further analyzed under a new JIRA (ICE-8502).
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.
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.
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.
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.
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
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).
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.
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.