flex-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alex Harui (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (FLEX-33311) Nullpointer in ConstraintLayout when executing Transition on DropDownList
Date Mon, 15 Aug 2016 20:13:22 GMT

    [ https://issues.apache.org/jira/browse/FLEX-33311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15421598#comment-15421598
] 

Alex Harui commented on FLEX-33311:
-----------------------------------

I took a look.  In the failure case I saw that the baselinePosition calculation forces a call
to parseConstraints while a parseConstraints is already in progress.  It appears that the
ConstraintLayout wasn't written to expect nested calls to parseConstraints which is why it
thinks it can get away with clearing the cache at the end of parseContraints.

I didn't spend too much time thinking about the "right solution",  Below is a diff where I
check for nesting and don't clear the cache.  There's a chance that might pick up some stale
data.  An alternative is to have parseConstraints exit without doing anything if it sees it
is a nested call.  There are probably more sophisticated and accurate solutions.

diff --git a/frameworks/projects/spark/src/spark/layouts/ConstraintLayout.as b/f
index 64db42d..1a45d4e 100644
--- a/frameworks/projects/spark/src/spark/layouts/ConstraintLayout.as
+++ b/frameworks/projects/spark/src/spark/layouts/ConstraintLayout.as
@@ -1595,6 +1595,8 @@ public class ConstraintLayout extends LayoutBase
         return vec;
     }
     
+    private var inParseConstraints:int = 0;
+    
     /**
      *  @private
      *  Iterates over elements and calls parseElementConstraints on each.
@@ -1620,6 +1622,8 @@ public class ConstraintLayout extends LayoutBase
         else
             rowBaselines.length = 0;
         
+        inParseConstraints++;
+        
         for (i = 0; i < n; i++)
         {
             row = _constraintRows[i];
@@ -1641,6 +1645,9 @@ public class ConstraintLayout extends LayoutBase
         }
         
         this.constraintCache = cache;
+        
+        inParseConstraints--;
+        
     }
     
     /**
@@ -1833,6 +1840,11 @@ public class ConstraintLayout extends LayoutBase
      */
     private function clearConstraintCache():void
     {
+        if (inParseConstraints)
+        {
+            return;
+        }
+        
         colSpanElements = null;
         rowSpanElements = null;
         otherElements = null;


> Nullpointer in ConstraintLayout when executing Transition on DropDownList
> -------------------------------------------------------------------------
>
>                 Key: FLEX-33311
>                 URL: https://issues.apache.org/jira/browse/FLEX-33311
>             Project: Apache Flex
>          Issue Type: Bug
>          Components: Spark: Layout, Transitions
>    Affects Versions: Apache Flex 4.8 (parity release)
>            Reporter: Maxime Cowez
>            Assignee: Mihai Chira
>             Fix For: Apache Flex 4.9.0
>
>         Attachments: Main.mxml, SpecifiableListWrapper.as, SpecifiableListWrapperHorizontalSkin.mxml,
stack.xml, stacks.txt
>
>
> In some very specific cases {{ConstraintLayout}} will throw a null pointer error when
a component inside it is playing a transition. I tried a few things and found out that:
> * {{parseConstraints()}} creates a new {{rowBaselines}} Vector (or empties it if it exists)
> * some other process calls {{clearConstraintCache()}} in the middle of the execution
of {{parseConstraints()}}, setting {{rowBaselines}} back to {{null}}
> * {{parseConstraints()}} calls {{parseElementConstraints()}} which tries to access elements
in {{rowBaselines}} and throws the error
> I know very little about how Effects and Transitions work, so the "some other process"
part is a bit of a mistery to me.
> *Steps to reproduce*:
> # Compile and run Main.mxml
> # Select the first item in the list
> # Click on the list and, before the resize transition finishes, click on it again.
> *Workaround*: subclass ConstraintLayout (or FormItemLayout), override `measure()`, put
a try/cacth block around it and use this custom layout. Not exactly pretty but it works without
apparent side effects.
> *Quick fix* (but probably not the ideal solution): just test whether {{rowBaselines}}
exists before trying to access it in {{ConstraintLayout.parseElementConstraints()}}.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message