Skip to content
Permalink
Browse files
Fix #11469. Exclude margins from the negative property check.
  • Loading branch information
@dmethvin
louisremi authored and dmethvin committed Mar 21, 2012
1 parent f40c862 commit 07c8a9b2448f42ee940e7fc1351344eb372f7463
Unified Split
Showing with 6 additions and 3 deletions.
  1. +6 −3 src/effects.js
9 src/effects.js
View file
@@ -636,9 +636,12 @@ jQuery.extend( jQuery.fx, {

// Ensure props that can't be negative don't go there on undershoot easing
jQuery.each( fxAttrs.concat.apply( [], fxAttrs ), function( i, prop ) {
jQuery.fx.step[ prop ] = function( fx ) {
jQuery.style( fx.elem, prop, Math.max(0, fx.now) + fx.unit );
};
// exclude marginTop, marginLeft, marginBottom and marginRight from this list
if ( prop.indexOf( "margin" ) ) {
jQuery.fx.step[ prop ] = function( fx ) {
jQuery.style( fx.elem, prop, Math.max(0, fx.now) + fx.unit );
};
}
});

if ( jQuery.expr && jQuery.expr.filters ) {

11 comments on commit 07c8a9b

@Krinkle

This comment has been minimized.

Sign in to view
Copy link
Member

@Krinkle Krinkle replied Mar 21, 2012

if ( prop.indexOf( "margin" ) ) { looks a bit counter-intuitive when meant to "exclude margin". I know it works because -1 (no matches) is considered true-ish in JavaScript, but > 0 is also true-ish. Perhaps use if ( prop.indexOf( "margin" ) === -1 ) { instead?
@rwaldron

This comment has been minimized.

Sign in to view
Copy link
Member

@rwaldron rwaldron replied Mar 21, 2012

The condition only cares about prop.indexOf( "margin" ) matching "margin" at 0: [margin]Top, [margin]Left, [margin]Bottom, [margin]Right. So what is the point in the additional bytes?
@jaubourg

This comment has been minimized.

Sign in to view
Copy link
Member

@jaubourg jaubourg replied Mar 21, 2012

I dunno, code is not that clear to me either... !/^margin/.test( prop ) would have been better imo and happens to be a byte shorter.
@rwaldron

This comment has been minimized.

Sign in to view
Copy link
Member

@rwaldron rwaldron replied Mar 21, 2012

@jaubourg I'm a sucker for a valid argument. +1

I'm still a little put off that this landed with no test to prove its failure.
@Krinkle

This comment has been minimized.

Sign in to view
Copy link
Member

@Krinkle Krinkle replied Mar 21, 2012

@rwldrn I agree, this went in a little too easy. I keep up with jquery core as much as I can but I only found out about this fix via the release notes in the blog post..
@dmethvin

This comment has been minimized.

Sign in to view
Copy link
Member

@dmethvin dmethvin replied Mar 21, 2012

Well, that's just me being lazy. I really wanted to get 1.7.2 out today but this was definitely a regression. I almost added !== 0 but meh. I don't have time to test it but String.indexOf is probably faster than RegExp.test() if it makes any difference. We can make it pretty for 1.8 but if it hadn't have landed I suspect it would have been a strong case for 1.7.3.
@rwaldron

This comment has been minimized.

Sign in to view
Copy link
Member

@rwaldron rwaldron replied Mar 21, 2012

@dmethvin don't get me wrong, I support your decision to land this and for the same reason. I'm just not sure how a patch can even be written without a test accompanying it, know what I mean? Always write the test first and then fix the bug.
@jaubourg

This comment has been minimized.

Sign in to view
Copy link
Member

@jaubourg jaubourg replied Mar 21, 2012

@dmethvin same as Rick. We all agree this needed to be in 1.7.2.
@mikesherov

This comment has been minimized.

Sign in to view
Copy link
Member

@mikesherov mikesherov replied Mar 22, 2012

+1 to @louisremi with the fix, but also +1 to @rwldrn. IMHO, untested code is broken code. We're just as vulnerable to another regression here as we were before. I think I'll write the tests myself just to make sure I won't cause this regression in 1.8.
@louisremi

This comment has been minimized.

Sign in to view
Copy link
Contributor

@louisremi louisremi replied Mar 22, 2012

I've already written this test and I'll send a PR today with additional tests.
Sorry for not doing it earlier.
Should I switch the condition to what @jaubourg proposed in the same PR or in a separate branch? I don't think the perf. difference matters, it's run only once, when the lib is loaded.
Sorry for the counter-intuitive mind ;-)
@mikesherov

This comment has been minimized.

Sign in to view
Copy link
Member

@mikesherov mikesherov replied Mar 22, 2012

Thanks again @louisremi for the fix!
Please sign in to comment.