AEM as a Cloud Service: Dialog submission bypasses required field validation with custom script

Last update: August 26, 2026

This article explains how to address an issue in Adobe Experience Manager as a Cloud Service where component dialogs can be submitted even if required fields aren’t filled, typically due to a custom client-side script overriding standard validation.

Description description

Environment

Adobe Experience Manager as a Cloud Service (AEMaaCS) and AEM SDK environments.

Symptoms

A component dialog contains a text field with custom validation and a path field marked as required.
In AEM SDK environments, the dialog can’t be submitted if the required fields are empty or validation fails.
In AEM as a Cloud Service environments, the dialog allows submission, even when required fields aren’t filled or validation fails.
The custom validator displays its error message, but clicking the Done button still submits the form.

Example field configuration:

<alt
    jcr:primaryType="nt:unstructured"
    sling:resourceType="granite/ui/components/coral/foundation/form/textfield"
    validation="testing.test"
    fieldDescription="Alternative text for image"
    fieldLabel="Alt text"
    name="./alt"/>
<linkURL
    jcr:primaryType="nt:unstructured"
    sling:resourceType="granite/ui/components/coral/foundation/form/pathfield"
    required="{Boolean}true"
    fieldDescription="Link"
    fieldLabel="Link"
    name="./linkURL"/>

Cause

A custom client-side validation script registers a global click handler for the Dialog Submit button. This handler intercepts all dialog submissions and directly submits the form, bypassing the standard Granite UI validation. As a result, dialogs are submitted even when required fields are empty or custom validation fails.

Resolution resolution

Follow the steps below to resolve the issue:

Review your custom client-side validation scripts, especially those registering event handlers for dialog submission (such as handlers for the Dialog Submit button).
Ensure that any custom handler only intercepts submission for the intended dialog or field (For example: by checking for a specific multifield or dialog context before acting).
Refactor the handler so that e.stopPropagation() and e.preventDefault() are only called after confirming the handler is dealing with the intended dialog. For all other dialogs, allow AEM’s standard validation and submission flow to proceed without interference.
Remove any fallback logic that directly submits the form for dialogs other than the intended one.
Redeploy your application.
Verify that dialog submission is now correctly blocked when required fields aren’t filled or validation fails.

recommendation-more-help

experience-cloud-kcs-help-kbarticles