Skip to main content

Bug Tracker

Side navigation

#1942 closed bug (fixed)

Opened November 17, 2007 11:20PM UTC

Closed November 28, 2007 12:00AM UTC

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 November 18, 2007 02:21AM UTC.

    proposed patch

Change History (2)

Changed November 18, 2007 02:20AM UTC by davidserduke comment:1

owner: → 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 November 28, 2007 12:00AM UTC by davidserduke comment:2

resolution: → fixed
status: assignedclosed

Fixed in [3958].