Mysterious failure in IE6 the first time i ran the suite:

1. attributes: val(Function) with incoming value...
   test #5991, #6282, jQuery.type #10 "Should be possible to set the val() to a newly created option"

Passing on second run and all subsequent runs.

that's really weird. the change is entirely contained inside the val(select) logic. i have no explanation for that.

Nor do I - Like I said it only happened the first time I ran it. I don't think its an issue.

I wanted to land this today but the test case doesn't seem to reproduce the bug. Running the test suite without the fix in attribute.js doesn't yield failures for me in IE6. But I can reproduce the bug on standalone pages (like the one linked to in the ticket).

I guess there is some timing issue. Or maybe the "bug" doesn't show until control is returned to browser, which would make it difficult to test.

I just tried this test (which executes the test non-interactively and programatically at DOM-ready):

http://test.getify.com/test-ie-form-reset-select-jquery.html

In IE9 RC1 and in IE6 SP3, the alert which pops up at page-load indicates that the .val() command failed to return a valid string (in fact, it seems to just return an empty array).

Can you confirm if you get the same behavior with that test?

Is it possible that my jquery test is invalid because somehow the .val() return value (an empty array-like object) somehow is seen by the test-suite .equals() as falsely equal to "3" somehow? I'm not sure how .equals() works, but maybe it's not the safe/appropriate test function to use when one of the values passed in is this special empty collection/array object?

I have no other explanation as to why you can't reproduce the failure with the test suite but can with my standalone page as I just linked above.

In other words, maybe we need a test that requires the type check as well as value (which could somehow be being coerced)?

Looking at the QUnit API, perhaps the test should be using .strictEqual()? Can you try that and see if the test fails as expected?

http://gyazo.com/a8d906276e09d9e3d3df9f02f83343b9.png

http://pastebin.com/zyeyUen9

I pulled in your branch and re-wrote the test so that it actually reproduced the ticket.

I made this test page http://jsfiddle.net/jitter/7Zen3/10/ (which includes your http://test.getify.com/jquery-bug2551.js) but this doesn't seem to fix the problem.

@jitter

http://test.getify.com/jquery-bug2551.js

has my fix in it. i'm not sure if that's the copy of jQuery you want to use if you're trying to get the test to fail. I was just using the public CDN URL for jquery 1.4.4.

@rwldrn--

So, you're manually creating a form and setting the select.... and it fails as expected. So I guess the question is, why can't using the test-suite's provided markup (index.html) reproduce the failure. That seems quite strange to me.

@getify
exactly that's my point. I used your patched version but it doesn't fix the bug. Select something in dropdown. Hit reset. Hit get value. Alert is empty --> fix doesn't work

@jitter -- your jsfiddle works fine for me. i'm confused.

what IE environment are you using? a native IE or in some VM? what version?

@getify -- that's not your fault, the test suite is a weirdo sometimes. I find it best to create and remove elements as necessary - for weird edge cases like this. Generally its recommended to use the existing elements.

Too be honest, I think that the real difference lies in how we are resetting the forms.

We found another solution which also should be more robust. Landed here 43a41ba
Thanks for the help