Validation error messages are not displayed when screen size is equal or less than 1024px

[GhostOrder28]

Link to reproduction

No response

Describe the Bug

Validation error messages are not displayed when screen size is equal or less than 1024px

To Reproduce

1. reduce the screen width to 1024 or less.
2. try to create a new entity of whatever collection you prefer (I will use the default Users collection)
3. leave empty the email field to trigger the validation error.
4. save the new user.
5. the email field will turn red, but there will be no validation message
6. Then increase the screen width to more than 1024 and you will see the validation message.

Payload Version

2

Adapters and Plugins

No response

[PatrikKozak]

Hey @GhostOrder28 - this is actually intended behavior to keep the mobile admin UI less cluttered.

So I will convert this to a discussion, where we can discuss potential improvements to validation errors in the mobile admin UI.

[stephaniesyed]

For custom errors, I do think it's important for the text to be shown regardless of screen size - though there is flexibility to perhaps display them differently.

I'm running into this because a nested and top level field need to have coordinating ids. Psuedocode of relevant info:

Partner{
   id: int
}

ShippingLocation {
   id: int
   partner_id: int
}

Portal{
   id: int
   partner_id: int
   shipping_location_id: int
}

My custom validator for Portals checks if the payload object is actually populated. If it isn't, that means it's client side code and makes a network call to make sure the shipping location's partner and the Portal's partner are the same, otherwise it uses the local API (which isn't a very graceful determination, but I'm unsure how else to do it). When validation fails, it just highlights the shipping location in red, rather than indicating that the shipping location isn't valid given the partner selected.

[anuith]

I agree with @stephaniesyed — every field should have a clear way to display its error message without requiring custom components. Probably above or below the input.

Regarding the 1024px breakpoint: I believe there's sufficient space at that size to show tooltips similarly to larger screens. Since the sidebar is already converted to stack at 1024px, it feels reasonable to allow tooltips to remain visible at that width. Perhaps the breakpoint for hiding tooltips could be lowered, or set to ≤1024px, to better balance clarity and layout constraints.