Why does Coded UI Test playback fail to scroll the Silverlight control into view?

Bringing the control into view is an essential part of the UITestAction during Playback since Coded UI Test performs actual Mouse/Keyboard actions on the control instead of programmatic action on the control. In case of failure to bring the control into view, the playback will throw a FailedToPerformActionOnBlockedControl exception or a PlaybackFailure exception.


The Coded UI Test playback engine attempts various approaches to bring the control into the physical screen view –


          Bring the application window into the screen area

          Set focus on the control.

          Scroll the control into the view port of the container within which it resides.


This post focuses on the third approach and the assumptions made in the scrolling logic for Silverlight test automation in Coded UI Test.



To scroll a control into view,  the control (or its accessibility peer) should either support the scrolling capability natively,  or needs to be residing inside one or more scrollable containers which can then be scrolled in some sequence to bring the control into view.


Silverlight controls such as ListBoxItem or ComboBoxItem have their AutomationPeer implement IScrollItemProvider which is used to scroll the item into view. [The  ComboBox scroll into view in Coded UI Test is actually done through a select mechanism]


If a control does not implement scrolling support natively, the Playback engine relies on the scrolling capability of the containers. In Silverlight, a scrollable container can be defined using the ScrollViewer control.


    <ScrollViewer HorizontalScrollBarVisibility=”Auto” VerticalScrollBarVisibility=”Auto”>

        <Grid x:Name=”LayoutRoot” Background=”White” Height=”400″ Width=”200″>

            <Image Height=”119″ HorizontalAlignment=”Left” Margin=”61,40,0,0″ Width=”200″ Source=”/Image;component/Images/Desert.jpg” />

            <Image Height=”150″ HorizontalAlignment=”Left” Margin=”60,185,0,0″ Width=”200″ Source=”/Image;component/Images/Tulips.jpg” />

            <Image Height=”41″ HorizontalAlignment=”Left” Margin=”65,358,0,0″ Width=”200″ Source=”/Image;component/Images/Penguins.jpg” />

            <ScrollViewer Height=”150″ HorizontalAlignment=”Left” Margin=”446,519,0,0″ Name=”scrollViewer1″ VerticalAlignment=”Top” Width=”300″ >

                <TextBox Name=”textBox1″ />





The Coded UI Test’s playback engine first attempts to perform programmatic scrolling using ScrollViewer.ScrollToVerticalOffset and ScrollViewer.ScrollToHorizontalOffset methods. In case it fails, or is not implemented in a custom ScrollViewer control, the scrolling will fall back to the next approach as described –


The Scroll Viewer control has a Horizontal Scroll Bar and Vertical Scroll Bar component with AutomationProperties.AutomationId properties set to “HorizontalScrollBar” and “VerticalScrollBar” respectively. Each of them in turn have 5 sub components  à Small Decrease Button, Large decrease Button, Thumb, Large Increase Button, Small Increase Button.


Following figure shows the AutomationProperties.AutomationId  properties of all the sub-components in the Scroll Viewer control.



The Playback engine identifies the scrollable container components using these AutomationProperties.AutomationId  properties and attempts to do the required scrolling using Mouse Click action on these sub components.

So, if you are implementing a custom scroll viewer, ensure that these default AutomationProperties.AutomationId  properties of the scroll viewer component are preserved in the respective custom control component.

Comments (2)

  1. Oliver Gramberg says:

    In MainPage.xaml, I have



                xmlns:sdk="schemas.microsoft.com/…/sdk" …>

       <Grid …>



                         ScrollViewer.VerticalScrollBarVisibility="Auto" …

               <sdk:TabControl …>

                   <sdk:TabItem …> …

                   <sdk:TabItem …> …


    A simple test fails to click on a TabItem if and onyl if it is scrolled out of view with the following exception:

    Microsoft.VisualStudio.TestTools.UITest.Extension.UITestControlNotFoundException: The playback failed to find the control with the given search properties. Additional Details:

    TechnologyName:  'Silverlight'

    ControlType:  'MainPage'

    —> System.Runtime.InteropServices.COMException: Error HRESULT E_FAIL has been returned from a call to a COM component.

    According to your desription, this should work because there is a standard ScrollViewer up in the hierarchy. What am I missing?

    Best regards

    Oliver Gramberg

  2. Tapas [MSFT] says:

    I don't think this is related to the scroller.  The above error is a search failure. The MainPage is the Silverlight Plugin object for which the playback search is failing. Primary question – Is the Silverlight Main Page visible when this error shows up? Or is it something that is hidden down (i.e. scrolled out of view) in the html page?

    PS. I would also suggest you post your queries to social.msdn.microsoft.com/…/threads which is the one stop forum for all Coded UI Test related queries.