fix(button): sync disabled state in renderHiddenButton

[Zac-Smucker-Bryan]

Issue number: resolves #30968

---

What is the current behavior?

<ion-button> with type="submit" does not cause the associated <form> to be submitted even though it is not disabled. When the text of the input field is cleared and then input re-added, you can submit the input.

What is the new behavior?

The visible and hidden button should always have the same disabled state. <ion-button> with type="submit" should always submit the associated <form> when it is enabled.

• Add formButtonEl.disabled = this.disabled; and formButtonEl.type = this.type; to button.tsx in renderHiddenButton(). This addition syncs the disabled status and type of the button when that happens.
• Add a test in to to packages/angular/test/base/e2e/src/lazy/form.spec.ts. to test the behavior. This test gets the state of both the visible and hidden buttons, and compares both to each other and to what is expected given if the form is filled out or not.

Does this introduce a breaking change?

• Yes
• No

Other information

Related to a stencil update that affected when @watch('disabled') fires.

[vercel]

@Zac-Smucker-Bryan is attempting to deploy a commit to the Ionic Team on Vercel.

A member of the Team first needs to authorize it.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
ionic-framework	Ready	Preview, Comment	Jun 22, 2026 5:43pm

[thetaPC]

Small thing on the PR title: fix(ion-button): sync disabled state in ion-button renderHiddenButton

Two tweaks. The scope convention here uses the component name without the ion- prefix (for example fix(button), fix(modal), fix(checkbox)), so the scope should be button. And since the scope already says it's about the button, repeating ion-button in the description is redundant. Suggested:

fix(button): sync disabled state in renderHiddenButton

Small thing on the PR description:

The issue link in the description won't auto close the issue. GitHub's closing keywords only fire when the keyword is followed directly by # and the number, like resolves #30968. Here it's resolves #[30968](...), so the # is followed by a [ and GitHub doesn't parse it as an issue reference. The markdown link renders fine visually but the linkage and auto close on merge won't happen.

Please change it to:

Issue number: resolves #30968

GitHub will turn that into a link on its own, so the markdown link isn't needed.

Once you push your latest changes, make sure that the PR description is still valid.

[thetaPC]

We need to update the following comment to reflect the changes and why they were added.

/**
 * If the form already has a rendered form button
 * then do not append a new one again.
 */

[Zac-Smucker-Bryan]

I added a another line of explanatory text with the latest round of commits.

[thetaPC]

This test does not actually catch the regression. It still passes without the fix. I verified by reverting the formButtonEl.disabled = this.disabled; line, keeping the test, and rebuilding: it stays green.

The reason is timing. The bug only happens when the disabled change races with Stencil's initialization, which is the window where @Watch('disabled') gets missed. This test changes disabled with el.evaluate and setTimeout after the component has fully loaded, and by that point the watch is active again and syncs normally. So it reduces to "set disabled to false after load," which is the same as the manual workaround in the issue (clear the input, then retype) that already worked before your fix. Also worth noting that el.disabled = true is a no-op there since the button already starts disabled in the markup.

There is no post-load DOM API to suppress the watch, so core e2e cannot reproduce this one deterministically. The faithful reproduction needs a framework binding that sets disabled during init, which is exactly the Angular async validator scenario from the issue.

Please move the regression test to packages/angular/test/base/e2e/src/lazy/form.spec.ts. Set up a submit button that starts disabled and has its disabled state flip to false asynchronously during init (an async validator resolving, or a Promise.resolve().then(...) in ngOnInit), then assert the form submits on click. Confirm it fails without the fix before pushing, since that is the whole point of the test.

If you are feeling adventurous, add the same coverage to the standalone test app too.

[Zac-Smucker-Bryan]

I added a test to packages/angular/test/base/e2e/src/lazy/form.spec.ts that compares both states and validates them as expected. The test fails if you comment out the suggested changes AND if you comment out the watch decorator for the disabled state in line 62 of button.tsx. It then works if you leave the watch decorator commented out but apply the changes OR if you add the decorator back in and also apply the changes. It seemed like the watch decorator was firing successfully always in the test environment, and as a consequence, that the test is at least good enough way to verify that if the watch decorator doesn't fire successfully, the fix should catch it.

I had a hard time replicating the race condition and wasn't sure if you wanted form.component.ts to be updated as well with ngOnInit (or else, a separate test component and ts file for this particular issue). When I was experimenting with other forms of testing and trying to use more of the Promise.resolve().then(...) in ngOnInit (and a couple of other things I tried to do with https://angular.dev/api/forms/AsyncValidatorFn), I kept getting timeout errors in the test. Let me know if you want want me to keep at your original suggestion and I will take another look.