Can you reduce this to something that doesn't require a human to make selections in a form?

Replying to [comment:1 rwaldron]:

Can you reduce this to something that doesn't require a human to make selections in a form?

Unfortunately, programmatically altering the selection corrects the behavior

Example:

$S1.focus().children('option:eq(1)').click().prop('selected', true).end().change(); 
$S2.focus().children('option:eq(0)').click().prop('selected', true).end().change();

Changing the selections through human interaction shows that the error still persists.

Here is a fiddle to compliment the previous code snippet.

http://jsfiddle.net/s6F4h/22/

This looks like inconsistent behavior throughout IE, from 6 to 9. The good news is that this seems to be fixed in IE10.

The page seems totally broken in IE6/7 once you make the first selection, the second box no longer even responds to clicks.

Don't know why I didn't notice this earlier. The markup is invalid. You can't use XHTML-style tags on elements that take content, save for the ONE EXCEPTION that jQuery allows for attribute-less tags as a shortcut. We can't save you from the other cases, you have to actually do them right. This is clearly documented. http://api.jquery.com/jQuery/#jQuery2

Wrong: $('<select class="abc" />')

Right: $('<select class="abc"></select>')

@dmethvin Are you sure? https://github.com/jquery/jquery/blob/c01e022f33575ed45fb8da65be756fc464d40a24/src/manipulation.js#L669-L670

@gibson042, yup, he's sure :)

https://github.com/jquery/jquery/blob/c01e022f33575ed45fb8da65be756fc464d40a24/src/manipulation.js#L19

Haha, nope gibson042 is right. I keep forgetting we fixed that for single tags. And I must have checked for that when I did the initial triage.

@mikesherov "select" is not in the no-content list there. Check execution on the fiddles; <select class="question" /> is converted to <select class="question" ></select> by https://github.com/jquery/jquery/blob/c01e022f33575ed45fb8da65be756fc464d40a24/src/manipulation.js#L670. I don't have access to the IEs right now, but if there's something going on here it's definitely *not* from self-closing markup.

That's what I get for triaging right before bed :-/

+1

Not sure this is vote roll material... Seems like a bug we need to just fix

Looks like issue is related to a browser bug IE where the DOM is correct but the view requires a repaint to reflect the changes. This can be done via a simple hide().show() as show here:

http://jsfiddle.net/saiwong/s6F4h/48/

This seems to only affect elements when the class is specified in the HTML text.

Marking as can't fix.

Replying to [ticket:12002 Brandon Boone]:

In response to the feedback I got on this Stack Overflow question: http://stackoverflow.com/questions/11298885/select-options-text-is-different-once-selected There may be an issue in how jQuery handles IE's quirkiness in regard to HTML object creation concerning "<select>" elements. Using the following links: * Broken: http://jsfiddle.net/s6F4h/16/ * Fixed: http://jsfiddle.net/s6F4h/17/ Follow these instructions: 1. In the first drop down choose 3 2. In the second drop down choose 1 3. In the first drop down choose 1 (should not be an available option) 4. Notice that the selected value is 2! 5. Notice that changing your selected value in the second drop down also produces different values than those presented. 6. Lastly, notice that the DOM is displaying the correct values Only thing different in these examples are the way the "select" elements are created.

> //Broken
> var $S1 = $('<select class="question" />'); 
> 
> //vs
> 
> //Fixed
> var $S1 = $('<select />', {'class': 'question'}); 
> 
> 

Broken in: * IE 9 v9.0.8112.16421 * IE 8 v8.0.7600.16385