Uploaded image for project: 'Apache Flex'
  1. Apache Flex
  2. FLEX-28098

SDK 4.5: changed implementation of Fade.getAffectedProperties() badly interacts with Resize effects

    XMLWordPrintableJSON

Details

    • Bug
    • Status: Closed
    • Major
    • Resolution: Fixed
    • Adobe Flex SDK 4.5 (Release)
    • Adobe Flex SDK Previous
    • Spark: Effects
    • None
    • Affected OS(s): All OS Platforms
      Affected OS(s): All OS Platforms
      Language Found: English

    Description

      Steps to reproduce:
      1. Build and execute testSDK45BugInEffects.mxml contained in the attached testSDK45BugInEffects.fxp using Flex SDK 4.5.
      2. This application contains two custom components using a skin which allows to expand/collapse the component by clicking the upper-left corner of each component. (The difference between the two components is that the one on the right side uses a workaround in its skin. For details, see the comments below.) Click the upper-left corner of both components and compare the new width of each.
      ==> The component on the left side (the one not using the workaround) has an incorrect width in collapsed state. The skin of the components has a sequence of Fade and Resize effects. When collapsing, the component starts shrinking progressively its size, but at the end of effects the initial width is restored, while it should not.
      3. Build and execute again the same app using Flex SDK 4.1 (or 4.0).
      ==> Now it runs as expected: after collapsing, both components have the same width.

      Actual Results:

      The two components (the one using the workaround and the one not using it) do not have the same width after the collapsing sequence of effects. The one not using the workaround has an incorrect width.

      Expected Results:

      The two components should have the same width after the collapsing sequence of effects.

      Workaround (if any):

      The behavior of SDK 4.0 and 4.1 can be restored by setting fade.relevantProperties to contain the same array as returned by Fade.getAffectedProperties in SDK 4.1:
      ["alpha", "visible", "parent", "index"]

      Comments:

      In SDK 4.1, Fade.getAffectedProperties returns ["alpha", "visible", "parent", "index"]. This list of properties fits more or less the fact that, as documented, Fade animates the "alpha" property and may affect the "visible" property as side-effect (while "parent" and "index" being apparently also somehow affected, although this is less clear from the documentation of the class Fade).

      Now, for some reason, in SDK 4.5 Fade.getAffectedProperties returns a much longer list of properties:
      ["alpha", "visible", "parent", "index", "explicitWidth", "explicitHeight", "rotation", "x", "y", "left", "right", "top", "bottom", "percentWidth", "percentHeight"]

      This change in SDK 4.5 looks strange, given the documentation of IEffect.getAffectedProperties:
      "Returns an Array of Strings, where each String is the name of a property changed by this effect. For example, the Move effect returns an Array that contains "x" and "y"."
      It is unclear why the Fade effect would now (SDK 4.5) also affect the size and position properties, while the doc of Fade still says that it affects the "alpha" property.

      In any case, the trouble is that this change breaks code that used to work with the previous SDK (4.0 and 4.1). Indeed, the documentation of IEffect.getAffectedProperties says "The EffectManager uses this method to ensure that no two effects are trying to animate the same property of the same object at the same time." Given that the list of properties declared as affected by Fade is now much longer, it is not surprising that this generates conflicts when Fade is used in a sequence with effects such as Resize.

      More exactly, the use-case of the attached sample which reproduces the regression in SDK 4.5 involves the following:

      • A sequence of Fade and Resize.
      • The sequence is triggered by state transitions.
      • The Resize effect has no explicit widthFrom/widthTo, instead the initial and final width are state-dependent (similar for the height).
      • The skin of the component has no explicit width/height at the top-level. Instead, the components adjusts its size to the size of an inner-component with explicit width/height.

      The suggested workaround consists in taking benefit of the fact that Effect.getAffectedProperties is only called if Effect.relevantProperties is not set. So, by setting fade.relevantProperties to contain the same array as returned by Fade.getAffectedProperties in SDK 4.1, the user can restore the previous behavior.

      Either the new implementation of Fade.getAffectedProperties is wrong and should not include the properties related with size and position, or there is a reason behind it but then it should be better documented (at minimum, in the incompatibilities section of the release notes) and especially a clean solution should be provided to avoid the misinteraction with Resize effects (a cleaner solution than the workaround proposed above).

      Attachments

        Activity

          People

            adobejira Adobe JIRA
            adobejira Adobe JIRA
            Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: