-
Notifications
You must be signed in to change notification settings - Fork 1.8k
[Android & iOS] - Fixed Entry and Editor from Accepting Input Values While Hidden. #27340
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
Hey there @prakashKannanSf3972! Thank you so much for your PR! Someone from the team will get assigned to your PR shortly and we'll get it reviewed. |
/azp run |
Azure Pipelines successfully started running 3 pipeline(s). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Copilot reviewed 5 out of 5 changed files in this pull request and generated no comments.
Comments suppressed due to low confidence (2)
src/Controls/tests/TestCases.Shared.Tests/Tests/Issues/Issue27236.cs:23
- Add validation to check that the input text is cleared when the control is hidden and then shown again.
element.SendKeys("Hello, Entry");
src/Controls/tests/TestCases.Shared.Tests/Tests/Issues/Issue27236.cs:36
- Add validation to check that the input text is cleared when the control is hidden and then shown again.
element.SendKeys("Hello, Editor");
/azp run |
Azure Pipelines successfully started running 3 pipeline(s). |
public override string Issue => "android allows type into hidden Entry control"; | ||
|
||
[Test] | ||
[Category(UITestCategories.Entry)] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could happen the same issue with the SearchBar?, could you verify?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could happen the same issue with the SearchBar?, could you verify?
No, the same behavior does not occur with the search bar. When the SearchBar's Visibility is set to Collapsed, it appropriately hides the keyboard as expected. This behavior has been applied consistently to Entry and Editor, ensuring uniform handling across these components.
element.SendKeys("Hello, Entry"); | ||
App.Tap("ToggleEntryVisibilityButton"); | ||
var keyboardVisible = App.IsKeyboardShown(); | ||
Assert.That(keyboardVisible, Is.False); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we include a VerifyScreenshot
to also check the Entry Visibility?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As per your suggestion, I have included the VerifyScreenshot
to validate the visibility of the editors. Let me know if you have any further concerns. Thanks!
Root Cause (Android)
When the Entry control is hidden, the soft keyboard remains active, and any text typed is queued and applied when the control becomes visible again. This is due to platform-specific keyboard input handling, which operates independently of control visibility.
Root Cause (iOS)
The soft keyboard remains visible and the focus persists even when the Entry control is hidden. Any text typed while the control is hidden is applied when the control becomes visible again, due to platform-specific behavior in managing focus and keyboard input.
Description of Change
Added platform-specific handling to dismiss the soft keyboard and remove focus when the Entry or Editor visibility is set to False. This prevents any new input from being queued and ensures that the keyboard is cleared when the control is hidden, restoring a clean state upon visibility restoration on Android and iOS.
Issues Fixed
Fixes #27236
Tested the behaviour in the following platforms
Output
Android
Screen.Recording.2025-01-24.at.5.58.24.PM.mov
Screen.Recording.2025-01-24.at.5.55.30.PM.mov
iOS
BeforeFix.mov
AfterFix.mov