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] [Created] (FLEX-34441) SparkSkin.endHighlightBitmapCapture() does not always restore contentBackgroundAlpha properly
Date Thu, 24 Jul 2014 10:42:41 GMT
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)

Mime
View raw message