[
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 properly
> ---------------------------------------------------------------------------------------------
>
> 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
> .beginHighlightBitmapCapture()).
> 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
(v6.2#6252)
