Some observations so far:

• This issue is not reproducible on a servlet environment.

• The issue (not sending an ajax request when tabbing out) occurs after the very first ajax request done by the component, whether it was triggered by tabbing out of the text field or by clicking on a date on the calendar. In other words, it's not related to the validation error.

• This seems to be a client-side only issue, where the onblur event listener is not working after the first time.

• After the first ajax request the entire component markup is updated, but it seems like the onblur event is not applied correctly.

I noticed that the scripts (i.e. inside <script> tags) with which the component is rendered when the page is loaded and the scripts with which the component is rendered after the first ajax update are slightly different. It seems like Liferay minifies the Javascript code when the page is loaded, but not on subsequent ajax requests. I don't know if this has anything to do with the issue.

Hi Arturo,

In order to see if this was a problem specifically with Liferay Portal, I deployed a pluto-specific version of the portlet to Apache Pluto. Sadly I wasn't able to try the test for this issue because I ran into another issue: ICE-10968. Just a thought, but focusing on solving ICE-10968 might help this issue move along as well.

Neil

r47950: moved onchange event setup before call to re-initialize component in client

This issue occurred simply because the onchange event wasn't being re-registered when the component was re-initialized. The code seemed too assume that there were not going to be full markup updates for the component, and, on Liferay, the full component markup was being updated at every request initiated by the component itself.

This issue could also be reproduced on a servlet environment by having the component's 'rendered' attribute bound to a boolean property, which in turn is also bound to a checkbox, to control it. After undrendering and then rendering the component again, the onchange ajax event was never triggered again.

ICEfaces4 trunk r47959: ran QA dateTimeEntry regressions (FF41, Chrome48, IE11), and showcase > dateTimeEntry tests (FF41, IE11), no issues found.

Jenkins ICEfaces 4.1.1 Build #6: ran QA dateTimeEntry regressions, and showcase > dateTimeEntry tests (FF41, IE11, Chrome48), no issues found.

Verified ICEfaces 4.1.1 Jenkins Build 6 (using liferay-faces-4.2.5.jar) with attached test case on Liferay 6.2/ Tomcat7.0.42, on FF41, Chrome48, IE11.

At step7, when entering an invalid date and pressing TAB, the field does not become red, however in the logs, the UPDATE_MODEL_VALUES and INVOKE_APPLICATION phases are skipped. On submit, an "Invalid date format" message is rendered on page.

Attaching test case used to verify this JIRA, using icefaces*-4.1.1 and liferay-faces*-4.2.5 jars.

Adding the liferay-faces-alloy-4.2.5-ga6.jar to the icefaces4-portlet-4.1.1.war test case fixes the dateTimeEntry field not turning red when entering an invalid date.