Opened 10 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)
Change History (4)
Changed 10 years ago by
| Attachment: | opacity.html added |
|---|
comment:1 Changed 10 years ago by
| Milestone: | tbd → 1.5 |
|---|---|
| Owner: | changed from anonymous to Eugene Lazutkin |
| Status: | new → assigned |
comment:2 Changed 10 years ago by
comment:3 Changed 9 years ago by
| Resolution: | → fixed |
|---|---|
| Status: | assigned → closed |
Related to #10409.