There is a gap between how you build the SDK and how you make and test
changes to the SDK:
(working from memory here) After you build the SDK ('ant main') you
run the script 'ide/constructFlexForIDE' to prepare the SDK for use in
Flash Builder. You then create your test application (in which you
will reproduce the bug) to use this newly build and prepared SDK.
Now a question to all of you: can we make an app (or extend the
Installer) so the steps to prepare a system for building the SDK are
performed automatically?
- I think we can download and launch the installers (not sure if we
can poll for completion, though)
- we can create an env.properties with all the paths set, bypassing
the need to set system wide variables in obscure settings panes/files
- we can create a preset directory structure to hold the source files
and their dependencies (AIR SDK, playerglobal etc.)
- we can find and edit mm.cfg and create a FlashPlayerTrust file
- etc.
Does anyone see any major obstacles that I'm overlooking?
EdB
On Thu, Jul 25, 2013 at 1:31 PM, Justin Mclean <jus...@classsoftware.com> wrote:
> 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
--
Ix Multimedia Software
Jan Luykenstraat 27
3521 VB Utrecht
T. 06-51952295
I. www.ixsoftware.nl
