When a scrollviewer wraps some item that's scrolled out of view, and the user taps on a portion of the contained area that isn't interactable (such as a label), the scrollviewer brings the first focusable element into view.
This causes an unexpected jump, and makes scrollviewer unreliable.
The ScrollView does not move.
The ScrollView brings the first focusable element into view, causing the page to jump unexpectedly.
https://github.com/jkastner/XamFormsScrollviewBug
My colleague went into the Xamarin.Forms codebase, and appears to have narrowed the actual cause:
Explanation:
On UWP on a page with a scroll viewer, clicking on any non-interactive portion of the page causes the scroll viewer to "jump" to a different positionCause
The IDontGetFocus interface on the ScrollViewRenderer triggers a call to OnGotFocus() any time the scroll viewer gets focus, which in turn moves the focus to a different element which causes the scroll viewer to jump to the position of that element.[UWP] Fixes IsTabStop property in Layouts (#4703)
https://github.com/xamarin/Xamarin.Forms/commit/d7bfb0cb7bdbea47a09c228550e64541184fe9b9#diff-b1a5e5a01f67d1a9df69aa44c77e786cIsTabStop property not working when Grid contains ScrollView #4653
https://github.com/xamarin/Xamarin.Forms/issues/4653Work-around
Implement a version of ScrollViewRenderer that doesn't implement the IDontGetFocus interface
I've the same issue )-:
Thanks for the excellent bug report @jkastner .
@AxelUser can you take a look at this?
Reproduced issue on UWP, Android seems fine.
I have the same problem in my application on uwp. Ios and Android works fine. Xamarin.forms version 3.6.0.344457
I urgent need a solution because i have trouble with customers. Is there anything which can help?
I have not enough knowledge to write my own renderer.
Hi, @kgrosche.
Unfortunately I haven't found better workaround than @jkastner did.
There is a possible interaction with
ScrollViewer Jumps to Top-most TextBox (UWP app) https://github.com/microsoft/microsoft-ui-xaml/issues/597
Any updates on this? It's still a significant issue for us.
How can i escalate this issue? I am not able to upgrade to Xamarin.forms 4.x because this issue is not fixed!!
HotFix
Put this renderer in your UWP project:
https://gist.github.com/DuncWatts/2c9dd44e13d29a0e6fdc72c659532bb6
Also make sure IsTabStop="True"
on your scrollview (which is the default) otherwise it still wont work.
All credit to @duncWatts from the UWP issue https://github.com/microsoft/microsoft-ui-xaml/issues/597
I have the same issue in native uwp, has anyone found a solution?
@premiaware in this comment there are some explanation of the issue and reference to workarounds.
Just noticed this issue, makes the app ui very annoying to use as it keeps moving the content of the scrollview.
I have fixed the issue in my UWP App. [https://github.com/microsoft/microsoft-ui-xaml/issues/597#issuecomment-519299933]
I am also running into this issue and it's preventing the use of the custom UI componnents because all clicks zoom to the top of the scroll view.
Is there any update on when this will be fixed? An app that is affected by this was just released to production and it ruins the user experience.
@dberroa have you tried the fix in @JKennedy24 's post? Just use that custom renderer and add IsTabStop = true
at line 96.
I believe there won't be a fix to this issue in Xamarin.Forms in the near future. Even though unexpected jumps on clicking is 100x more important than tabs not working quite right, the review processes here don't seem able to accept fixing a huge bug at the cost of creating a tiny bug. If that remains the case, then this huge bug will remain until WinUI 3.0.
I would also appreciate it if this bug was fixed. Thanks in advance.
A hot fix I found is setting isTapStop="False" for the button or whatever it is jumping focus to.
Most helpful comment
HotFix
Put this renderer in your UWP project:
https://gist.github.com/DuncWatts/2c9dd44e13d29a0e6fdc72c659532bb6
Also make sure
IsTabStop="True"
on your scrollview (which is the default) otherwise it still wont work.All credit to @duncWatts from the UWP issue https://github.com/microsoft/microsoft-ui-xaml/issues/597