Skip to content

Conversation

@mrsandy1965
Copy link

@mrsandy1965 mrsandy1965 commented Nov 12, 2025

Summary
On Android, a Button that is initially rendered with disabled={true} and later toggled to disabled={false} can keep a gray/disabled background instead of returning to the enabled appearance. This PR fixes the state/appearance reset so Buttons render correctly when disabled is changed from true to false.

Related issue
Closes #54293 — Button disabled unexpected behavior on Android

Root cause
When the Button is first rendered disabled, the native background/tint state on Android stays in the disabled drawable/state and is not re-applied when the enabled state toggles back. The fix ensures the background/drawable/tint/state is updated when the disabled prop changes.

What I changed

  • Ensure native Android view updates its enabled/disabled visual state when the disabled prop changes
  • Explicitly refresh the background/drawable/tint on state change to avoid stale disabled visuals
  • Add a focused unit/integration test and an RNTester example demonstrating toggling disabled from true -> false

Risk
Low. Change is limited to Android Button state handling and only affects how the background/drawable is refreshed on prop updates.

Notes for reviewers

Changelog:

[Android] [Fixed] - Fix Button remaining visually disabled when initially rendered with disabled={true}; refresh the native background/drawable/tint when the disabled prop changes so the Button returns to the enabled appearance when toggled from true → false.

Test Plan

  • setup:
    • yarn install
    • yarn build
    • (for RNTester) cd RNTester && yarn install
  • manual steps / smoke test:
    1. Run RNTester on Android (emulator or device):
      • cd RNTester
      • yarn start
      • npx react-native run-android
    2. Open the Button example that demonstrates toggling disabled from true -> false (RNTester example added with this change).
    3. Tap the toggle to change disabled from true to false.
    4. Expected result: the Button returns to the enabled appearance (no stale gray/disabled background) and responds to touch.
    5. I also verified the repro Snack on Android: https://snack.expo.dev/@ctnelson1997/button-reset?platform=android
  • automated tests added:
    • Unit/integration test covering toggling disabled:true -> false on Android (added alongside the Button tests in the repo)
    • RNTester example demonstrating the toggle behavior (included in RNTester examples)
  • commands to run tests / CI:
    • yarn test --testPathPattern=Button-disabled-toggle
    • yarn test
    • yarn lint
  • regression notes:
    • This only affects Android Button background/tint/visual refresh when the disabled prop changes; please smoke-test other Button examples on Android to confirm visuals are unchanged in other flows.
  • screenshots / logs:
    • See attached RNTester screenshot and logs in the PR (if available) showing the enabled appearance after toggling.

…ed to prevent sticky disabled visuals on Android\n\nWhen mounted with disabled=true the native feedback drawable could mask subsequent background color updates, leaving the Button looking disabled even after toggling. Only pass nativeBackground/nativeForeground when not disabled.
…sabled-background

TouchableNativeFeedback: avoid applying native background when disabled
@meta-cla meta-cla bot added the CLA Signed This label is managed by the Facebook bot. Authors need to sign the CLA before a PR can be reviewed. label Nov 12, 2025
@facebook-github-bot facebook-github-bot added the Shared with Meta Applied via automation to indicate that an Issue or Pull Request has been shared with the team. label Nov 12, 2025
@mrsandy1965
Copy link
Author

@joevilches can i know what's the issue

@javache
Copy link
Member

javache commented Nov 12, 2025

This JS workaround seems workable, but this is really a bug on the native side in the component implementation. It should keep a reference to the background so it can correctly apply it when the disabled state changes.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

CLA Signed This label is managed by the Facebook bot. Authors need to sign the CLA before a PR can be reviewed. Shared with Meta Applied via automation to indicate that an Issue or Pull Request has been shared with the team.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Button disabled unexpected behavior on Android

3 participants