[iOS, Mac, Windows] Fixed CharacterSpacing for SearchBar text and placeholder text#30407
Merged
PureWeen merged 5 commits intodotnet:inflight/currentfrom Dec 16, 2025
Merged
Conversation
Contributor
|
Hey there @@Dhivya-SF4094! Thank you so much for your PR! Someone from the team will get assigned to your PR shortly and we'll get it reviewed. |
Contributor
|
/azp run MAUI-UITests-public |
|
Azure Pipelines successfully started running 1 pipeline(s). |
jsuarezruiz
suggested changes
Jul 4, 2025
Contributor
jsuarezruiz
left a comment
There was a problem hiding this comment.
The added snapshots contains the cursor. Because is blinking, the test could randomly fail. Could you update the test to remove the cursor?
Use:
Contributor
Author
@jsuarezruiz Updated the test sample to set IsCursorVisible to false using the UITestSearchBar.IsCursorVisibleProperty |
Contributor
|
/azp run MAUI-UITests-public |
|
Azure Pipelines successfully started running 1 pipeline(s). |
Contributor
|
/rebase |
9f52013 to
1126026
Compare
Contributor
|
/azp run |
|
Azure Pipelines successfully started running 3 pipeline(s). |
15f4314 to
e986f49
Compare
StephaneDelcroix
approved these changes
Dec 9, 2025
PureWeen
pushed a commit
that referenced
this pull request
Dec 16, 2025
…ceholder text (#30407) <!-- Please let the below note in for people that find this PR --> > [!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](https://github.com/dotnet/maui/wiki/Testing-PR-Builds) from this PR and let us know in a comment if this change resolves your issue. Thank you! <!-- !!!!!!! MAIN IS THE ONLY ACTIVE BRANCH. MAKE SURE THIS PR IS TARGETING MAIN. !!!!!!! --> ### Issue Detail The CharacterSpacing property in SearchBar behaves inconsistently across platforms: 1) iOS/macOS: Not applied to search text or placeholder—both use default spacing. 2) Windows: Applied to search text, but placeholder still shows default spacing. ### Root Cause **iOS**: The CharacterSpacing logic for SearchBar is defined in UpdateCharacterSpacing() in TextFieldExtensions.cs, shared across Entry, Editor, and SearchBar. For Entry and Editor, it's triggered via MapFormatting(), which is called from MapText() (e.g., in Entry.iOS), ensuring spacing is applied on load and text change. For SearchBar, MapFormatting() was not invoked, so CharacterSpacing was never applied to either the search text or placeholder. **Windows** - The CharacterSpacing property of the SearchBar is applied only to the search text via the AutoSuggestBox.CharacterSpacing property. However, the placeholder text is rendered by a separate internal TextBlock that does not inherit this spacing, resulting in default character spacing for the placeholder. ### Description of Change **iOS**: The fix involves explicitly calling MapFormatting() within the MapText() method of SearchBar.iOS. **Windows**: The fix explicitly locates the TextBlock rendering the placeholder using GetFirstDescendant<TextBlock>() and applies the same CharacterSpacing to it within the OnLoaded lifecycle of the AutoSuggestBox. This ensures that both search text and placeholder text reflect the correct spacing consistently. ### Validated the behaviour in the following platforms - [x] Android - [x] Windows - [x] iOS - [x] Mac ### Issues Fixed: Fixes #30366 ### Screenshots | | Before | After | |----------|---------|--------| |PlaceHolder Text| <img src="https://github.com/user-attachments/assets/04e443ac-3931-4d2d-a51f-9947557cbb45"> | <img src="https://github.com/user-attachments/assets/63ab8cca-7e3e-40d3-b82d-2cc8f27f4965"> | |SearchBar Text| <img src="https://github.com/user-attachments/assets/157a4b5a-c0e0-4424-9a0f-f2c9fea2432b"> | <img src="https://github.com/user-attachments/assets/dcecca30-081f-4ba7-bfda-000d2618fda3"> |
github-actions bot
pushed a commit
that referenced
this pull request
Dec 22, 2025
…ceholder text (#30407) <!-- Please let the below note in for people that find this PR --> > [!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](https://github.com/dotnet/maui/wiki/Testing-PR-Builds) from this PR and let us know in a comment if this change resolves your issue. Thank you! <!-- !!!!!!! MAIN IS THE ONLY ACTIVE BRANCH. MAKE SURE THIS PR IS TARGETING MAIN. !!!!!!! --> ### Issue Detail The CharacterSpacing property in SearchBar behaves inconsistently across platforms: 1) iOS/macOS: Not applied to search text or placeholder—both use default spacing. 2) Windows: Applied to search text, but placeholder still shows default spacing. ### Root Cause **iOS**: The CharacterSpacing logic for SearchBar is defined in UpdateCharacterSpacing() in TextFieldExtensions.cs, shared across Entry, Editor, and SearchBar. For Entry and Editor, it's triggered via MapFormatting(), which is called from MapText() (e.g., in Entry.iOS), ensuring spacing is applied on load and text change. For SearchBar, MapFormatting() was not invoked, so CharacterSpacing was never applied to either the search text or placeholder. **Windows** - The CharacterSpacing property of the SearchBar is applied only to the search text via the AutoSuggestBox.CharacterSpacing property. However, the placeholder text is rendered by a separate internal TextBlock that does not inherit this spacing, resulting in default character spacing for the placeholder. ### Description of Change **iOS**: The fix involves explicitly calling MapFormatting() within the MapText() method of SearchBar.iOS. **Windows**: The fix explicitly locates the TextBlock rendering the placeholder using GetFirstDescendant<TextBlock>() and applies the same CharacterSpacing to it within the OnLoaded lifecycle of the AutoSuggestBox. This ensures that both search text and placeholder text reflect the correct spacing consistently. ### Validated the behaviour in the following platforms - [x] Android - [x] Windows - [x] iOS - [x] Mac ### Issues Fixed: Fixes #30366 ### Screenshots | | Before | After | |----------|---------|--------| |PlaceHolder Text| <img src="https://github.com/user-attachments/assets/04e443ac-3931-4d2d-a51f-9947557cbb45"> | <img src="https://github.com/user-attachments/assets/63ab8cca-7e3e-40d3-b82d-2cc8f27f4965"> | |SearchBar Text| <img src="https://github.com/user-attachments/assets/157a4b5a-c0e0-4424-9a0f-f2c9fea2432b"> | <img src="https://github.com/user-attachments/assets/dcecca30-081f-4ba7-bfda-000d2618fda3"> |
PureWeen
pushed a commit
that referenced
this pull request
Dec 22, 2025
…ceholder text (#30407) <!-- Please let the below note in for people that find this PR --> > [!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](https://github.com/dotnet/maui/wiki/Testing-PR-Builds) from this PR and let us know in a comment if this change resolves your issue. Thank you! <!-- !!!!!!! MAIN IS THE ONLY ACTIVE BRANCH. MAKE SURE THIS PR IS TARGETING MAIN. !!!!!!! --> ### Issue Detail The CharacterSpacing property in SearchBar behaves inconsistently across platforms: 1) iOS/macOS: Not applied to search text or placeholder—both use default spacing. 2) Windows: Applied to search text, but placeholder still shows default spacing. ### Root Cause **iOS**: The CharacterSpacing logic for SearchBar is defined in UpdateCharacterSpacing() in TextFieldExtensions.cs, shared across Entry, Editor, and SearchBar. For Entry and Editor, it's triggered via MapFormatting(), which is called from MapText() (e.g., in Entry.iOS), ensuring spacing is applied on load and text change. For SearchBar, MapFormatting() was not invoked, so CharacterSpacing was never applied to either the search text or placeholder. **Windows** - The CharacterSpacing property of the SearchBar is applied only to the search text via the AutoSuggestBox.CharacterSpacing property. However, the placeholder text is rendered by a separate internal TextBlock that does not inherit this spacing, resulting in default character spacing for the placeholder. ### Description of Change **iOS**: The fix involves explicitly calling MapFormatting() within the MapText() method of SearchBar.iOS. **Windows**: The fix explicitly locates the TextBlock rendering the placeholder using GetFirstDescendant<TextBlock>() and applies the same CharacterSpacing to it within the OnLoaded lifecycle of the AutoSuggestBox. This ensures that both search text and placeholder text reflect the correct spacing consistently. ### Validated the behaviour in the following platforms - [x] Android - [x] Windows - [x] iOS - [x] Mac ### Issues Fixed: Fixes #30366 ### Screenshots | | Before | After | |----------|---------|--------| |PlaceHolder Text| <img src="https://github.com/user-attachments/assets/04e443ac-3931-4d2d-a51f-9947557cbb45"> | <img src="https://github.com/user-attachments/assets/63ab8cca-7e3e-40d3-b82d-2cc8f27f4965"> | |SearchBar Text| <img src="https://github.com/user-attachments/assets/157a4b5a-c0e0-4424-9a0f-f2c9fea2432b"> | <img src="https://github.com/user-attachments/assets/dcecca30-081f-4ba7-bfda-000d2618fda3"> |
github-actions bot
pushed a commit
that referenced
this pull request
Dec 24, 2025
…ceholder text (#30407) <!-- Please let the below note in for people that find this PR --> > [!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](https://github.com/dotnet/maui/wiki/Testing-PR-Builds) from this PR and let us know in a comment if this change resolves your issue. Thank you! <!-- !!!!!!! MAIN IS THE ONLY ACTIVE BRANCH. MAKE SURE THIS PR IS TARGETING MAIN. !!!!!!! --> ### Issue Detail The CharacterSpacing property in SearchBar behaves inconsistently across platforms: 1) iOS/macOS: Not applied to search text or placeholder—both use default spacing. 2) Windows: Applied to search text, but placeholder still shows default spacing. ### Root Cause **iOS**: The CharacterSpacing logic for SearchBar is defined in UpdateCharacterSpacing() in TextFieldExtensions.cs, shared across Entry, Editor, and SearchBar. For Entry and Editor, it's triggered via MapFormatting(), which is called from MapText() (e.g., in Entry.iOS), ensuring spacing is applied on load and text change. For SearchBar, MapFormatting() was not invoked, so CharacterSpacing was never applied to either the search text or placeholder. **Windows** - The CharacterSpacing property of the SearchBar is applied only to the search text via the AutoSuggestBox.CharacterSpacing property. However, the placeholder text is rendered by a separate internal TextBlock that does not inherit this spacing, resulting in default character spacing for the placeholder. ### Description of Change **iOS**: The fix involves explicitly calling MapFormatting() within the MapText() method of SearchBar.iOS. **Windows**: The fix explicitly locates the TextBlock rendering the placeholder using GetFirstDescendant<TextBlock>() and applies the same CharacterSpacing to it within the OnLoaded lifecycle of the AutoSuggestBox. This ensures that both search text and placeholder text reflect the correct spacing consistently. ### Validated the behaviour in the following platforms - [x] Android - [x] Windows - [x] iOS - [x] Mac ### Issues Fixed: Fixes #30366 ### Screenshots | | Before | After | |----------|---------|--------| |PlaceHolder Text| <img src="https://github.com/user-attachments/assets/04e443ac-3931-4d2d-a51f-9947557cbb45"> | <img src="https://github.com/user-attachments/assets/63ab8cca-7e3e-40d3-b82d-2cc8f27f4965"> | |SearchBar Text| <img src="https://github.com/user-attachments/assets/157a4b5a-c0e0-4424-9a0f-f2c9fea2432b"> | <img src="https://github.com/user-attachments/assets/dcecca30-081f-4ba7-bfda-000d2618fda3"> |
PureWeen
pushed a commit
that referenced
this pull request
Dec 26, 2025
…ceholder text (#30407) <!-- Please let the below note in for people that find this PR --> > [!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](https://github.com/dotnet/maui/wiki/Testing-PR-Builds) from this PR and let us know in a comment if this change resolves your issue. Thank you! <!-- !!!!!!! MAIN IS THE ONLY ACTIVE BRANCH. MAKE SURE THIS PR IS TARGETING MAIN. !!!!!!! --> ### Issue Detail The CharacterSpacing property in SearchBar behaves inconsistently across platforms: 1) iOS/macOS: Not applied to search text or placeholder—both use default spacing. 2) Windows: Applied to search text, but placeholder still shows default spacing. ### Root Cause **iOS**: The CharacterSpacing logic for SearchBar is defined in UpdateCharacterSpacing() in TextFieldExtensions.cs, shared across Entry, Editor, and SearchBar. For Entry and Editor, it's triggered via MapFormatting(), which is called from MapText() (e.g., in Entry.iOS), ensuring spacing is applied on load and text change. For SearchBar, MapFormatting() was not invoked, so CharacterSpacing was never applied to either the search text or placeholder. **Windows** - The CharacterSpacing property of the SearchBar is applied only to the search text via the AutoSuggestBox.CharacterSpacing property. However, the placeholder text is rendered by a separate internal TextBlock that does not inherit this spacing, resulting in default character spacing for the placeholder. ### Description of Change **iOS**: The fix involves explicitly calling MapFormatting() within the MapText() method of SearchBar.iOS. **Windows**: The fix explicitly locates the TextBlock rendering the placeholder using GetFirstDescendant<TextBlock>() and applies the same CharacterSpacing to it within the OnLoaded lifecycle of the AutoSuggestBox. This ensures that both search text and placeholder text reflect the correct spacing consistently. ### Validated the behaviour in the following platforms - [x] Android - [x] Windows - [x] iOS - [x] Mac ### Issues Fixed: Fixes #30366 ### Screenshots | | Before | After | |----------|---------|--------| |PlaceHolder Text| <img src="https://github.com/user-attachments/assets/04e443ac-3931-4d2d-a51f-9947557cbb45"> | <img src="https://github.com/user-attachments/assets/63ab8cca-7e3e-40d3-b82d-2cc8f27f4965"> | |SearchBar Text| <img src="https://github.com/user-attachments/assets/157a4b5a-c0e0-4424-9a0f-f2c9fea2432b"> | <img src="https://github.com/user-attachments/assets/dcecca30-081f-4ba7-bfda-000d2618fda3"> |
github-actions bot
pushed a commit
that referenced
this pull request
Dec 27, 2025
…ceholder text (#30407) <!-- Please let the below note in for people that find this PR --> > [!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](https://github.com/dotnet/maui/wiki/Testing-PR-Builds) from this PR and let us know in a comment if this change resolves your issue. Thank you! <!-- !!!!!!! MAIN IS THE ONLY ACTIVE BRANCH. MAKE SURE THIS PR IS TARGETING MAIN. !!!!!!! --> ### Issue Detail The CharacterSpacing property in SearchBar behaves inconsistently across platforms: 1) iOS/macOS: Not applied to search text or placeholder—both use default spacing. 2) Windows: Applied to search text, but placeholder still shows default spacing. ### Root Cause **iOS**: The CharacterSpacing logic for SearchBar is defined in UpdateCharacterSpacing() in TextFieldExtensions.cs, shared across Entry, Editor, and SearchBar. For Entry and Editor, it's triggered via MapFormatting(), which is called from MapText() (e.g., in Entry.iOS), ensuring spacing is applied on load and text change. For SearchBar, MapFormatting() was not invoked, so CharacterSpacing was never applied to either the search text or placeholder. **Windows** - The CharacterSpacing property of the SearchBar is applied only to the search text via the AutoSuggestBox.CharacterSpacing property. However, the placeholder text is rendered by a separate internal TextBlock that does not inherit this spacing, resulting in default character spacing for the placeholder. ### Description of Change **iOS**: The fix involves explicitly calling MapFormatting() within the MapText() method of SearchBar.iOS. **Windows**: The fix explicitly locates the TextBlock rendering the placeholder using GetFirstDescendant<TextBlock>() and applies the same CharacterSpacing to it within the OnLoaded lifecycle of the AutoSuggestBox. This ensures that both search text and placeholder text reflect the correct spacing consistently. ### Validated the behaviour in the following platforms - [x] Android - [x] Windows - [x] iOS - [x] Mac ### Issues Fixed: Fixes #30366 ### Screenshots | | Before | After | |----------|---------|--------| |PlaceHolder Text| <img src="https://github.com/user-attachments/assets/04e443ac-3931-4d2d-a51f-9947557cbb45"> | <img src="https://github.com/user-attachments/assets/63ab8cca-7e3e-40d3-b82d-2cc8f27f4965"> | |SearchBar Text| <img src="https://github.com/user-attachments/assets/157a4b5a-c0e0-4424-9a0f-f2c9fea2432b"> | <img src="https://github.com/user-attachments/assets/dcecca30-081f-4ba7-bfda-000d2618fda3"> |
PureWeen
added a commit
that referenced
this pull request
Dec 29, 2025
## CollectionView - Fixed the NRE in CarouselViewController on iOS 15.5 & 16.4 by @Ahamed-Ali in #30838 <details> <summary>🔧 Fixes</summary> - [NRE in CarouselViewController on iOS 15.5 & 16.4](#28557) </details> - [iOS, macOS] Fixed CollectionView group header size changes with ItemSizingStrategy by @NanthiniMahalingam in #33161 <details> <summary>🔧 Fixes</summary> - [[NET 10] I6_Grouping - Grouping_with_variable_sized_items changing the 'ItemSizingStrategy' also changes the header size.](#33130) </details> ## Flyout - Add unit tests for TabBar and FlyoutItem navigation ApplyQueryAttributes (#25663) by @StephaneDelcroix in #33006 ## Flyoutpage - Fixed the FlyoutPage.Flyout Disappearing When Maximizing the Window on Mac Platform by @NanthiniMahalingam in #26701 <details> <summary>🔧 Fixes</summary> - [FlyoutPage.Flyout - navigation corrupted when running om mac , on window ok](#22719) </details> ## Mediapicker - [Windows] Fix for PickPhotosAsync throws exception if image is modified by @HarishwaranVijayakumar in #32952 <details> <summary>🔧 Fixes</summary> - [PickPhotosAsync throws exception if image is modified.](#32408) </details> ## Navigation - Fix for TabBar Navigation does not invoke its IQueryAttributable.ApplyQueryAttributes(query) by @SuthiYuvaraj in #25663 <details> <summary>🔧 Fixes</summary> - [Tabs defined in AppShell.xaml does not invoke its view model's IQueryAttributable.ApplyQueryAttributes(query) implementaion](#13537) - [`ShellContent` routes do not call `ApplyQueryAttributes`](#28453) </details> ## ScrollView - Fix ScrollToPosition.Center behavior in ScrollView on iOS and MacCatalyst by @devanathan-vaithiyanathan in #26825 <details> <summary>🔧 Fixes</summary> - [ScrollToPosition.Center Centers the First Item too in iOS and Catalyst](#26760) - [On iOS - ScrollView.ScrollToAsync Element, ScrollToPosition.MakeVisible shifts view to the right, instead of just scrolling vertically](#28965) </details> ## Searchbar - [iOS, Mac, Windows] Fixed CharacterSpacing for SearchBar text and placeholder text by @Dhivya-SF4094 in #30407 <details> <summary>🔧 Fixes</summary> - [[iOS, Mac, Windows] SearchBar CharacterSpacing property is not working as expected](#30366) </details> ## Shell - Update logic for large title display mode on iOS - shell by @kubaflo in #33039 ## TitleView - [iOS] Fixed memory leak with PopToRootAsync when using TitleView by @Vignesh-SF3580 in #28547 <details> <summary>🔧 Fixes</summary> - [NavigationPage.TitleView causes memory leak with PopToRootAsync](#28201) </details> ## Xaml - [C] Fix binding to interface-inherited properties like IReadOnlyList<T>.Count by @StephaneDelcroix in #32912 <details> <summary>🔧 Fixes</summary> - [Compiled Binding to Array.Count provides no result](#13872) </details> - Fix #31939: CommandParameter TemplateBinding lost during reparenting by @StephaneDelcroix in #32961 <details> <summary>🔧 Fixes</summary> - [CommandParameter TemplateBinding Lost During ControlTemplate Reparenting](#31939) </details> <details> <summary>🧪 Testing (4)</summary> - [Testing] Fixed Test case failure in PR 33185 - [12/22/2025] Candidate by @TamilarasanSF4853 in #33257 - [Testing] Re-saved ShouldFlyoutBeVisibleAfterMaximizingWindow test case images in PR 33185 - [12/22/2025] Candidate by @TamilarasanSF4853 in #33271 - [Testing] Fixed Test case failure in PR 33185 - [12/22/2025] Candidate - 2 by @TamilarasanSF4853 in #33299 - [Testing] Fixed Test case failure in PR 33185 - [12/22/2025] Candidate - 3 by @TamilarasanSF4853 in #33311 </details> <details> <summary>📦 Other (2)</summary> - [XSG][BindingSourceGen] Add support for RelayCommand to compiled bindings by @simonrozsival via @Copilot in #32954 <details> <summary>🔧 Fixes</summary> - [Issue #25818](#25818) </details> - Revert "Update logic for large title display mode on iOS - shell (#33039)" in cff7f35 </details> **Full Changelog**: main...inflight/candidate
StephaneDelcroix
pushed a commit
that referenced
this pull request
Jan 5, 2026
…ceholder text (#30407) <!-- Please let the below note in for people that find this PR --> > [!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](https://github.com/dotnet/maui/wiki/Testing-PR-Builds) from this PR and let us know in a comment if this change resolves your issue. Thank you! <!-- !!!!!!! MAIN IS THE ONLY ACTIVE BRANCH. MAKE SURE THIS PR IS TARGETING MAIN. !!!!!!! --> ### Issue Detail The CharacterSpacing property in SearchBar behaves inconsistently across platforms: 1) iOS/macOS: Not applied to search text or placeholder—both use default spacing. 2) Windows: Applied to search text, but placeholder still shows default spacing. ### Root Cause **iOS**: The CharacterSpacing logic for SearchBar is defined in UpdateCharacterSpacing() in TextFieldExtensions.cs, shared across Entry, Editor, and SearchBar. For Entry and Editor, it's triggered via MapFormatting(), which is called from MapText() (e.g., in Entry.iOS), ensuring spacing is applied on load and text change. For SearchBar, MapFormatting() was not invoked, so CharacterSpacing was never applied to either the search text or placeholder. **Windows** - The CharacterSpacing property of the SearchBar is applied only to the search text via the AutoSuggestBox.CharacterSpacing property. However, the placeholder text is rendered by a separate internal TextBlock that does not inherit this spacing, resulting in default character spacing for the placeholder. ### Description of Change **iOS**: The fix involves explicitly calling MapFormatting() within the MapText() method of SearchBar.iOS. **Windows**: The fix explicitly locates the TextBlock rendering the placeholder using GetFirstDescendant<TextBlock>() and applies the same CharacterSpacing to it within the OnLoaded lifecycle of the AutoSuggestBox. This ensures that both search text and placeholder text reflect the correct spacing consistently. ### Validated the behaviour in the following platforms - [x] Android - [x] Windows - [x] iOS - [x] Mac ### Issues Fixed: Fixes #30366 ### Screenshots | | Before | After | |----------|---------|--------| |PlaceHolder Text| <img src="https://github.com/user-attachments/assets/04e443ac-3931-4d2d-a51f-9947557cbb45"> | <img src="https://github.com/user-attachments/assets/63ab8cca-7e3e-40d3-b82d-2cc8f27f4965"> | |SearchBar Text| <img src="https://github.com/user-attachments/assets/157a4b5a-c0e0-4424-9a0f-f2c9fea2432b"> | <img src="https://github.com/user-attachments/assets/dcecca30-081f-4ba7-bfda-000d2618fda3"> |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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!
Issue Detail
The CharacterSpacing property in SearchBar behaves inconsistently across platforms:
Root Cause
iOS: The CharacterSpacing logic for SearchBar is defined in UpdateCharacterSpacing() in TextFieldExtensions.cs, shared across Entry, Editor, and SearchBar.
For Entry and Editor, it's triggered via MapFormatting(), which is called from MapText() (e.g., in Entry.iOS), ensuring spacing is applied on load and text change.
For SearchBar, MapFormatting() was not invoked, so CharacterSpacing was never applied to either the search text or placeholder.
Windows - The CharacterSpacing property of the SearchBar is applied only to the search text via the AutoSuggestBox.CharacterSpacing property. However, the placeholder text is rendered by a separate internal TextBlock that does not inherit this spacing, resulting in default character spacing for the placeholder.
Description of Change
iOS: The fix involves explicitly calling MapFormatting() within the MapText() method of SearchBar.iOS.
Windows: The fix explicitly locates the TextBlock rendering the placeholder using GetFirstDescendant() and applies the same CharacterSpacing to it within the OnLoaded lifecycle of the AutoSuggestBox. This ensures that both search text and placeholder text reflect the correct spacing consistently.
Validated the behaviour in the following platforms
Issues Fixed:
Fixes #30366
Screenshots