Opened 9 years ago

Closed 9 years ago

#10408 closed defect (fixed)

bug in dojo._setOpacity "anti-fuzzy" fix

Reported by: CnEY Owned by: Eugene Lazutkin
Priority: high Milestone: 1.5
Component: Core Version: 1.4.0b
Keywords: opacity Cc:
Blocked By: Blocking:

Description

The fix (and evolution thereof) initially introduced for bug #2661 misses a possibly obscure margin case: if opacity (or in IE's case, filter) has never been set on the element before, and _setOpacity is called with an opacity value of 1, the filter is not disabled as intended. This is because the code to disable the filter occurs before the filter is actually brought into existence; moving the code to after filter is set fixes the issue.

Attached is a small test page. To reproduce, simply click the "Set opacity to 100%" button once; if you can't eyeball it (it's obvious in IE6, or any version of IE with cleartype on), click the "is filter enabled?" button - it will alert true, when it should alert false. Clicking the 100% button a second time will cause it to be set to false, since then the filter has already been added to the node and thus could be disabled.

I tested this in 1.3.2, but it presumably exists also in 1.4 RC since upon inspection of the source, the code in question is still in the same state.

Attachments (1)

opacity.html (751 bytes) - added by CnEY 9 years ago.

Download all attachments as: .zip

Change History (4)

Changed 9 years ago by CnEY

Attachment: opacity.html added

comment:1 Changed 9 years ago by Eugene Lazutkin

Milestone: tbd1.5
Owner: changed from anonymous to Eugene Lazutkin
Status: newassigned

comment:2 Changed 9 years ago by Eugene Lazutkin

Related to #10409.

comment:3 Changed 9 years ago by Eugene Lazutkin

Resolution: fixed
Status: assignedclosed

(In [21800]) ONly existing filter should be disabled, thx CnEY!, !strict, fixes #10408.

Note: See TracTickets for help on using tickets.