I’m messing around with 8.3 beta and enjoying some of the new features very much. One thing I am particularly interested in is the Form component in Perspective (pretty much everything I work on is in Perspective), but I am somewhat confused about the behavior of the Enter key when editing fields like a text widget, and that (seemingly all) other widgets in the form have their fields cleared when enter is pressed with no event fired and (again seemingly, as I may be missing something obvious here) no way to prevent/change this behavior.
For example, just creating another text field (or text area) widget in the default configuration that the Form gives you when you drag it in, giving the new one an ID (so it appears) and typing some text into the first field. Then, clicking on the second field and entering some text, but then pressing enter, causes the first field (and, for whatever reason, sometimes the second field) to be wiped clean. The data property updates just fine showing a now empty list, and if you click off of the field you’re focused on/editing to an empty area of the form or anywhere else on the page, the text stays just fine.
Is this finalized behavior/intentional and I’m missing something? Or is there something else going on, like a bug of some sort. Just doing a sanity check and hoping to get some input on this.
Thank you for bringing this to our attention. I was able to reproduce the issue, but I still need more information on what might have caused it. I’ll keep you updated—thanks again!
It seems the issue may be related to the 'Submit' action: disabling the "Submit" action appears to get re-enabled when pressing the Enter key. Notably, the issue doesn’t occur if the action bar is completely disabled.
We now have an internal bug ticket open to track this issue.
Thank you for looking into that so quickly. Sounds like something I should be able to work around temporarily since disabling the action bar prevents the issue from occurring, just will need some extra logic to maybe re-enable at some point in the form completion process or something like that. We definitely see a lot of value in the form for some of our projects so I appreciate you responding so fast. Have a great day!
@Lina_Wright Have another question if it’s alright. With validation, I can see that the status changes when constraints are added like tooShort, tooLong, valueMissing, etc. But even though (as the image shows) the boxes for these sample email and phone number entries are highlighted due to a pattern mismatch, the status does not change from valid, neither the browser default nor custom messages are displaying, and the submission of the form is not prevented like with other constraints not being met. Is this also an issue, or am I potentially doing something wrong? For reference, the pattern regex constraints are the same used in the form example found at Perspective - Form | Ignition User Manual in the ‘Basic Form Layout with Validation’ section (I tried copying the link directly to that but it keeps defaulting to the top of the page for some reason) and the widgets for email and phone numbers are of type email and tel respectively. Thank you!
Hi, I tested this out and if you look at the Console window, you should see an error being thrown similar to the following:
Pattern attribute value ^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\\.[a-zA-Z]{2,}$ is not a valid regular expression: Uncaught SyntaxError: Failed to read the \'patternMismatch\' property from \'ValidityState\': Invalid regular expression: /^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\\.[a-zA-Z]{2,}$/v: Invalid character in character class
This is due to the hyphen not being properly escaped in the provided pattern. The following pattern should work:
I will follow up with our Docs team to adjust that Value.
One other thing to mention is that since the field has a type of “email”, it will automatically have intrinsic validation applied (see <input type="email"> - HTML | MDN). The pattern constraint can be used to further restrict the value.
