[
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)
