Bug Tracker

Opened 13 years ago

Closed 13 years ago

#1942 closed bug (fixed)

animating width/height of bordered objects in Opera

Reported by: wizzud Owned by: davidserduke
Priority: major Milestone: 1.2.2
Component: effects Version: 1.2.1
Keywords: opera animate borders Cc:
Blocked by: Blocking:

Description

Came across this problem whereby width/height animation in Opera, of an object that has a border, causes 'jumps' in the object size before resizing.

Demo and fix : http://www.wizzud.com/tester/operabug.html

This occurs because the borders are being included in the starting width and height when initialising the animation. The problem is located in fx.cur(), when curCSS() is used to get the width/height values.

I can only find this problem in Opera (tried IE6, IE7, FF1.5, FF2, Safari 2, Safari 3beta).

I have a rough patch (see below and demo) that fixes it, based on the theory that if width() and height() are the standard API methods for determining those particular values then why should animate() not use them too.

/* THE FIX : ...*/ jQuery.fx.prototype.cur = function(force){

if ( this.elem[this.prop] != null && this.elem.style[this.prop] == null )

return this.elem[ this.prop ];

wizzud...(opera screws up animation with borders)...inserted

if( this.prop == 'width'
this.prop == 'height')

return parseFloat(jQuery.css(this.elem, this.prop));

wizzud...end of insert

var r = parseFloat(jQuery.curCSS(this.elem, this.prop, force));

return r && r > -10000 ? r : parseFloat(jQuery.css(this.elem, this.prop))
0;

};

Attachments (1)

1942.diff (1.2 KB) - added by davidserduke 13 years ago.
proposed patch

Download all attachments as: .zip

Change History (3)

comment:1 Changed 13 years ago by davidserduke

Owner: set to davidserduke
Status: newassigned

You make a compelling test case. :)

I made a slight modification to your fix. It is essentially the same thing. jQuery.css calls jQuery.curCSS unless it is width/height so it is already doing that check. See if my logic makes sense here.

Current cur function:

cur: function(force){
  if ( this.elem[this.prop] != null && this.elem.style[this.prop] == null )
    return this.elem[ this.prop ];

  var r = parseFloat(jQuery.curCSS(this.elem, this.prop, force));
  return r && r > -10000 ? r : parseFloat(jQuery.css(this.elem, this.prop)) || 0;
},

New cur function:

cur: function(force){
  if ( this.elem[this.prop] != null && this.elem.style[this.prop] == null )
    return this.elem[ this.prop ];

  var r = parseFloat(jQuery.css(this.elem, this.prop, force));
  return r && r > -10000 ? r : parseFloat(jQuery.curCSS(this.elem, this.prop)) || 0;
},

jQuery.css calls jQuery.curCSS directly UNLESS it is width and height. So making the change to the 'var r' line to call .css instead of .curCSS (passing through force) is essentially putting in wizzud's fix. At this point I also changed the second function. If r is "false" or bad it tries the jQuery.curCSS call again without force to see if that can get the value and returns 0 if it can't. Since jQuery.css only does something different on width and height it makes sense to bypass .css and move to .curCSS since we already know .css has returned something bad !(r && r > -10000).

Changed 13 years ago by davidserduke

Attachment: 1942.diff added

proposed patch

comment:2 Changed 13 years ago by davidserduke

Resolution: fixed
Status: assignedclosed

Fixed in [3958].

Note: See TracTickets for help on using tickets.