From c4431304c4ecb359b95092c118ef504f94f1239d Mon Sep 17 00:00:00 2001 From: moooyo <42196638+moooyo@users.noreply.github.com> Date: Tue, 11 Aug 2026 15:47:02 +0800 Subject: [PATCH] [Quick Accent] Fix missing last-item selection highlight (#49820) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit ## Summary of the Pull Request Fixes a pre-existing Quick Accent rendering edge case where the last character is selected and inserted correctly, but its selection highlight is missing when a long character list is scrolled to the end. The horizontal items panel now leaves a symmetric 1-DIP margin outside its edge containers. This keeps `ScrollIntoView` from landing exactly at the maximum scroll offset, where WinUI can clip the last item's selected visual. The symmetric margin preserves short-list centering and works in both flow directions. The behavior was reproduced on both the #49633 baseline and #49655, so it was not introduced by #49655. ## PR Checklist - [ ] Closes: N/A — discovered while validating #49655; no matching issue is currently filed - [ ] **Communication:** Draft PR for maintainer discussion - [x] **Tests:** Existing tests pass; the XAML compositor edge was also covered by a deterministic GUI regression run - [x] **Localization:** N/A — no end-user-facing strings changed - [x] **Dev docs:** N/A — no developer-facing behavior or contract changed - [x] **New binaries:** N/A — no binaries or dependencies added - [x] **Documentation updated:** N/A — no documentation impact ## Detailed Description of the Pull Request / Additional comments With the overflowing horizontal list at its maximum offset, the last `ListViewItem` remains realized, selected, and visible, and its `SelectionIndicator` has opacity 1. However, WinUI does not paint that selected visual. Adding one DIP of scroll extent after the edge container avoids that boundary condition without changing selection or keyboard-navigation logic. The panel margin is symmetric so non-overflowing lists remain centered and RTL layouts receive the same protection at either edge. Infinite-width measurement already includes the margin, so the existing window sizing path needs no special case. ## Validation Steps Performed - Built `PowerAccent.UI` with `Debug|x64` using `tools/build/build.ps1`. - Built `PowerAccent.Common.UnitTests` and `PowerAccent.Core.UnitTests` with `Debug|x64`. - Ran both suites with `vstest.console.exe`: **55/55 passed**. - Reproduced the original failure by holding `A`, pressing `Space`, then `Shift+Space` before reveal: the selected `ₐ` was inserted but the baseline showed no selection-highlight pixels. - Repeated the same first-frame scenario **20 times** after the fix: all first and stable frames rendered the highlight (4441 detected accent pixels), with the foreground window preserved. - Repeated insertion validation in a dedicated text host **5 times**: all runs inserted `U+2090` (`ₐ`), rendered the highlight, and preserved foreground focus. - Ran `git diff --check` successfully. Co-authored-by: Yu Leng (from Dev Box) --- .../PowerAccent.UI/PowerAccentXAML/SelectorControl.xaml | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/src/modules/poweraccent/PowerAccent.UI/PowerAccentXAML/SelectorControl.xaml b/src/modules/poweraccent/PowerAccent.UI/PowerAccentXAML/SelectorControl.xaml index 5f87e76fd4..5d16b8b6b4 100644 --- a/src/modules/poweraccent/PowerAccent.UI/PowerAccentXAML/SelectorControl.xaml +++ b/src/modules/poweraccent/PowerAccent.UI/PowerAccentXAML/SelectorControl.xaml @@ -38,7 +38,12 @@ - + +