[ 
https://issues.apache.org/jira/browse/FLEX-34441?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14073073#comment-14073073
 ] 

Tamás Nepusz edited comment on FLEX-34441 at 7/24/14 10:42 AM:
---------------------------------------------------------------

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


was (Author: ntamas):
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)

Reply via email to