Details
-
Bug
-
Status: Open
-
Minor
-
Resolution: Unresolved
-
Apache Flex 4.12.1
-
None
-
Tested on Mac OS X 10.9.2; probably affects other platforms as well
Description
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.