Hi,
I took some notes while fixing this bug.
https://issues.apache.org/jira/browse/FLEX-33165
Any feedback and questions welcome.
Bug information
Note that it's marked as "easyfix" and a RTE. Generally these sort of bugs
don't take much to fix. Looking at the report you can see it's for a mobile
project and Adobe Flex 4.6 so the line numbers are not going to match up to the
current development branch. Search for the line of code where the error occurs,
as the code may of change first look for the function name. You can see that
the error is now on line 1581.
Reproduce the Bug
There is no sample code so you need to work out how to reproduce it, so create
a new sample mobile project containing a horizontal spark list and run it. See
if it can reproduce the issue using the 4.6 SDK. No luck. (See the JIRA issue
for the code used)
Try and work out how to generate the RTE. Looking at the snapElement method it
looks like the error would only occur when scrollProperty is null and that
could happen if both canScrollHorizontally and canScrollVertically are false.
It's possible that this could happen when size changes removes the scrollbars
when screen orientation changes. This is probably why the bug is hard to
reproduce as it depends on the amount of content in the list and the screen
size. The easy way to simulate this is to turn off both horizontal scrolling
and vertical scrolling and call the mx_internal method. Modify the code to call
the method directly with both scroll bar policy off and smapping set to
something other than none. Bingo we have the RTE!
protected function init(event:FlexEvent):void
{
list.scroller.mx_internal::snapElement(10, false);
}
<s:List id="list" dataProvider="{listdata}" width="100%" height="100%"
verticalScrollPolicy="off" horizontalScrollPolicy="off"
scrollSnappingMode="center">
<s:layout>
<s:HorizontalLayout />
</s:layout>
</s:List>
Test in the develop branch
Change to using the latest develop branch and see if the issue still exists and
yes it does.
Fix the bug
To fix add a null check and recompile the spark project by changing to the
frameworks/projects/spark directory and run ant to compile, this should only
take less than a min to compile.
Clean the FB project so it picks up the framework change. Sometime it will
cache the swc and may require swapping to and old SDK and then back again.
Double check you are using the SDK you made the change in.
Test the Change
Run the program again and/or text code path in the debugger to see that the
issue has been fixed. Play about with the sample application to make sure
nothing else has been broken.
Running mustella tests
A change to the scroller class could effect a lot of tests but we can run the
basic tests to make sure and assume the CI will pick up any other issues. For a
change like this I wouldn't expect any issues or side effects as the RTE would
normally occur, but it's best to be safe.
./mini_run.sh tests/gumbo/components/ScrollBar
./mini_run.sh tests/gumbo/components/Scroller
Both sets of test pass as expected.
[java] =====================================================
[java] Passes: 122
[java] Fails: 0
[java] =====================================================
[java] =====================================================
[java] Passes: 74
[java] Fails: 0
[java] =====================================================
Commit the change
If you are a committer you can directly commit the change via a git push. If
you are not not a committer you would need to generate a patch file and add it
to the JIRA issue. Make sure you generate the patch from the base SDK directory
like so.
git diff frameworks/projects/spark/src/spark/components/Scroller.as
diff --git a/frameworks/projects/spark/src/spark/components/Scroller.as
b/frameworks/projects/spark/
index 9f91412..c48222d 100644
--- a/frameworks/projects/spark/src/spark/components/Scroller.as
+++ b/frameworks/projects/spark/src/spark/components/Scroller.as
@@ -1579,7 +1579,8 @@ public class Scroller extends SkinnableComponent
}
else
{
- viewport[scrollProperty] = snapScrollPosition;
+ if (scrollProperty)
+ viewport[scrollProperty] = snapScrollPosition;
return null;
}
Update JIRA
Mark the bug as resolved noting down the Apache Flex versions it has been fixed
in.
Hope that was helpful,
Justin
