Skip to content

[iOS, Mac, Windows] Fixed CharacterSpacing for SearchBar text and placeholder text#30407

Merged
PureWeen merged 5 commits intodotnet:inflight/currentfrom
Dhivya-SF4094:fix-30366
Dec 16, 2025
Merged

[iOS, Mac, Windows] Fixed CharacterSpacing for SearchBar text and placeholder text#30407
PureWeen merged 5 commits intodotnet:inflight/currentfrom
Dhivya-SF4094:fix-30366

Conversation

@Dhivya-SF4094
Copy link
Contributor

@Dhivya-SF4094 Dhivya-SF4094 commented Jul 3, 2025

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:

  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() 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

  • Android
  • Windows
  • iOS
  • Mac

Issues Fixed:

Fixes #30366

Screenshots

Before  After 
PlaceHolder Text      
SearchBar Text      

@dotnet-policy-service dotnet-policy-service bot added the community ✨ Community Contribution label Jul 3, 2025
@dotnet-policy-service
Copy link
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.

@dotnet-policy-service dotnet-policy-service bot added the partner/syncfusion Issues / PR's with Syncfusion collaboration label Jul 3, 2025
@jsuarezruiz jsuarezruiz added the area-controls-searchbar SearchBar control label Jul 3, 2025
@Dhivya-SF4094 Dhivya-SF4094 changed the title [iOS, Mac, Windows] Fixed Character spacing for SearchBar Placeholder text [iOS, Mac, Windows] Fixed CharacterSpacing for SearchBar text and placeholder text Jul 3, 2025
@jsuarezruiz
Copy link
Contributor

/azp run MAUI-UITests-public

@azure-pipelines
Copy link

Azure Pipelines successfully started running 1 pipeline(s).

Copy link
Contributor

@jsuarezruiz jsuarezruiz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The added snapshots contains the cursor. Because is blinking, the test could randomly fail. Could you update the test to remove the cursor?
Use:

public static readonly BindableProperty IsCursorVisibleProperty =

@Dhivya-SF4094
Copy link
Contributor Author

The added snapshots contains the cursor. Because is blinking, the test could randomly fail. Could you update the test to remove the cursor? Use:

public static readonly BindableProperty IsCursorVisibleProperty =

@jsuarezruiz Updated the test sample to set IsCursorVisible to false using the UITestSearchBar.IsCursorVisibleProperty

@Dhivya-SF4094 Dhivya-SF4094 marked this pull request as ready for review July 4, 2025 10:49
@Dhivya-SF4094 Dhivya-SF4094 requested a review from a team as a code owner July 4, 2025 10:49
@jsuarezruiz
Copy link
Contributor

/azp run MAUI-UITests-public

@azure-pipelines
Copy link

Azure Pipelines successfully started running 1 pipeline(s).

@jsuarezruiz
Copy link
Contributor

/rebase

Copilot AI review requested due to automatic review settings October 27, 2025 15:50
Copy link
Contributor

Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copilot encountered an error and was unable to review this pull request. You can try again by re-requesting a review.

@jsuarezruiz
Copy link
Contributor

/azp run

@azure-pipelines
Copy link

Azure Pipelines successfully started running 3 pipeline(s).

@PureWeen PureWeen changed the base branch from main to inflight/current December 16, 2025 20:52
@PureWeen PureWeen merged commit bae1163 into dotnet:inflight/current Dec 16, 2025
174 of 183 checks passed
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"> 
|
@github-actions github-actions bot locked and limited conversation to collaborators Jan 16, 2026
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

area-controls-searchbar SearchBar control community ✨ Community Contribution partner/syncfusion Issues / PR's with Syncfusion collaboration

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[iOS, Mac, Windows] SearchBar CharacterSpacing property is not working as expected

5 participants