Microsoft-ui-xaml: The ScrollViewer scrolling randomly breaks down

[Sergio0694]

Describe the bug

So, this is sort of a weird issue to open, if you will, as I don't really have much detail to share on this. The problem is that the native ScrollViewer control will randomly break down and stop scrolling entirely. The weird thing is that if you scroll on the mouse wheel, you'll still be able to see the scroll bar move up and down as if you were actually scrolling, but the content itself will not move at all.
Also, if you actually use the mouse to manually click somewhere _on the scroll bar_, the content then _does_ scroll instantaneously to that offset. It just won't move at all while using the mouse wheel though.

NOTE: when this happens, all the ScrollViewer in the app are affected, it's not a single one that breaks down. In one case I had 3 ListViews side by side in different panels, and all three of them started showing this behavior.

NOTE 2: this can sometimes recover on its own. One time it happened, I minimized the app for a while and when I brought it back up again the ScrollViewers started working fine again, without the need to close the app and open it again.

NOTE 3: this happens both with a local Debug build as well as with a Release build (.NET Native) downloaded from the Store.

This is happening in two different apps for me, and I know of other devs that had the same issue too. I can also confirm that this first happened quite a few builds ago, I think I've first noticed this back on 14393 (although I can't be sure it wasn't already there before that one too).
I know you're planning on including an entirely new ScrollViewer with WinUI 3.0, but since you said you'd still be updating the current one with bug fixes I thought I'd mention this anyway.
Now, I don't really know how to reproduce this. If you have any ideas, please let me know what I can do to help out. I just know that for me, it'll randomly break down, with no exceptions being thrown or anything like that, it'd just stop working. Note that this happens very rarely, but it still happens from time to time (it was not just a one time issue that never happened again).

Steps to reproduce the bug

Steps to reproduce the behavior:

1. ..?

Expected behavior

The ScrollViewer should scroll as usual

Screenshots

I have a video that shows the issue, but since it's from an app I'm working on that I don't want to announce yet, I can't link it here. I'd be happy to share it via DM to one of you guys from the WinUI team, if that helps.
Anyway, that's just a ListView with some content, and you can see the scrollbar moving up and down while the rest of the content remains perfectly still.
It also shows that while the issue is present, you can still click on the scrollbar with the mouse to make the content jump to a different offset, that still works.

Version Info

This happens with the native ScrollViewer, both with and without the WinUI package installed.
I've noticed this on W10 Desktop (x64, both Home and Pro if that matters)

NuGet package version:

| Windows 10 version | Saw the problem? |
| :--------------------------------- | :-------------------- |
| Insider Build (xxxxx) | Yes |
| October 2018 Update (17763) | Yes |
| April 2018 Update (17134) | Yes |
| Fall Creators Update (16299) | Yes |
| Creators Update (15063) | Yes |
| Anniversary Update (14393) | Yes |

| Device form factor | Saw the problem? |
| :-------------------- | :------------------- |
| Desktop | Yes |
| Mobile | |
| Xbox | |
| Surface Hub | |
| IoT | |

Additional context

[jevansaks]

Thanks for reporting this, it's definitely something we've heard reports of before but we've never had a reliable repro. Unfortunately I don't think this area has particularly good tracing so we probably need a live repro of this to debug.

Is this something that happens often enough that we could work with you to set up a remote debug session? Or maybe you could get the repro set up in a VM and then save the VM state and share that out?

[Sergio0694]

Hey @jevansaks - sure, I figured something like this would indeed be hard to track, but I figured having an open issue about this could help anyway, if nothing else so that other devs would be able to chime in and possibly share more useful info on this if they can.

So, as I said it's completely random for me. Sometimes it'll happen twice in less than an hour, sometimes it could be a week or more before it happens again 😕

That said though, it does seem to be particularly frequent with this new app I'm working on for some reason, so that might be useful to debug this. So to answer your questions:

1. I don't think a remote debug session would help, since as I said, sometimes it can still be days between occurrences of this bug.
2. Sure, I could try to setup a VM and run the app for a while. Since I've had reports of this happening with builds from the Store as well, I guess I could just get the app from there instead of having to setup VS and everything. Also, again, I'm not sure if this would help since the issue doesn't happen that frequently, but I could share a private download link for you if you'd like to try the app and see if the issue happens on your side (if you're lucky).

Another question: what if this happens when I'm just debugging the app from VS, with my primary OS and not from a VM? Is there some sort of snapshot I could take at that point from VS, or would you actually need a full VM snapshot in order for it to provide useful info?

[jevansaks]

I hear you, these types of issues are tricky. We're working on adding better diagnostics to the more complex controls (like ScrollViewer) going forward so that we would be able to debug issues in the field better.

Is there some sort of snapshot I could take at that point from VS,

I'm not aware of a way to snapshot a VS debugging session like that -- but if you were using remote debugging of the app running in a VM then when it repros you could detach the visual studio debugger and then save the VM at that point. I also understand if you don't want to go to these lengths to get us a repro. :)

If you can share a link to the app in the store or just an appx here, we could try reproing with that locally.

[Sergio0694]

Oh, the improved diagnostics sounds like a good idea for the future! 😄

No it's fine, I'm happy to help out where/if I can!
I just don't have experience working with remote debugging sessions, so if all you need is just a VM snapshot I guess I could just grab one of those official W10 VM images from MS, install the app and play with it until I eventually (hopefully) get the issue, then make a snapshot I can share with you guys.
Would that work?

As for either a download link or an appx build to share, as I said I'd like not to just share either of them here. If that's ok for you, I could either email those to you, or DM them on Twitter (just followed you there). I realize it's not idea and I'm sorry if this is annoying, I'd just like to keep the app under wraps for now 😅

[jevansaks]

I could just grab one of those official W10 VM images from MS

Yup, that's what I was thinking -- set it up in a local Hyper-V session and it should be pretty easy to manage the state.

And no worries about not wanting to share the app openly. DM me on Twitter with a link to the app. Thanks!

[wbokkers]

I reported this issue mid 2018.
It could be reproduced by Microsoft and the root cause was found.
Micah Lewis emailed me on July 18, 2018:

Thought you’d like to know… A dev from the other team has identified the root cause for the scrolling issue. Next step is identifying the right fix and hopefully getting it in to be part of the next major release.

Some nitty-gritty details in case you’re interested…

When switching between chat/calendar windows, viewports are getting destroyed and recreated. If it so happens that the viewport was destroyed when it’s in an inertia (or even running state too), dmanip doesn’t get a chance to clean it up from the _activeViewportMap. Hence the orphaned viewport entry lingers in _activeViewportMap and thus compositor bit won’t get set to dirty due to the reason below.

I took some traces of the app in repro state. From what I’m seeing so far, it looks like the _activeViewportMap map has two viewports in it. One of them doesn’t actually seem to be active (it’s state is READY). I’m not sure which viewport this corresponds to. The viewport that is actually active is infact getting its viewport update callback. However, since the code in OnViewportUpdated() sets the dirty bit only when all viewports in the _activeViewportMap is updated, it never ends up setting the compositor’s dirty flag (hence no updation).

It looks like some kind of race must have caused the inactive viewport to accidentally remain the _activeViewportMap structure.

And on October 30, 2018:
Hi Wim, it looks like the fix was checked into a lower level branch two weeks ago. Depending on how quickly those changes are integrated from that team’s branch up to MAIN (which might take a few more weeks) the fix should be available on a future Insider’s build and part of the next major release in 2019.

[jevansaks]

The power of the hive mind! Thanks @wbokkers for closing the loop on this, that's incredible. And awesome to hear it's fixed now.

Based on that it sounds like it should no longer repro on insider builds and the upcoming Windows 1903 release.

[wbokkers]

The issue has still been seen on Insider builds by @Sergio0694. So maybe Micah Lewis (@micahl ?) can confirm that the fix will be in 1903?

[micahl]

@Sergio0694 which insider build # have you hit this?

@jevansaks the issue Wim hit was tracked by internal issue # 17855072. It says the fix should be in builds as of 18282.1000.rsmaster.181109-1528.

[Sergio0694]

Hi, thank you guys for chiming in!
I'm running 18362.86 right now, so I can confirm the fix still isn't working on this build.

[micahl]

@wbokkers have you had a chance to try your app on a recent build and verify that the issue no longer repros for you?

[wbokkers]

@micahl I can't reproduce it on 18362.86. It can take some time before the issue shows up, but I scrolled for about 15 minutes.
I can't reproduce it on 17763.475 either. But that's probably because I'm on a new PC and not all devices have this problem afaik. Our app is being tested for quite some time now and I get a lot of feedback, but never about this issue. So, I assumed that this issue had already been solved in some cumulative update.

[micahl]

@Sergio0694, it's possible this is a different issue than the one @wbokkers hit. As Jevan mentioned earlier we've seen some issues like this with the existing ScrollViewer control and they can be elusive to track down. If you can get a VM with a repro using as recent version of the OS as you can find then let @jevansaks know.

[DerGary]

@micahl is there a plan to ship the fix of this issue as an update for Windows Versions prior to 1903? Our Company is currently mostly on 1809 and the responsible staff has no intention to update to 1903 in the near future they might skip this and update next year to 1909. But our users can't wait that long for a fix for this issue.

[micahl]

@DerGary, no promises, but I have started an thread internally to raise the issue.

[DerGary]

@micahl thank you very much, that is very kind of you. In the meantime (maybe I should have asked that first) is there a known workaround that I can build inside the app to prevent this issue from happening in the first place?

[micahl]

@wbokkers, you did something to avoid hitting this issue, right? What was it? @DerGary, unfortunately I'm not aware of a guaranteed workaround.

[wbokkers]

@michahl, no I couldn't avoid hitting the issue, as far as I can remember. I can't reproduce the issue now, and there are no user complaints about it either.

[Ambigulous]

@DerGary, what is your company? I am preparing to bring the fix to Windows 10 1809 per your request, some information about your company and the product would help to make the business case. If you have a support agreement with Microsoft, we could even send you a private update for you to verify ahead of time. Thanks!

[DerGary]

I'm working for the s.Oliver Bernd Freier GmbH & Co. KG. We are employing about 7000 people worldwide. We have 2 UWP Apps that are used each by around 300 employees. We have usage of around 150-180 unique users per day per app. The Users depend on these apps because they have no other way of doing their work currently. And yes we do have a support agreement with Microsoft.

[adrientetar]

Pay attention this person just signed up on gh, it looks like a phishing attempt. And mentions "1809" an old release of Windows.

[Felix-Dev]

@adrientetar Reading up on the latest comments, I'm not sure this is a "phishing attempt". @DerGary is explicitly asking for a 1809 backporting of the fix and @micahl did say a couple days ago he was starting a thread internally about backporting it. Since github is also a relatively new way of interacting with customers for certain parts of MS, the sign-up date also doesn't have to necessarily be a suspicious sign.

Perhaps someone can clarify? @jevansaks @Ambigulous @micahl

[DerGary]

I was also sceptic about the signup date. But I did not provide any confidential information and I also won't do that in a public forum. But thanks for your concerns @adrientetar and @Felix-Dev. I would also be happy if @micahl would validate that account.

[jevansaks]

I was giving @ambigulous the benefit of the doubt as well but their account isn't associated with the Microsoft org on GitHub so now I'm suspicious too. @ambigulous can you email me so we can get this sorted out?

[micahl]

@DerGary, i've reached out to the folks with whom I've been communicating and will update once I know. fyi, we do have an internal issue tracking the request to backport to 1809 that is going through review.

[Ambigulous]

I am properly linked now. Sorry for causing doubt, but it is good to see the high level of caution :) Yes 1809 is an old version of Windows but it is still supported. That is the work I am involved in, providing security/functionality/reliability updates to in-market versions of Windows, via Windows Updates.

[jevansaks]

Thanks @Ambigulous!!

[DerGary]

@Ambigulous are you sure you are properly linked? Github does not show me that you are a member of the microsoft organization?

[adrientetar]

One thing with GitHub is organization memberships aren't public by default, you have to go to that organization page and hit the lock icon next to your alias in the members list.

[jevansaks]

It takes a little while for that card in the activity feed to show up, but I confirmed on the internal site for linking accounts that @Ambigulous is a Microsoft employee helping out with servicing this fix. :)

[micahl]

Yep, we're all good. Thanks everyone!

[DerGary]

@Ambigulous was the information I provided sufficient for your business case?

[Ambigulous]

@DerGary, yes it helped a lot, thank you!
We have already made the fix to Windows 10 1809, and is being tested. It should become available in the September 17th "Preview of Monthly Rollup" optional update.

[DerGary]

@Ambigulous can you provide the KB number of this update? I'm unable to find it.

[jevansaks]

Thanks for the ping! Looks like it's ready to go but got delayed a couple days. My sources tell me "KB4516077 will be live around 10:00 AM tomorrow".