flex-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tamás Nepusz (JIRA) <j...@apache.org>
Subject [jira] [Updated] (FLEX-34441) SparkSkin.endHighlightBitmapCapture() does not always restore contentBackgroundAlpha properly
Date Thu, 24 Jul 2014 10:42:42 GMT

     [ https://issues.apache.org/jira/browse/FLEX-34441?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel

Tamás Nepusz updated FLEX-34441:

    Attachment: SparkSkinBug.fxp

Flash Builder project to demonstrate the issue and a possible workaround.

> SparkSkin.endHighlightBitmapCapture() does not always restore contentBackgroundAlpha
> ---------------------------------------------------------------------------------------------
>                 Key: FLEX-34441
>                 URL: https://issues.apache.org/jira/browse/FLEX-34441
>             Project: Apache Flex
>          Issue Type: Bug
>          Components: Spark Components
>    Affects Versions: Apache Flex 4.12.1
>         Environment: Tested on Mac OS X 10.9.2; probably affects other platforms as well
>            Reporter: Tamás Nepusz
>            Priority: Minor
>              Labels: workaround
>         Attachments: SparkSkinBug.fxp
> SparkSkin.beginHighlightBitmapCapture() bumps the contentBackgroundAlpha style of the
component temporarily to 0.5 if it is less than 0.5 when the highlight bitmap is being captured,
in order to ensure that the captured bitmap includes an opaque snapshot of the background.
This is fine, but SparkSkin.endHighlightBitmapCapture() sometimes fails to restore the original
value of the contentBackgroundAlpha style. In particular, if the contentBackgroundAlpha is
set from CSS such that the value also depends on the state of the skin, .endHighlightBitmapCapture()
might restore the old value using setStyle() (and not clearStyle()), which prevents the state-dependent
CSS values from being applied, because the value set by setStyle() always takes precedence
over the value dictated by the CSS declarations.
> I'm attaching a project on which the issue can be reproduced. The project contains an
extended TextInput class called MyTextInput, which adds a new skin state named "editing" to
the TextInput field, allowing us to make the field look differently when it is in focus using
CSS declarations only. MyTextInput has two skins: MyTextInputSkin (which is identical to the
default Spark TextInput skin plus the extra "editing" state) and MyPatchedTextInputSkin (which
includes a workaround that we have found). The rules in defaults.css dictate that the contentBackgroundAlpha
of a MyTextInput field is 0.2 when it is not being edited, but it is 1.0 when it is being
edited. SparkSkin.beginHighlightBitmapCapture() and .endHighightBitmapCapture() is triggered
by adding an errorMessage to the text field (which creates an error skin, which in turn calls
> Steps to reproduce:
> 1. Start the application.
> 2. Click in the text field in the "Old Behaviour" column. Note that it turns fully opaque
when you click it.
> 3. Click on the "Add Error" button in the "Old Behaviour" column. Note that the text
field turns translucent again as the focus moves to the button, and the border of the text
field turns red to indicate the error.
> 4. Click in the text field again. Note that it turns fully opaque again.
> 5. Click in the other text field in the "With Workaround" column. Note that the text
field turns translucent. So far, so good.
> 6. Click in the first text field in the "Old Behaviour" column. This is where the bug
manifests itself.
> Expected behaviour:
> The first text field should turn fully opaque in step 6 above.
> Observed behaviour:
> The first text field stays translucent in step 6 above (because the contentBackgroundAlpha
style in the CSS is not applied), but its text turns black (indicating that the _other_ style
in the same CSS declaration that dictated contentBackgroundAlpha: 1 got applied).
> Workaround:
> Our workaround proposed in MyPatchedTextInputSkin relies on the internals of SparkSkin.endHighlightBitmapCapture()
where we force Spark to take the route where clearStyle() is called instead of setStyle()
with the old value. This is achieved by temporarily modifying the styleDeclarations internal
variable and removing contentBackgroundAlpha from it, so beginHighlightBitmapCapture() will
"think" that it is not modified in any way.

This message was sent by Atlassian JIRA

View raw message