Tamás Nepusz created FLEX-34441:
-----------------------------------
Summary: 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
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)
