Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP

Loading…

[1.9] Prevent Clearing Cloned Style to Affect Source Element's Style. Fixes #8908 #886

Closed
wants to merge 76 commits into from
@elijahmanor

Clearing a Cloned Element's Style Causes the Original Element's Style to be Cleared

Introduction

In IE9 and IE10 you can run into the situation when clearing ("") a cloned element's style will also clear out the original element's corresponding style.

The actual jQuery Core Ticket #8908 isolates the bug when using the background-image style.

While I was trying to recreate and research this issue I had a feeling that there may be other styles that have the same issue, so I've created a test suite checking 252 CSS1-3 styles and testing various assertions.

Along the way, I also found some additional inconsistencies. These findings are technically unrelated to the #8908 issue so I will list those inconsistencies somewhere else and we can discuss those later.

Source Element's Style Cleared When Cloned Element's Style Cleared

IE9 & IE10

After testing 252 various styles only the following 8 ended up being problematic.

  • background-attachment
  • background-color
  • background-image
  • background-position
  • background-repeat
  • background-clip
  • background-origin
  • background-size

IE 6/7/8, Chrome, Firefox, Opera

Thankfully these browsers did not have the problem described in this issue when tested.

Proposed Solutions

1. Use Default Values when Trying to Empty Style

The following fix resolves the weird issue by substituting and empty string with it's default value. An object is used to store the style name and associated default value. If the value happens to be an empty string then it will look in the object for a matching key and if there is a match it will use that instead.

// css.js
+ // These styles were identified to be problems in IE9/10
+ var defaultValue = {
+     "background-attachment": "scroll",
+     "background-color": "transparent",
+     "background-image": "none",
+     "background-position": "0% 0%",
+     "background-repeat": "repeat",
+     "background-clip": "border-box",
+     "background-origin": "padding-box",
+     "background-size": "auto auto"
+ };

+ value = ( value === "" && defaultValue[ name ] !== undefined ) ? defaultValue[ name ] : value;

try {
    style[ name ] = value;
} catch(e) {}

Pros

  • This is very explicit in describing which styles are problematic in IE

Cons

  • There is extra code executed when clearing the style for a nonIE browser. This could be a problem because updating a style via the .css() method is very common
  • There is a considerable amount of code to account for all problematic styles and this will bloat the jQuery source

2. Strange Side Effect That Breaks the Clone Connection

This solution is a little more strange and not so obvious. I ran into this fix as I was building up my unit tests and asserting a bunch of things I thought should be true. One of those assertions was verifying that when setting a style using the $elem.css( "someStyle", "someValue" ) method that it actually worked. So, I used the getter ($elem.css( "someValue" ) method, but by doing so I found the problem going away just by calling the getter! And with that the following solution came about.

You may notice a slightly strange piece of code ( window.getComputedStyle( elem, null ) || {} ), but that was needed to get around an Opera bug I had when working with XML nodes. Technically I could have made the whole fix into one statement, but the minification process does a decent job of squishing down the fix to look like (b.nodeType===1&&a.getComputedStyle&&(i=(a.getComputedStyle(b,null)||{}).backgroundImage).

// clone.js
jQuery.extend({
    clone: function( elem, dataAndEvents, deepDataAndEvents ) {
        var srcElements,
            destElements,
            i,
-           clone;
+           clone,
+           fix8908;

        if ( jQuery.support.html5Clone || jQuery.isXMLDoc(elem) || !rnoshimcache.test( "<" + elem.nodeName + ">" ) ) {
+           // Fixes #8909 - By accessing one of the element's computed styles it breaks the
+           // connection with the cloned element's styles in IE9/10
+           if ( elem.nodeType === 1 && window.getComputedStyle ) {
+               fix8908 = ( window.getComputedStyle( elem, null ) || {} ).backgroundImage;
+           }
+
            clone = elem.cloneNode( true );
        // IE<=8 does not properly clone detached, unknown element nodes
        } else {
            ...
        }
        ...
    },
    ...
});

Pros

  • The amount of code for this fix is relatively small
  • This code is limited to the clone execution path, which happens infrequently when compared to the .css() method approach in option #1.

Cons

  • This relies on a weird quirk in IE9/10 to get around the problem, but it seems to be the most succinct.

3. Have IE9 & IE10 Fix this Bug

It would be ideal if no patch had to be made to jQuery at all and IE9 and IE10 could apply a fix instead. Seeing that the issue is found in IE9 though may rule out this option entirely.

Pros

  • No patch for jQuery would be needed

Cons

  • Even if the bug was fixed immediately for IE9 & IE10 there would still be an issue with versions of IE9 that didn't have the IE fix.

Unit Test

The following Unit Test exposes the problem in IE9 and IE10. In browsers that don't support these styles I am skipping over them and asserting that they are not an issue.

test( "Clearing a Cloned Element's Style Shouldn't Clear the Original Element's Style (#8908)", function() {
    expect( 8 );

    var baseUrl = document.location.href.replace( /([^\/]*)$/, "" );
    var styles = [
        { name: "background-attachment", value: [ "fixed" ], expected: [ "scroll" ] },
        { name: "background-color", value: [ "rgb(255, 0, 0)", "rgb(255,0,0)" ], expected: [ "transparent" ] },
        { name: "background-image", value: [ 'url("test.png")', 'url(' + baseUrl + 'test.png)', 'url("' + baseUrl + 'test.png")' ], expected: [ "none" ] },
        { name: "background-position", value: [ "5% 5%" ], expected: [ "0% 0%" ] },
        { name: "background-repeat", value: [ "repeat-y" ], expected: [ "repeat" ] },
        { name: "background-clip", value: [ "content-box" ], expected: [ "border-box" ] },
        { name: "background-origin", value: [ "content-box" ], expected: [ "padding-box" ] },
        { name: "background-size", value: [ "80px 60px" ], expected: [] }
    ];

    jQuery.each( styles, function(index, style) {
        var $source, source, $clone;

        style.expected = style.expected.concat( [ "", "auto" ] );
        $source = jQuery( "<div />" );
        source = $source[ 0 ];
        if ( source.style[ style.name ] === undefined ) {
            ok( true, style.name +  ": style isn't supported and therefore not an issue" );
            return true;
        }
        $source.css( style.name, style.value[0] );
        $clone = $source.clone();
        $clone.css( style.name, "" );

        ok( ~jQuery.inArray( $source.css( style.name ), style.value ),
            "Clearning clone.css() doesn't affect source.css(): " + style.name +
            "; result: " + $source.css( style.name ) +
            "; expected: " + style.value.join( "," ) );
    });
});

Conclusion

Based on the research I have done testing 252 CSS styles I have isolated this issue to only 8 styles in IE9 and IE10.

I've recommended solving this issue 3 different ways, but in the end the 2nd option seems best to me since it only is executed in the clone execution path and is significantly smaller than the 1st option. The 3rd option of having IE fix this issue seems too late since the issue also affects IE9.

@dmethvin
Owner

Nice detective work! :+1: I think we'll have to land something in 1.9/2.0 since IE9 is not gonna get fixed and I think it's even too late for an IE10 fix at this point since they have gone RTM with Windows 8.

The call to getComputedStyle on the clone source element worries me from a performance perspective because I think that will cause a reflow in many cases. It would be good to perf test it and if needed use a feature test for the bug to ensure that only the guilty browsers are hurt by any performance hit.

There's a very similar-sounding bug regarding .clone() in IE7 ... I wonder if it could be solved the same way? http://bugs.jquery.com/ticket/9777

The commits are kind of messed up, probably because you submitted the earlier pull from your master, but we can cherry-pick d5d8622 off there. If you haven't already you should probably clean up your master if you haven't already. http://stackoverflow.com/questions/1628088/how-to-reset-my-local-repository-to-be-just-like-the-remote-repository-head

@elijahmanor

Yeah, I wondered if the PR came in clean or not. Arg. Yeah, I'll try what is listed on that SO link.

The fix comes down to adding the following before the call to elem.cloneNode( true );

// Fixes #8909 - By accessing one of the element's computed styles it breaks the
// connection with the cloned element's styles in IE9/10
if ( elem.nodeType === 1 && window.getComputedStyle ) {
    fix8908 = ( window.getComputedStyle( elem, null ) || {} ).backgroundImage;
}

As one of the cons I mentioned performance because it would run that code for any browser. I wasn't sure a good way to isolate just to IE9/10.

Good point about causing a reflow. I'm not sure about that one, but I can try to dig into that further.

I'll take a look at #9777 as you mentioned. It maybe be related, but as for the above bug it didn't show itself in IE7.

I figured this PR would probably wait since 1.8 is about finalized. Thanks for your feedback.

If you have any ideas on how to isolate this to IE9/10 I am all ears ;)

src/manipulation.js
@@ -585,11 +585,17 @@ jQuery.extend({
var srcElements,
destElements,
i,
- clone;
+ clone,
+ fix8908;
@rwaldron Collaborator
rwaldron added a note

I'd like to avoid having numbered identifiers. This seems like something that belongs in the support module.

@rwldrn Yeah, I wasn't too thrilled about that either, but the fix depends on getting a style off of the object returned from getComputedStyle(). The reason I went ahead and saved it off to a variable was to get around the Expected an assignment or function call and instead saw an expression. JSHint error. I could save it off to an existing variable such as i, but that felt weird too.

I am thinking of pulling out a feature detection into the jQuery.support module to test for this strange bug so that it can be scoped to only IE9/10 and not affect the performance of other browsers.

With this support feature, I will still need to save the style to a variable for JSHint to like it. Would you recommend renaming the variable, reusing another variable, or something else?

@rwaldron Collaborator
rwaldron added a note

This is a strange thing... It's really bothersome that IE10 actually released a browser that allows a clone's style property to retain reference to the source element.

Anyway, yeah this belongs in jQuery.support, maybe called jQuery.support.whenWillTheyLearn ;)

@dmethvin Owner
dmethvin added a note

Instead of having the ticket number in the variable name, usually we mention the ticket in a short comment. So you can just pick a short name or even reuse i if it isn't used in the code path.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
@elijahmanor

Changes Since the Initial Pull Request

Source Code Changes

I make a new test in the support module called clearCloneStyle that is true if the browser clears only the clone's style appropriate, but is false if it incorrectly clear's the original element's style as IE9 and IE10 do with 8 different styles. I picked the shortest style name of the 8 to test to keep the code short. The feature test intentionally doesn't use jQuery in order to keep the test as fast as possible.

support.clearCloneStyle = (function() {
    var source = document.createElement( "div" ),
        styleName = "backgroundClip",
        value = "content-box",
        clone;

    source.style[ styleName ] = value;
    clone = source.cloneNode( true );
    clone.style[ styleName ] = "";

    return source.style[ styleName ] === value;
})();

I am using the support.clearCloneStyle property in the fix right before the clone in manipulation.js

...
if ( jQuery.support.html5Clone || jQuery.isXMLDoc(elem) || !rnoshimcache.test( "<" + elem.nodeName + ">" ) ) {
+    // Fixes #8909 - By accessing one of the element's computed styles it breaks the
+    // connection with the cloned element's styles in IE9/10
+    if ( !jQuery.support.clearCloneStyle && elem.nodeType === 1 &&
+        window.getComputedStyle ) {
+        i = ( window.getComputedStyle( elem, null ) || {} ).backgroundPosition;
+    }

    clone = elem.cloneNode( true );
    ...
}
...

As I was retesting the code in IE6/7/8/9/10 I noticed that one of the styles (backgroundPosition) was not passing in IE9 :( The weird getComputedStyle call fixed all of the 8 broken styles in IE10, but only 7 of them in IE9. So, I had to add the following code in the style method of the css.js file to fix that outlier.

...         
// If a hook was provided, use that value, otherwise just set the specified value
if ( !hooks || !("set" in hooks) || (value = hooks.set( elem, value, extra )) !== undefined ) {
+    // IE9/10 Clearing Cloned Style Clear's Original Style. Fixes bug #8908
+    value = !jQuery.support.clearCloneStyle && value === "" && 
+        name.match( /backgroundPosition/ ) ? "0% 0%" : value;

    // Wrapped to prevent IE from throwing errors when 'invalid' values are provided
    // Fixes bug #5509
    try {
        style[ name ] = value;
    } catch(e) {}
}
...

Browsers Tested

I have run the above changes through the following browsers

Windows

  • Chrome 22d/21.0b/20/19/18/17/16/15/14
  • Firefox 15.0b/14/13/12/11/10/9/8/7/6/5/4/3.6/3
  • IE 10/9/8/7/6
  • Opera 12.5b/12.0/11.6/11.5/11.1/10.0
  • Safari 5.1/5.0/4.0

Mac

  • Chrome 20.0b/19/18/17/16/14
  • Firefox 14.0b/13/12/11/10/9/8/7/6/5
  • Opera 12/11.6/11.1
  • Safari 5.1/5.0/4.0

Unit Test Changes

As I was testing the code in all the above browsers I added another assertion to the Unit Test to check if the style that was being cleared on the clone element was indeed being reset. Because of that addition assertion I made the following changes...

  • Added a unit test to verify that the clone was indeed reset correctly
  • Add the #ff0000 value to match the backgroundColor for Opera 11.1
  • When a background-image is cleared in Firefox it sets the value to the full image path that it is inheriting
  • Added the -1000px 0% value to match the backgroundPosition for Firefox 5.0
  • Switched background-clip to padding-box because Safari 5.0 doesn't support that value

Summary of Changes

  • I added the jQuery.support.clearCloneStyle check and used it before the elem.cloneNode( true ) to limit when a call to getComputedStyle occurs (IE9 / 10)
  • I had to add another fix in the style method to fix the backgroundPosition style that wasn't fixed by the getComputedStyle above. This code path is also limited by the jQuery.support.clearCloneStyle check.
  • I added another assertion to the Unit Test to verify that clearing out the style indeed resets it to an expected default value.
@fracmak fracmak commented on the diff
src/css.js
@@ -204,6 +204,9 @@ jQuery.extend({
// If a hook was provided, use that value, otherwise just set the specified value
if ( !hooks || !("set" in hooks) || (value = hooks.set( elem, value, extra )) !== undefined ) {
+ // IE9/10 Clearing Cloned Style Clear's Original Style. Fixes bug #8908
+ value = !jQuery.support.clearCloneStyle && value === "" && name.match( /backgroundPosition/ ) ? "0% 0%" : value;
@fracmak
fracmak added a note

Is this a regex because of backgroundPositionX and backgroundPositionY? Is that value still work for those? Also, can you move the regex out to it's own variable at the top of the file with the other regex's so it can get cached?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
@jaubourg
Collaborator

Isn't keeping the tests for browsers with JSON.parse the best way to make sure we have the same behaviour across browsers? Or am I missing something here?

Owner

We can only compare our results to json.parse on browser that have the native method. I agree it's not optimal to test this everywhere but where we actually use it. Perhaps we dump this test's attempt to compare since we don't care about the native result.

Collaborator

Oh, I get what you mean now. Why not just put the tests with the expected result using jQuery.parseJSON only? Browsers with JSON.parse support will use this code path, others will use our polyfil. We'd have some sort of comparison... just not in the same browser but between browsers. Makes sense?

Collaborator

I'm with @jaubourg on this one... JSON.parse is just another component we abstract, and will have to normalize if a flaw is discovered in some environment's native implementation.

dmethvin and others added some commits
@dmethvin dmethvin Combine parseJSON tests and fix style.
We only care about the result of parseJSON so there's no reason to feature detect the entire test.
32051e9
@gibson042 gibson042 Fix #4262: faster .eq(), closes gh-1000. b5084b4
Sai Wong Fix #12610, remove unneeded window.event. Close gh-968. 5228f0a
@mikesherov mikesherov adding awesome new contributors to AUTHORS.txt a7a8aad
@fracmak fracmak Fixes #12518, removes an offsetWidth on focus/blur events for an <IE9…
… bug that caused a performance hit. Closes gh-958
408e5e0
@jonathansampson jonathansampson Fix attribute names in aliased form property test. Close gh-951.
Test expects input elements having name='id', name='name', and name='target'. Additionally, these should have id='id', id='name', and id='target' respectively. No element was provided with id='id' or name='id', but rather one element had two name attributes (illegal) with the values 'id' and 'name' respectively.
144b8bf
Sai Wong Fix #12048. Set attributes for XML fragments. Close gh-965. 2b0e720
@rwaldron rwaldron Don't expose jQuery.deletedIds. Close gh-889. 8076a33
@markelog markelog Alternate fix for #11426; check responseText. Close gh-843. cafb542
Marcel Greter Fix #12107. Let .proxy() curry args without overwriting context. Close de9ff7c
@gibson042
Collaborator

You might as well remove the definitions of jQuery.deletedIds and jQuery.uuid while you're in there. 1.9 approaches!

dmethvin and others added some commits
@Krinkle

Very deep ;-)

Collaborator

Haha that was previously much deeper ;) a little copy pasta there

@Krinkle

Maybe additionally assert that the return value is strictEqual to $div? That way it doesn't just assert it being a no-op, but it also actually being chainable.

edit: Done in pull #1008.

@rwaldron
Collaborator

We should encourage new tests to be in their own call to test( ... )

Collaborator

Had it that way first, but decided it belonged in the same test block. Next time we won't. Good to know. Thanks!

Krinkle and others added some commits
@Krinkle Krinkle Implement expectation test instead of using _removeData. Close gh-997.
* Removed inline usage of QUnit.reset() because it is messing with the
  expectation model as reset does .empty() which does a recursive cleanData
  on everything in #qunit-fixture, so any expectJqData above .reset() would
  fail negatively.

  Instead of calling reset inline, either updated the following assertions to
  take previous assertions' state into account, or broke the test() up into
  2 tests at the point where it would call QUnit.reset.

* After introducing the new memory leak discovery a whole bunch of tests were
  failing as they didn't clean up everything. However I didn't (yet) add
  QUnit.expectJqData calls all over the place because in most if not all of
  these cases it is valid data storage. For example in test "data()", there
  will be an internal data key for "parsedAttrs". This particular test isn't
  intending to test for memory leaks, so therefor I made the new discovery
  system only push failures when the test contains at least 1 call to
  QUnit.expectJqData.

  When not, we'll assume that whatever data is being stored is acceptable
  because the relevant elements still exist in the DOM anyway (QUnit.reset
  will remove the elements and clean up the data automatically).

  I did add a "Always check jQuery.data" mode in the test suite that will
  trigger it everywhere. Maybe one day we'll include a call to everywhere,
  but for now I'm keeping the status quo: Only consider data left in storage
  to be a problem if the test says so ("opt-in").

* Had to move #fx-tests inside the fixture because ".remove()" test would
  otherwise remove stuff permanently and cause random other tests to fail
  as "#hide div" would yield an empty collection.
  (Why wasn't this in the fixture in the first place?)

  As a result moving fx-tests into the fixture a whole bunch of tests failed
  that relied on arbitrary stuff about the document-wide or fixture-wide
  state (e.g. number of divs etc.). So I had to adjust various tests to
  limit their sample data to not be so variable and unlimited...

* Moved out tests for expando cleanup into a separate test.

* Fixed implied global variable 'pass' in effects.js that was causing
  "TypeError: boolean is not a function" in *UNRELATED* dimensions.js that
  uses a global variable "pass = function () {};" ...

* Removed spurious calls to _removeData. The new test exposed various failures
  e.g. where div[0] isn't being assigned any data anyway.
  (queue.js and attributes.js toggleClass).

* Removed spurious clean up at the bottom of test() functions that are
  already covered by the teardown (calling QUnit.reset or removeClass to
  supposedly undo any changes).

* Documented the parentheses-less magic line in toggleClass. It appeared that
  it would always keep the current class name if there was any (since the
  assignment started with "this.className || ...".

  Adding parentheses + spacing is 8 bytes (though only 1 in gzip apparently).
  Only added the comment for now, though I prefer clarity with logical
  operators, I'd rather not face the yayMinPD[1] in this test-related commit.

* Updated QUnit urlConfig to the new format (raw string is deprecated).

* Clean up odd htmlentities in test titles, QUnit escapes this.
  (^\s+test\(.*)(&gt\;) → $1>
  (^\s+test\(.*)(&lt\;) → $1<

[1] jQuery MinJsGz Release Police Department (do the same, download less)
36c9ecb
@dmethvin dmethvin Update authors. 5be4c10
@markelog markelog Fix #10416. Don't trust computed styles on detached elements. Close g… bea5ecb
@yiminghe yiminghe Fix #12685. Handle inconsistent opacity for ie < 9. Close gh-1005. c78a3ba
@mikesherov mikesherov Fix #12009. $().find( DOMElement ) should pushStack properly. Close g… e8f9151
@gibson042
Collaborator

Seems like we'd be better off with jQuery.unique than this.

Collaborator

I presumed this was faster because in this case we already knew the prevLength.

Owner

The previous code wasn't using it either, and i made the same assumption as @mikesherov. I have absolutely no evidence to back up whether it's faster or whether it being somewhat faster makes a difference, but it FEELS like it should. :ghost:

Collaborator

True, but it also checks the entirety of prevLength on every outer iteration. I can't say for sure that jQuery.unique would be faster in the average case (not that I would be surprised, either), but it would be smaller, clearer, and always return elements in DOM order (see http://jsfiddle.net/EAtqe/ for a demonstration of the current behavior).

Collaborator

If this is a correctness issue (re: DOM order), we should fix it.

Collaborator

Although, we should open a separate issue for that :-)

@gibson042
Collaborator

.selector is only relevant for the string case... why not early return this.pushStack( jQuery( selector ).filter(function() { ... }) ) if selector is not a string and skip the else block entirely?

Collaborator

Not a bad idea.

Owner

Yeah I agree that makes more sense. I can do a followup.

@dmethvin
Owner

Damn, forgot to add another test!

@dmethvin

Dunno if it's the trailing comma, but jshint is throwing a fit about the unit tests now.

Yep, where in JS it is sometimes tolerated, in JSON it is always invalid. Depending on the jshint implementation it will ignore the entire file and consider it invalid JSON because the parser used is unable parse the JSON.

Collaborator

Color me ashamed. Fix forthcoming (if not already in).

@Krinkle

Trailing comma!

Collaborator

unnecessary semi.

@Krinkle

Trailing comma!

Collaborator

unnecessary semi.

Lol, yes of course, that's what I meant :open_mouth:

@Krinkle

Trailing comma!

Collaborator

unnecessary semi.

@Krinkle

This broke 300+ tests in module "effects" and 5 in "core" (in all browsers).

EDIT: Follow-up: 68f001e.

Collaborator

That sounds like a record!

@markelog
Collaborator

sorry about that :-(

@dmethvin
Owner

@elijahmanor can you rebase this when you get a chance? It's gotten a bit stale but I'm ready to land it for 1.9. Let me know if you need any help.

@Krinkle

Do we have tests for jQuery( .., methods );? Or did you remove the only (indirect) tests for that?

Yep! :smile:

@scottgonzalez

There are still calls to jQuery.access() which pass 7 parameters. For example, .data() uses all 7 params and sets pass to false. We used to determine if function values should be executed based on pass, but now it's based purely on value. This breaks .data( "foo", function() {} ).

@gnarf
Owner

Ack sorry I got your name typed wrong @lukemelia

No worries. Thanks for getting this fix in!

@elijahmanor

@dmethvin I just pulled in the changes and fixed the differences. Unfortunately I saw you said "rebase" after I pushed ;( So there are tons of commits shown.

@dmethvin dmethvin referenced this pull request from a commit
Commit has since been removed from the repository and is no longer available.
@timmywil
Collaborator

Didn't actually close.

@timmywil timmywil closed this
@dmethvin
Owner

I haven't landed this yet, I just created a branch for @elijahmanor to review.

@dmethvin dmethvin reopened this
@timmywil
Collaborator

Woops, read the close, thought it needed to be closes/closed. :/

@aFarkas

Great, just saw, that this little bug is fixed now. Can you also add the exact same propHook for the src property?

Owner

@aFarkas, can you create a ticket for that?

@dmethvin dmethvin closed this in 5904468
@dmethvin
Owner

I realized there was no need to fix for backgroundPositionX/Y since they're not standard or supported across browsers (Firefox is the holdout, possibly Opera as well).

@tp9 tp9 referenced this pull request from a commit
Commit has since been removed from the repository and is no longer available.
@soulteary

It is a pity.

@mzgol
Collaborator

@markelog Can you chime in in this bug? https://bugzilla.mozilla.org/show_bug.cgi?id=968065 It's supposed to be fixed long ago.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Commits on Jul 23, 2012
  1. @elijahmanor
Commits on Jul 30, 2012
  1. @elijahmanor
Commits on Aug 8, 2012
  1. @elijahmanor
  2. @elijahmanor
Commits on Aug 13, 2012
  1. @elijahmanor
  2. @elijahmanor
Commits on Oct 19, 2012
  1. @jaubourg
  2. @cobrajs @dmethvin
  3. @dmethvin
Commits on Oct 20, 2012
  1. @dmethvin

    Combine parseJSON tests and fix style.

    dmethvin authored
    We only care about the result of parseJSON so there's no reason to feature detect the entire test.
  2. @gibson042 @dmethvin

    Fix #4262: faster .eq(), closes gh-1000.

    gibson042 authored dmethvin committed
  3. @dmethvin

    Fix #12610, remove unneeded window.event. Close gh-968.

    Sai Wong authored dmethvin committed
  4. @mikesherov
  5. @fracmak @mikesherov

    Fixes #12518, removes an offsetWidth on focus/blur events for an <IE9…

    fracmak authored mikesherov committed
    … bug that caused a performance hit. Closes gh-958
  6. @jonathansampson @dmethvin

    Fix attribute names in aliased form property test. Close gh-951.

    jonathansampson authored dmethvin committed
    Test expects input elements having name='id', name='name', and name='target'. Additionally, these should have id='id', id='name', and id='target' respectively. No element was provided with id='id' or name='id', but rather one element had two name attributes (illegal) with the values 'id' and 'name' respectively.
  7. @dmethvin

    Fix #12048. Set attributes for XML fragments. Close gh-965.

    Sai Wong authored dmethvin committed
Commits on Oct 21, 2012
  1. @rwaldron @dmethvin

    Don't expose jQuery.deletedIds. Close gh-889.

    rwaldron authored dmethvin committed
  2. @markelog @dmethvin

    Alternate fix for #11426; check responseText. Close gh-843.

    markelog authored dmethvin committed
  3. @dmethvin

    Fix #12107. Let .proxy() curry args without overwriting context. Close

    Marcel Greter authored dmethvin committed
  4. @dmethvin
  5. @markelog @dmethvin
  6. @mikesherov
Commits on Oct 22, 2012
  1. @markelog @dmethvin
  2. @dmethvin

    Missing semicolon.

    dmethvin authored
  3. @mikesherov

    updated AUTHORS

    mikesherov authored
  4. @matjae @dmethvin

    Fix #12411, .removeClass(undefined) is a chaining no-op. Close gh-913.

    matjae authored dmethvin committed
    .removeClass() //removes all classes, as documented
    .removeClass(window.nonExistentVariable) // removes nothing
  5. @mikesherov

    new JSHINT mixed spaces/tabs is smart enough to not warn on multiline…

    mikesherov authored
    … comments, rendering smarttabs useless
Commits on Oct 23, 2012
  1. @mikesherov
Commits on Oct 24, 2012
  1. @dmethvin

    Update authors.

    dmethvin authored
  2. @timmywil
  3. @rwaldron

    Brute force property removal when removeData([a,b,c]). Fixes #12786

    rwaldron authored
    Signed-off-by: Rick Waldron <waldron.rick@gmail.com>
  4. @rwaldron
Commits on Oct 25, 2012
  1. @dmethvin
  2. @dmethvin
  3. @dgalvez @dmethvin

    Fix #11542. document.body should not be special in .offset() and docu…

    dgalvez authored dmethvin committed
    …ment.documentElement is the default element.offsetParent. Close gh-899.
  4. @rwaldron

    Less deep and more strict.

    rwaldron authored
  5. @rwaldron
Commits on Oct 26, 2012
  1. @markelog @rwaldron
  2. @DFoxinator @mikesherov

    Fixes #12139, make sure absolutely positioned elements have HTML as o…

    DFoxinator authored mikesherov committed
    …ffsetParent, closes gh-1010
Commits on Oct 29, 2012
  1. @Krinkle @dmethvin

    Implement expectation test instead of using _removeData. Close gh-997.

    Krinkle authored dmethvin committed
    * Removed inline usage of QUnit.reset() because it is messing with the
      expectation model as reset does .empty() which does a recursive cleanData
      on everything in #qunit-fixture, so any expectJqData above .reset() would
      fail negatively.
    
      Instead of calling reset inline, either updated the following assertions to
      take previous assertions' state into account, or broke the test() up into
      2 tests at the point where it would call QUnit.reset.
    
    * After introducing the new memory leak discovery a whole bunch of tests were
      failing as they didn't clean up everything. However I didn't (yet) add
      QUnit.expectJqData calls all over the place because in most if not all of
      these cases it is valid data storage. For example in test "data()", there
      will be an internal data key for "parsedAttrs". This particular test isn't
      intending to test for memory leaks, so therefor I made the new discovery
      system only push failures when the test contains at least 1 call to
      QUnit.expectJqData.
    
      When not, we'll assume that whatever data is being stored is acceptable
      because the relevant elements still exist in the DOM anyway (QUnit.reset
      will remove the elements and clean up the data automatically).
    
      I did add a "Always check jQuery.data" mode in the test suite that will
      trigger it everywhere. Maybe one day we'll include a call to everywhere,
      but for now I'm keeping the status quo: Only consider data left in storage
      to be a problem if the test says so ("opt-in").
    
    * Had to move #fx-tests inside the fixture because ".remove()" test would
      otherwise remove stuff permanently and cause random other tests to fail
      as "#hide div" would yield an empty collection.
      (Why wasn't this in the fixture in the first place?)
    
      As a result moving fx-tests into the fixture a whole bunch of tests failed
      that relied on arbitrary stuff about the document-wide or fixture-wide
      state (e.g. number of divs etc.). So I had to adjust various tests to
      limit their sample data to not be so variable and unlimited...
    
    * Moved out tests for expando cleanup into a separate test.
    
    * Fixed implied global variable 'pass' in effects.js that was causing
      "TypeError: boolean is not a function" in *UNRELATED* dimensions.js that
      uses a global variable "pass = function () {};" ...
    
    * Removed spurious calls to _removeData. The new test exposed various failures
      e.g. where div[0] isn't being assigned any data anyway.
      (queue.js and attributes.js toggleClass).
    
    * Removed spurious clean up at the bottom of test() functions that are
      already covered by the teardown (calling QUnit.reset or removeClass to
      supposedly undo any changes).
    
    * Documented the parentheses-less magic line in toggleClass. It appeared that
      it would always keep the current class name if there was any (since the
      assignment started with "this.className || ...".
    
      Adding parentheses + spacing is 8 bytes (though only 1 in gzip apparently).
      Only added the comment for now, though I prefer clarity with logical
      operators, I'd rather not face the yayMinPD[1] in this test-related commit.
    
    * Updated QUnit urlConfig to the new format (raw string is deprecated).
    
    * Clean up odd htmlentities in test titles, QUnit escapes this.
      (^\s+test\(.*)(&gt\;) → $1>
      (^\s+test\(.*)(&lt\;) → $1<
    
    [1] jQuery MinJsGz Release Police Department (do the same, download less)
  2. @dmethvin

    Update authors.

    dmethvin authored
  3. @markelog @dmethvin
Commits on Oct 30, 2012
  1. @yiminghe @dmethvin
  2. @mikesherov @dmethvin
Commits on Oct 31, 2012
  1. @Krinkle @gibson042

    No ticket: fix effects test failure in IE6. Close gh-1012.

    Krinkle authored gibson042 committed
Commits on Nov 1, 2012
  1. @dmethvin

    Fix #10544. Remove deprecated .data() event namespaced triggering.

    dmethvin authored
    Data events were horribly slow, never documented, and caused strange interpretation of data items with dots in them.
  2. @dmethvin
  3. @dmethvin

    Test case for #12816

    dmethvin authored
  4. @gibson042
  5. @gibson042
  6. @Krinkle @dmethvin
  7. @dmethvin

    Fix #12827. Remove exclusive event semantics from .trigger().

    dmethvin authored
    No unit tests were removed in the undoing of this feature. :sob:
  8. @gibson042
  9. @dmethvin
  10. @dmethvin
  11. @dmethvin
Commits on Nov 2, 2012
  1. @dmethvin
  2. @markelog @dmethvin

    Follow-up for .selector property removal

    markelog authored dmethvin committed
  3. @dmethvin
  4. @gibson042
Commits on Nov 5, 2012
  1. @gibson042
  2. @gibson042
Commits on Nov 6, 2012
  1. @gibson042
Commits on Nov 8, 2012
  1. @dmethvin
  2. @gnarf
  3. @gnarf
  4. @gnarf

    Fixing units

    gnarf authored
  5. @gnarf
  6. @gnarf
  7. @gibson042
Commits on Nov 10, 2012
  1. @gibson042
Commits on Nov 13, 2012
  1. @gibson042
  2. @dmethvin

    Fix #12777. Add applet to non-cacheable fragment types.

    dmethvin authored
    I don't want to add a unit test that creates a dependency on an applet.
Commits on Nov 15, 2012
  1. @dmethvin

    Revert "Fixes #12569. Improve Feature Detect For oldIE bubbling. closes

    dmethvin authored
    gh-967"
    
    This reverts commit 063ea02.
    
    I've beaten on this for a while and can't find a suitable feature detect that catches Chrome's support for focusin.
  2. @elijahmanor

    Merge with latest master

    elijahmanor authored
Commits on Nov 16, 2012
  1. @elijahmanor

    Merge differences

    elijahmanor authored
Something went wrong with that request. Please try again.