This is Xamarin's bug tracking system. For product support, please use the support links listed in your Xamarin Account.
Bug 41415 - ScrollX and ScrollY values are not consistent with iOS
Summary: ScrollX and ScrollY values are not consistent with iOS
Status: RESOLVED FIXED
Alias: None
Product: Forms
Classification: Xamarin
Component: Android (show other bugs)
Version: 2.2.0
Hardware: Macintosh Mac OS
: --- normal
Target Milestone: ---
Assignee: Bugzilla
URL:
: 45060 (view as bug list)
Depends on:
Blocks:
 
Reported: 2016-06-01 00:41 UTC by trjunk
Modified: 2016-12-06 12:12 UTC (History)
6 users (show)

See Also:
Tags: AC
Is this bug a regression?: ---
Last known good build:


Attachments

Description trjunk 2016-06-01 00:41:54 UTC
I've noticed some weird behavior when there is an AbsoluteLayout embedded in a ScrollView. There is some inconsistency between android and iOS with the Scrolled event. Here's some example code:


ScrollTestPage.xaml
-----
<?xml version="1.0" encoding="UTF-8"?>
<ContentPage xmlns="http://xamarin.com/schemas/2014/forms" xmlns:x="http://schemas.microsoft.com/winfx/2009/xaml" x:Class="ScrollTest.ScrollTestPage">
    <ContentPage.Content>
        <ScrollView x:Name="scrollView" Orientation="Both" HorizontalOptions="FillAndExpand" VerticalOptions="FillAndExpand">
            <AbsoluteLayout WidthRequest="1000" HeightRequest="1000" />
        </ScrollView>
    </ContentPage.Content>
</ContentPage>
-----

ScrollTestPage.xaml.cs
-----
using System;
using System.Collections.Generic;

using Xamarin.Forms;
using System.Diagnostics;

namespace ScrollTest {

    public partial class ScrollTestPage : ContentPage {
		
        public ScrollTestPage() {
            InitializeComponent();
                scrollView.Scrolled += OnScrolled;
            }

        void OnScrolled(object sender, ScrolledEventArgs e) {
            Debug.WriteLine("{0:0.0} {1:0.0}", e.ScrollX, e.ScrollY);
        }
    }
}
-----

The problem that I am seeing is that in android the ScrollX and ScrollY variables return strange results. When scrolling horizontally, ScrollX returns the X position of the window (this is expected) and ScrollY returns 0 (not expected). With vertical scrolling, ScrollX is 0 and ScrollY is normal. However, on iOS both ScrollX and ScrollY return the expected X and Y positions of the window respectively. Is this normal?
Comment 1 Carson Roscoe 2016-07-08 18:28:08 UTC
I have just ran into the same issue.

On Android I have a scrollview that can scroll both horizontally and vertically. I have a custom control inside it that does virtualized drawing, so it needs to know the current ScrollX and ScrollY so it can calculate what is visible (and needs to be drawn) vs what is not visible (what should not be drawn).

Whenever the user scrolls vertically or horizontally on Android, everything mucks up.

My debugging has shown that, even if the ScrollX and ScrollY are both at 2000, if you start scrolling vertically too fast (going very very slow works), the ScrollX is set to 0.

If you start scrolling horizontally too fast (by too fast I mean average speed I should add), the ScrollY is set to 0 in the scrollview.

Product: Forms
Component: Android
Forms Version: 2.2.0.4
Android Version: 2.2.0.31
Device #1: Nexus 10 (Android 4.4.2 - API 19) - Emulated in Xamarin Emulator
Device #2: Nexus 7  (Android 5.1.0 - API 22) - Emulated in Xamarin Emulator
Development Hardware: Windows 10 Lenovo ThinkPad

EXTRA:

https://forums.xamarin.com/discussion/70815/scrollview-both-direction-android-problem

That is a Thread to the forums posted Today (July 8th 2016) where another person ran into the same issue and showed the console log. You'll notice not a single case on Android did both the ScrollX and ScrollY have values - the one not being scrolled always returned 0.
Comment 2 adrianknight89 2016-09-29 18:14:39 UTC
See https://github.com/xamarin/Xamarin.Forms/pull/394
Comment 3 Paul DiPietro [MSFT] 2016-10-19 23:32:30 UTC
*** Bug 45060 has been marked as a duplicate of this bug. ***
Comment 4 Rui Marinho 2016-12-06 12:12:14 UTC
Should be fixed in 2.3.4-pre2

Note You need to log in before you can comment on or make changes to this bug.