[Panel] Pattern setting is ignored in some cases

[manuelmoreale]

Description

The pattern settings on text fields seems to be ignored when a specific length is set and the input value is longer than what's specified.

As an example, I have this pattern "\d{4,4}" set on a very simple text field.
The panel is correctly evaluating the input as I type and the x is correctly displayed next to the label if the input value is too short or too long

If I try to save though, when the string is shorter I get the warning that there's an error and that The value does not match the expected pattern

But if it's longer the panel doesn't throw and error and it saves the incorrect string just fine.
I attached a quick video to make it more clear

Screen.Recording.2024-07-30.at.11.09.13.AM.mov

Expected behavior
The panel should throw an error in both cases.

Your setup

4.3.0 running locally on PHP 8.3.9

Console output
I see a regular error when the value is too short (Kirby\\Exception\\InvalidArgumentException) but I see nothing when it's too long.

Your system (please complete the following information)

• Browser: Happens on both latest Firefox and Safari versions.

[rasteiner]

Just curious about what happens if you give it "^\d{4,4}$" as pattern.
I mean, my guess is that the panel considers it valid if any part of the value matches your pattern.

[distantnative]

Yep that's the issue. Backend checks only for any match of the pattern, but seems like the HTML attribute is rather defined as exact match (so nothing before or after the match either). One fix would be that Kirby adds ^ and $ to the start/end of the pattern if not already present.

[manuelmoreale]

One fix would be that Kirby adds ^ and $ to the start/end of the pattern if not already present.

That doesn't sound like a terrible solution honestly

but seems like the HTML attribute is rather defined as exact match (so nothing before or after the match either)

This is what MDN says: The pattern's regular expression must match the entire input's value, rather than matching a substring - as if a ^(?: were implied at the start of the pattern and )$ at the end.

[rasteiner]

One fix would be that Kirby adds ^ and $ to the start/end of the pattern if not already present.

I think it could even be dumber and simply add them always, no need to check for the presence: /^^foo$$/ matches foo too