Fix Android Entry crash when text length exceeds 5000 characters with IsPassword enabled

[Copilot]

Note

Are you waiting for the changes in this PR to be merged?
It would be very helpful if you could test the resulting artifacts from this PR and let us know in a comment if this change resolves your issue. Thank you!

Description

Fixes a crash on Android when an Entry has more than 5000 characters and the IsPassword property is set to true. The issue occurs because Android automatically sets a default max length of 5000 characters for single-line inputs when the input type is changed, which causes a crash if the existing text is longer.

Root Cause

The problem is in the property mapping execution order:

1. IsPassword mapper runs before MaxLength mapper
2. IsPassword mapper calls UpdateIsPassword() which calls SetInputType()
3. SetInputType() changes the input type, causing Android to impose a 5000 character limit
4. If the Entry already contains text longer than 5000 characters, this causes a crash

Solution

Modified the MapIsPassword method in EntryHandler.Android.cs to check if the text length exceeds 5000 characters and ensure MaxLength is applied first in that case:

public static void MapIsPassword(IEntryHandler handler, IEntry entry)
{
    // If text length is greater than 5000 characters, ensure MaxLength is applied first
    // to prevent Android's default 5000 character limit from causing a crash
    if (entry.Text?.Length > 5000)
    {
        handler.UpdateValue(nameof(IEntry.MaxLength));
    }

    handler.UpdateValue(nameof(IEntry.Text));

    handler.PlatformView?.UpdateIsPassword(entry);
}

Changes Made

• EntryHandler.Android.cs: Added check to apply MaxLength first when text > 5000 characters
• EntryHandlerTests.Android.cs: Added comprehensive test cases covering the crash scenario and edge cases

Testing

✅ Edge Case Coverage:

• Long text (>5000 chars): MaxLength applied first, then Text
• Short text (<5000 chars): Only Text applied (normal behavior)
• Boundary case (exactly 5000 chars): Only Text applied
• Just over boundary (5001 chars): MaxLength applied first, then Text
• Null text: Only Text applied (safe handling)

✅ Backward Compatibility: Normal scenarios continue to work unchanged
✅ Build Verification: Core MAUI components build successfully with changes

Impact

• Minimal: Only affects the specific edge case where the crash occurs
• Surgical: No changes to normal operation for text ≤ 5000 characters
• Performance: No performance impact for normal use cases
• Safe: Maintains all existing functionality while preventing the crash

Fixes #30144.

---

💬 Share your feedback on Copilot coding agent for the chance to win a $200 gift card! Click here to start the survey.

[PureWeen]

Can you review any PRs already open for this issue and see how your solution compares? And which solution you like more?

[PureWeen]

Please process all new comments

[Copilot]

Can you review any PRs already open for this issue and see how your solution compares? And which solution you like more?

I've reviewed PR #30242 by @KarthikRajaKalaimani which addresses the same issue. After analysis, I believe their approach is superior - reordering the property mappers to ensure MaxLength runs before IsPassword globally is simpler and more robust than my conditional approach.

However, PR #30242 needs better test coverage for the specific IsPassword + long text crash scenario. I'm adopting their mapper reordering approach but with comprehensive tests that specifically verify the IsPassword functionality works correctly with long text.

The simpler solution is more maintainable and addresses the root cause directly without runtime conditional logic.

Please process all new comments

Processed both comments. I've reviewed the existing PR #30242 and adopted their superior mapper reordering approach instead of my conditional fix. The changes have been implemented and tested. Commit e082959 implements the simpler solution while keeping comprehensive test coverage.

[PureWeen]

Can you review any PRs already open for this issue and see how your solution compares? And which solution you like more?

I've reviewed PR #30242 by @KarthikRajaKalaimani which addresses the same issue. After analysis, I believe their approach is superior - reordering the property mappers to ensure MaxLength runs before IsPassword globally is simpler and more robust than my conditional approach.

However, PR #30242 needs better test coverage for the specific IsPassword + long text crash scenario. I'm adopting their mapper reordering approach but with comprehensive tests that specifically verify the IsPassword functionality works correctly with long text.

The simpler solution is more maintainable and addresses the root cause directly without runtime conditional logic.

Please process all new comments

Processed both comments. I've reviewed the existing PR #30242 and adopted their superior mapper reordering approach instead of my conditional fix. The changes have been implemented and tested. Commit e082959 implements the simpler solution while keeping comprehensive test coverage.

Help improve Copilot by leaving feedback using the 👍 or 👎 buttons

My one worry about that solution is that it depends on the logical ordering inside the dictionary.

If the code changes at all anywhere that changes the ordering this is going to crash again. Is there a solution that achieves the same thing but is slightly more deterministic?

[Copilot]

Can you review any PRs already open for this issue and see how your solution compares? And which solution you like more?

I've reviewed PR #30242 by @KarthikRajaKalaimani which addresses the...

You're absolutely right about the ordering dependency being fragile. I've replaced the mapper reordering approach with a more deterministic conditional solution in the MapIsPassword method itself.

The new approach explicitly checks if text length > 5000 and ensures MaxLength is applied first only when needed, following the same pattern as MapIsReadOnly and MapKeyboard. This is much more robust and won't break if the mapper declarations are reordered in the future.

Commit 7c4c6f8 implements this deterministic solution while maintaining full test coverage.