#12002 closed bug (cantfix)
$('<select class="question" />'); vs $('<select />', {'class': 'question'}); produces different results in IE
Reported by: | Brandon Boone | Owned by: | saiwong |
---|---|---|---|
Priority: | low | Milestone: | None |
Component: | attributes | Version: | 1.7.2 |
Keywords: | ie6 ie7 ie8 ie9 | Cc: | |
Blocked by: | Blocking: |
Description
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:
- In the first drop down choose 3
- In the second drop down choose 1
- In the first drop down choose 1 (should not be an available option)
- Notice that the selected value is 2!
- Notice that changing your selected value in the second drop down also produces different values than those presented.
- 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
Change History (18)
comment:1 follow-up: 2 Changed 11 years ago by
Owner: | set to Brandon Boone |
---|---|
Status: | new → pending |
comment:2 Changed 11 years ago by
Status: | pending → new |
---|
Replying to 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.
comment:4 Changed 11 years ago by
Component: | unfiled → attributes |
---|---|
Keywords: | ie6 ie7 ie8 ie9 added |
Priority: | undecided → low |
Status: | new → open |
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.
comment:5 Changed 10 years ago by
Resolution: | → invalid |
---|---|
Status: | open → closed |
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>')
comment:6 Changed 10 years ago by
Resolution: | invalid |
---|---|
Status: | closed → reopened |
comment:7 Changed 10 years ago by
Resolution: | → invalid |
---|---|
Status: | reopened → closed |
@gibson042, yup, he's sure :)
comment:8 Changed 10 years ago by
Resolution: | invalid |
---|---|
Status: | closed → reopened |
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.
comment:9 Changed 10 years ago by
@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.
comment:10 Changed 10 years ago by
Status: | reopened → open |
---|
That's what I get for triaging right before bed :-/
comment:11 Changed 10 years ago by
Keywords: | 1.9-discuss added |
---|
comment:13 Changed 10 years ago by
Not sure this is vote roll material... Seems like a bug we need to just fix
comment:14 Changed 10 years ago by
Keywords: | 1.9-discuss removed |
---|---|
Milestone: | None → 1.9 |
comment:15 Changed 10 years ago by
Owner: | changed from Brandon Boone to saiwong |
---|---|
Status: | open → assigned |
comment:16 Changed 10 years ago by
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 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:
- In the first drop down choose 3
- In the second drop down choose 1
- In the first drop down choose 1 (should not be an available option)
- Notice that the selected value is 2!
- Notice that changing your selected value in the second drop down also produces different values than those presented.
- 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
comment:17 Changed 10 years ago by
Resolution: | → cantfix |
---|---|
Status: | assigned → closed |
comment:18 Changed 10 years ago by
Milestone: | 1.9 → None |
---|
Can you reduce this to something that doesn't require a human to make selections in a form?