What is even more interesting, entering a valid year fires the validation warning. I suspect the string for the field value is getting truncated along the way somewhere, I will dig into this.

Threw in some JS to see what the raw values going into the validate script. It looks like the last character is getting truncated. I can see this happening on other fields, so it looks like something is going wrong in the TextEdit when getting the RawValue. 

Tracing up to where JS gets the value out of the CJX_Object, it looks like the RawValue is truncated before that point. Going to start investigating on the input side and attempt to determine where the value is getting cut off from a keystroke perspective.

Yay, more investigation of this. After talking with dsinclair, we have determined the issue is due to a JS handler for text will change calling xfa.host.SetFocus, which will in turn cause the another JS handler to fire, but before the data has actually been updated.

Either the entire SetFocus call needs to be delayed until the handler is done and text is changed, or the JS callback that is being invoked needs to be delayed until the current handling is done. I need to dig into the spec to see what it says about this case and figure out how to avoid re-entering the event handling code like this.

From XML Forms Architecture (XFA) Specification Version 3.3 page 407:

Rule 4: Scripts That Fire (Invoke) Other Events
A script may cause changes of state that in turn fire or invoke other events. It may also directly declare an event. Thus, a script triggered by one event can indirectly fire other events. In such cases the order of
execution is implementation-defined.

Note: In the Adobe implementation scripts execute in a single thread. No concurrency is allowed.



From the behaviour being seen in Acrobat, it appears in addition to being single threaded, their implementation is non-reenterant. PDFium's implementation is currently reenterant by virtue of their being no event/action/message queuing system, so things like Dispatch event drill down to the target and invoke the handler immediately.

Thus technically PDFium is within spec, it is different then Acrobat, and there are PDFs in the wild that assume the Acrobat behaviour. 
To be clear, currently this form cannot be filled in by a user, because when enter the 4th digit in a valid year they will get a validation error and that last digit will be removed from the entered data. The fix for this is nominally to make event handling non-reenterant, like Acrobat, but that is yet another major architectural change.

Removing myself from bugs I do not plan to address while working 20% on PDFium.

FWIW, I think this is about reentrancy, not concurrency.