[
https://issues.apache.org/jira/browse/FLEX-33311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15420940#comment-15420940
]
Mihai Chira edited comment on FLEX-33311 at 8/15/16 12:59 PM:
--------------------------------------------------------------
[~aharui] I'm attaching a stack trace xml. You can do a search for
{{clearConstraintCache }}. I know it's a bit overwhelming, but it shows how
{{Group.get baselinePosition()}} triggers a new validation cycle (started by
{{UIComponent.validateBaselinePosition()}}), which ends up closing the DropDown
({{DropDownListBase.close_updateCompleteHandler}}), which triggers another
validation (started by {{Effect.play()}}), which gets {{ConstraintLayout}} to
clear its cache (as it normally would). However, in the last 3 stacks we can
see that it returns to an outer validation cycle, which is still in
{{validateSize()}}, and the {{ConstraintLayout}} is now trying to access the
{{rowBaselines}} Array which it cleared when the inner validation cycle
(mentioned above) ended.
Still investigating what the best fix would be. Any ideas are welcome.
was (Author: evolverine):
[~aharui] I'm attaching a stack trace xml. I know it's a bit overwhelming, but
it shows how {{Group.get baselinePosition()}} triggers a new validation cycle
(started by {{UIComponent.validateBaselinePosition()}}), which ends up closing
the DropDown ({{DropDownListBase.close_updateCompleteHandler}}), which triggers
another validation (started by {{Effect.play()}}), which gets
{{ConstraintLayout}} to clear its cache (as it normally would). However, in the
last 3 stacks we can see that it returns to an outer validation cycle, which is
still in {{validateSize()}}, and the {{ConstraintLayout}} is now trying to
access the {{rowBaselines}} Array which it cleared when the inner validation
cycle (mentioned above) ended.
Still investigating what the best fix would be. Any ideas are welcome.
> 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, 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)
