Windows icon indicating copy to clipboard operation
Windows copied to clipboard

WrapLayout "collapsing"

Open TopperDEL opened this issue 7 months ago • 3 comments

Describe the bug

I have a weird bug that unfortunately mighe be difficult to find. Im using the WinUI-ItemsRepeater with a WrapLayout as "ItemsRepeater.Layout" like this:

          <winui:ItemsRepeater >
              <winui:ItemsRepeater.Layout>
                  <controls:WrapLayout Orientation="Horizontal" VerticalSpacing="1"HorizontalSpacing="1"/>
              </winui:ItemsRepeater.Layout>
              <winui:ItemsRepeater.ItemTemplate>
                  <DataTemplate>

                      [...]

                  </DataTemplate>
              </winui:ItemsRepeater.ItemTemplate>
          </winui:ItemsRepeater>

Now it seems that adding Elements in a long list when the ItemsRepeater is "scrolled down", then it "collapses" and renders the Items wrong. I unfortunately have no other repro than this video:

https://github.com/user-attachments/assets/aa7b6ff4-2ce0-43b9-a892-f55279af9fbf

Whenever it blinks blue, I'm adding a test-element (via right-click). I'm scrolling down while I do this. Once I reach a certain point, adding another element (or basically "modifiying the underlying collection") leads to a collaps of all (!) WrapLayout within that control. I have three of them in here and they all do collapse.

I'm assuming that the renderer crashes for whatever reason. Or the layout calculation gets corrupted. I hope some of you with deeper knowledge of the insights might get a clue what's happening here. Basically all Items in all visible WrapLayouts/ItemsRepeater do not get rendered once after the other but all get rendered at (0,0):

Image

Steps to reproduce

Unfortunately I do not have a repro outside of my app.

Expected behavior

I should be able to add elements as I wish without the layout collapsing.

Screenshots

Image

Code Platform

  • [ ] UWP
  • [x] WinAppSDK / WinUI 3
  • [ ] Web Assembly (WASM)
  • [ ] Android
  • [ ] iOS
  • [ ] MacOS
  • [ ] Linux / GTK

Windows Build Number

  • [ ] Windows 10 1809 (Build 17763)
  • [ ] Windows 10 1903 (Build 18362)
  • [ ] Windows 10 1909 (Build 18363)
  • [ ] Windows 10 2004 (Build 19041)
  • [ ] Windows 10 20H2 (Build 19042)
  • [ ] Windows 10 21H1 (Build 19043)
  • [ ] Windows 10 21H2 (Build 19044)
  • [ ] Windows 10 22H2 (Build 19045)
  • [x] Windows 11 21H2 (Build 22000)
  • [ ] Other (specify)

Other Windows Build number

No response

App minimum and target SDK version

  • [ ] Windows 10, version 1809 (Build 17763)
  • [ ] Windows 10, version 1903 (Build 18362)
  • [ ] Windows 10, version 1909 (Build 18363)
  • [ ] Windows 10, version 2004 (Build 19041)
  • [ ] Windows 10, version 2104 (Build 20348)
  • [x] Windows 11, version 22H2 (Build 22000)
  • [ ] Other (specify)

Other SDK version

No response

Visual Studio Version

2022

Visual Studio Build Number

17.4

Device form factor

Desktop

Additional context

No response

Help us help you

No, I'm unable to contribute a solution.

TopperDEL avatar May 23 '25 15:05 TopperDEL

Yes, my app also meets this issue. And I found we just need to remove this line https://github.com/CommunityToolkit/Windows/blob/main/components/Primitives/src/WrapLayout/WrapLayout.cs#L194 The continue.

h82258652 avatar Jun 12 '25 02:06 h82258652

Nice finding @h82258652! Thank you!

TopperDEL avatar Jun 12 '25 06:06 TopperDEL

Added a comment on the PR, but that continue came from a fix for #70, so it may be more complex here. I think we need a few tests to ensure we've covered all the various scenarios and make sure we're fixing all the possible scenarios.

michael-hawker avatar Oct 06 '25 18:10 michael-hawker