#6409 closed bug (invalid)
fadeTo and animate work not correctly with opacity in Linux Chrome and Chromium
Reported by: | Leolik | Owned by: | Leolik |
---|---|---|---|
Priority: | undecided | Milestone: | |
Component: | effects | Version: | 1.4.2 |
Keywords: | Cc: | ||
Blocked by: | Blocking: |
Description
If, in Linux Chrome or Chromium, tag have opacity 0.3 (for example) and you change it to 0.3 again, with fadeTo() or animate() - opacity changed to 0 and after this again changed to 0.3 - thats not correct. Sorry for my English.
Change History (12)
comment:1 Changed 13 years ago by
comment:3 Changed 12 years ago by
Owner: | set to Leolik |
---|---|
Priority: | → undecided |
Status: | new → pending |
Please submit a complete test case that reproduces this issue on jsFiddle so that we can fully investigate the issue you were experiencing.
comment:4 Changed 12 years ago by
Resolution: | → invalid |
---|---|
Status: | pending → closed |
Because we get so many tickets, we often need to return them to the initial reporter for more information. If that person does not reply within 14 days, the ticket will automatically be closed, and that has happened in this case. If you still are interested in pursuing this issue, feel free to add a comment with the requested information and we will be happy to reopen the ticket if it is still valid. Thanks!
comment:7 Changed 12 years ago by
Seems like any subsequent call to fadeTo() (after the initial one) on given element starts with opacity at 0.
comment:8 Changed 12 years ago by
This bug is caused by the fact that animate() assumes px unit for all values where unit is not given. Linux Chrome seems to be offended by that in case of opacity. After adding special case for opacity everything works properly.
Patch for jQuery 1.4.4 that does just that:
6490c6490 < e.custom( start, end, name != "opacity" ? unit : "" ); --- > e.custom( start, end, unit );
and same patch but for src/effects.js file in jQuery GIT:
206c206 < e.custom( start, end, unit ); --- > e.custom( start, end, name != "opacity" ? unit : "" );
I also forked jQuery at github applied this patch and made a Pull request. https://github.com/KamilSzot/jquery/commit/53b7d87f056fb03dc39a33513a4ac9106c36a28a
comment:9 Changed 12 years ago by
I made a mistake during testing and those patches do not fix the problem. Also assuming px unit does no harm as there is special case for opacity in jQuery.fx.step
comment:10 Changed 12 years ago by
I think I've found the real cause. It's bug in Chrome. I've filed the issue there: http://code.google.com/p/chromium/issues/detail?id=69180
comment:11 Changed 12 years ago by
You can work around the bug by replacing line:
var r = parseFloat( jQuery.css( this.elem, this.prop ) );
with:
var r = parseFloat( jQuery.css( this.elem, this.prop ).replace(",", ".") );
comment:12 Changed 12 years ago by
Below is much more elegant workaround, that I can use with standard minified release version of jQuery.
Just put it your code before using opacity animation:
var standardOpacityHook = jQuery.cssHooks.opacity.get jQuery.cssHooks.opacity.get = function( elem, computed ) { return standardOpacityHook(elem, computed).replace(",", "."); }
Just noticed that issue on Google Chrome 5.0.342.9 beta - Debian Lenny (2.6.26-2-686 GNU/Linux).