Side navigation
#7981 closed bug (worksforme)
Opened January 15, 2011 08:19AM UTC
Closed April 01, 2011 02:20AM UTC
Last modified March 24, 2014 11:25AM UTC
Setting "selected" attribute to false should have no effect in single line <select>
| Reported by: | anonymous | Owned by: | jitter |
|---|---|---|---|
| Priority: | low | Milestone: | 1.5.1 |
| Component: | attributes | Version: | 1.5 |
| Keywords: | Cc: | ||
| Blocked by: | Blocking: |
Description
Hi. I filed this bug (if it is one) also at the WekKit Project (https://bugs.webkit.org/show_bug.cgi?id=52436) since I don't know who is responsible for this behaviour.
(I am using Ubuntu 10.04)
I got a <select> element with three <option> inside (my page ist XHTML 1.0 Transitional), looks like this:
<select> <option value="0">0</option> <option value="1">1</option> <option value="2">2</option> </select>
None of those is selected manually (i.e. has the "selected='selected'" tag) but on first loading the page, the option "0" ist shown by default. When I use jQuery to delete all "selected" tags in all <option>-element (which are not there), suddenly no option is selected anymore. You can check it yourself with following (w3c validated) little code:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="de" lang="de">
<head>
<title>test</title>
<meta http-equiv="Content-Type" content="text/html;charset=utf-8"/>
<script type="text/javascript" src="https://ajax.googleapis.com/ajax/libs/jquery/1.4.4/jquery.min.js"></script>
</head>
<body>
<select id="s" size="1">
<option value="0">0</option>
<option value="1">1</option>
<option value="2">2</option>
</select>
<input id="i" type="button" value="Remove 'selected'"/>
<script type="text/javascript">
$(document).ready(function() {
$("#i").click(function() {
$("#s").find("option").removeAttr("selected");
});
});
</script>
</body>
</html>
This disappearing of a selected value happens in Google Chrome 8.0.552.237, Chromium 10.0.639.0 (71411) as well as Safari 5.0.3 (7533.19.4). You see, pretty new browsers. According to webkit.org the webkit version of Chromium is 534.16 but the newest webkit version is r75294. So I can't really tell if I got the newest one, it's a confusing name scheme.
This behaviour, however, does not appear in Firefox 3.6.13, Opera 11.00 or Internet Explorer 8.
I think that the way Firefox, Opera and IE handle this is the correct way. Could you please check if this is a bug in WebKit?
Best regards,
Christian
Attachments (0)
Change History (9)
Changed January 15, 2011 01:31PM UTC by comment:1
| _comment0: | Thanks for taking the time to contribute to the jQuery project by writing a bug report. \ \ I looked into this and (as Alexey Proskuryakov on the webkit bug tracker already pointed out) this isn't an issue with `removeAttr()` directly but with WebKit acting strange when you set the `selected` property of a DOM option element to `false` (or `""`). \ \ ----- \ \ '''Why does jQuery do `jQuery.attr( this, name, "" );` in `removeAttr()`?''' \ \ jQuery does this to fix a bug in some IE versions which don't handle calls to `removeAttribute( name )` correctly. For more insight into this check the ticket #464 (corresponding [https://github.com/jquery/jquery/commit/94e59e287a9fde9425cd96713e8130aef06bc431 commit]). This was already done in December 2006 and has been in jQuery since version 1.0.4. \ \ Also this [http://jsfiddle.net/jitter/jzkT6/show test case] (with jQuery 1.0.3 which didn't yet include this fix) shows (e.g. in IE 6) that `.removeAttr()` needs this fix in IE. You can also check out the still active test case link in the original ticket. \ \ ----- \ \ '''Is this really a jQuery issue?''' \ \ I don't think so. This can also be triggered in WebKit without the use of jQuery by plain javascript. The code also isn't artificial but a legitimate use case. \ \ [http://jsfiddle.net/jitter/bDmSP/3/show/ test case with a single option]\\\\ \ [http://jsfiddle.net/jitter/bDmSP/show/ test case with two options] (2nd has selected set) \ \ Both test cases show the same behavior in WebKit. On opening the page the correct option element is shown preselected. After clicking the button no option is shown as selected and the `selectedIndex` property of the parent `select` return -1. \ \ ----- \ \ '''Is WebKit doing the wrong thing?''' \ \ That is a though call. If you look at the specifications of `select/option` in HTML 4.01 and DOM Level 2 this behavior could be seen as "not incorrect" (but neither are the other browsers incorrect). Check the following\\\\ \ [http://www.w3.org/TR/DOM-Level-2-HTML/html.html#ID-85676760 DOM Level 2 - selectedIndex]\\\\ \ [http://www.w3.org/TR/html401/interact/forms.html#h-17.6.1 HTML 4.01 - Pre-selected options] \ \ You could argue that having no option shown selected and `selectedIndex` set to -1 is a correct way of reacting to all option DOM elements having set their `selected` property to false explicitly. \ \ ----- \ \ If we look at the newer specifications [http://dev.w3.org/html5/spec/the-button-element.html#dom-select-selectedindex HTML5 select DOM Interface - selectedIndex] and the following text from [http://dev.w3.org/html5/spec/the-button-element.html#the-select-element HTML5 - 4.10.9 The select element] \ > If [...] the element's display size is 1, then whenever there are no option elements in the select element's list of options that have their selectedness set to true, the user agent must set the selectedness of the first option element in the list of options in tree order that is not disabled, if any, to true. \ \ I would argue that how Opera/FF,IE behave is the correct way to go. Of course I might have missed some very important points in the specifications as this was just a quick check. Feel free to correct me. \ \ ----- \ \ '''Is this going to be fixed in jQuery''' \ \ Maybe. I might take some time to investigate which browsers really need this `.attr( this, name, "" )` workaround and build in a check to run this only for the browsers which need it. Because skipping this step would bring performance improvements if you call `.removeAttr()` on many elements. So the fix would be "coincidental" and the underlying "issue" with WebKit would remain. (e.g. `$("option").attr("selected", "");`). \ \ So until we decide if the perf improvement to `removeAttr()` is worth it I leave this ticket open. → 1295098440383198 |
|---|---|
| component: | unfiled → manipulation |
| description: | Hi. I filed this bug (if it is one) also at the WekKit Project ([https://bugs.webkit.org/show_bug.cgi?id=52436]) since I don't know who is responsible for this behaviour. \ \ (I am using Ubuntu 10.04) \ I got a <select> element with three <option> inside (my page ist XHTML 1.0 Transitional), looks like this: \ \ <select> \ <option value="0">0</option> \ <option value="1">1</option> \ <option value="2">2</option> \ </select> \ \ None of those is selected manually (i.e. has the "selected='selected'" tag) but on first loading the page, the option "0" ist shown by default. When I use jQuery to delete all "selected" tags in all <option>-element (which are not there), suddenly no option is selected anymore. You can check it yourself with following (w3c validated) little code: \ \ <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> \ <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="de" lang="de"> \ <head> \ <title>test</title> \ <meta http-equiv="Content-Type" content="text/html;charset=utf-8"/> \ <script type="text/javascript" src="https://ajax.googleapis.com/ajax/libs/jquery/1.4.4/jquery.min.js"></script> \ </head> \ <body> \ <select id="s" size="1"> \ <option value="0">0</option> \ <option value="1">1</option> \ <option value="2">2</option> \ </select> \ <input id="i" type="button" value="Remove 'selected'"/> \ <script type="text/javascript"> \ $(document).ready(function() { \ $("#i").click(function() { \ $("#s").find("option").removeAttr("selected"); \ }); \ }); \ </script> \ </body> \ </html> \ \ This disappearing of a selected value happens in Google Chrome 8.0.552.237, Chromium 10.0.639.0 (71411) as well as Safari 5.0.3 (7533.19.4). You see, pretty new browsers. According to webkit.org the webkit version of Chromium is 534.16 but the newest webkit version is r75294. So I can't really tell if I got the newest one, it's a confusing name scheme. \ This behaviour, however, does not appear in Firefox 3.6.13, Opera 11.00 or Internet Explorer 8. \ \ I think that the way Firefox, Opera and IE handle this is the correct way. Could you please check if this is a bug in WebKit? \ \ Best regards, \ Christian → Hi. I filed this bug (if it is one) also at the WekKit Project ([https://bugs.webkit.org/show_bug.cgi?id=52436]) since I don't know who is responsible for this behaviour. \ \ (I am using Ubuntu 10.04) \ I got a <select> element with three <option> inside (my page ist XHTML 1.0 Transitional), looks like this: \ {{{ \ <select> \ <option value="0">0</option> \ <option value="1">1</option> \ <option value="2">2</option> \ </select> \ }}} \ None of those is selected manually (i.e. has the "selected='selected'" tag) but on first loading the page, the option "0" ist shown by default. When I use jQuery to delete all "selected" tags in all <option>-element (which are not there), suddenly no option is selected anymore. You can check it yourself with following (w3c validated) little code: \ {{{ \ <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> \ <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="de" lang="de"> \ <head> \ <title>test</title> \ <meta http-equiv="Content-Type" content="text/html;charset=utf-8"/> \ <script type="text/javascript" src="https://ajax.googleapis.com/ajax/libs/jquery/1.4.4/jquery.min.js"></script> \ </head> \ <body> \ <select id="s" size="1"> \ <option value="0">0</option> \ <option value="1">1</option> \ <option value="2">2</option> \ </select> \ <input id="i" type="button" value="Remove 'selected'"/> \ <script type="text/javascript"> \ $(document).ready(function() { \ $("#i").click(function() { \ $("#s").find("option").removeAttr("selected"); \ }); \ }); \ </script> \ </body> \ </html> \ }}} \ This disappearing of a selected value happens in Google Chrome 8.0.552.237, Chromium 10.0.639.0 (71411) as well as Safari 5.0.3 (7533.19.4). You see, pretty new browsers. According to webkit.org the webkit version of Chromium is 534.16 but the newest webkit version is r75294. So I can't really tell if I got the newest one, it's a confusing name scheme. \ This behaviour, however, does not appear in Firefox 3.6.13, Opera 11.00 or Internet Explorer 8. \ \ I think that the way Firefox, Opera and IE handle this is the correct way. Could you please check if this is a bug in WebKit? \ \ Best regards, \ Christian |
| priority: | undecided → low |
Changed January 16, 2011 05:58PM UTC by comment:2
| keywords: | → needsreview |
|---|
Changed February 02, 2011 12:04AM UTC by comment:3
| milestone: | 1.next → 1.5.1 |
|---|---|
| owner: | → jitter |
| status: | new → assigned |
| version: | 1.4.4 → 1.5 |
Changed February 03, 2011 10:29AM UTC by comment:4
| component: | manipulation → attributes |
|---|
Changed February 07, 2011 09:20AM UTC by comment:5
The underlying issue/bug in webkit was fixed in the newest release. So take your time. :)
Changed March 29, 2011 12:23PM UTC by comment:6
in jquery min you just need change line to:
a.setAttribute(c,e)
from a[c]=e
in not minified version:
elem[ name ] = value;
change with:
elem.setAttribute( name, value );
Changed March 29, 2011 07:26PM UTC by comment:7
It seems that webkit has fixed the issue for us: http://jsfiddle.net/timmywil/pRmQN/
Changed April 01, 2011 02:20AM UTC by comment:8
| keywords: | needsreview |
|---|---|
| resolution: | → worksforme |
| status: | assigned → closed |
Changed March 24, 2014 11:25AM UTC by comment:9
you can set it by $("#select_id").prop("selectedIndex", 3); Select index starts from zero.
read here for example.
http:kvcodes.com/2014/03/set-html-select-options-selected-value-using-jquery/
Thanks for taking the time to contribute to the jQuery project by writing a bug report.
I looked into this and (as Alexey Proskuryakov on the webkit bug tracker already pointed out) this isn't an issue with
removeAttr()directly but with WebKit acting ~~strange~~ differntly when you set theselectedproperty of a DOM option element tofalse(or"").Why does jQuery do
jQuery.attr( this, name, "" );inremoveAttr()?jQuery does this to fix a bug in some IE versions which don't handle calls to
removeAttribute( name )correctly. For more insight into this check the ticket #464 (corresponding commit). This was already done in December 2006 and has been in jQuery since version 1.0.4.Also this test case (with jQuery 1.0.3 which didn't yet include this fix) shows (e.g. in IE 6) that
.removeAttr()needs this fix in IE. You can also check out the still active test case link in the original ticket.Is this really a jQuery issue?
I don't think so. This can also be triggered in WebKit without the use of jQuery by plain javascript. The code also isn't artificial but a legitimate use case.
test case with a single option\\\\
test case with two options (2nd has selected set)
Both test cases show the same behavior in WebKit. On opening the page the correct option element is shown preselected. After clicking the button no option is shown as selected and the
selectedIndexproperty of the parentselectreturn -1.Is WebKit doing the wrong thing?
That is a though call. If you look at the specifications of
select/optionin HTML 4.01 and DOM Level 2 this behavior could be seen as "not incorrect" (but neither are the other browsers incorrect). Check the following\\\\DOM Level 2 - selectedIndex\\\\
HTML 4.01 - Pre-selected options
You could argue that having no option shown selected and
selectedIndexset to -1 is a correct way of reacting to all option DOM elements having set theirselectedproperty to false explicitly.If we look at the newer specifications HTML5 select DOM Interface - selectedIndex and the following text from HTML5 - 4.10.9 The select element
I would argue that how Opera/FF,IE behave is the correct way to go. Of course I might have missed some very important points in the specifications as this was just a quick check. Feel free to correct me.
Is this going to be fixed in jQuery
Maybe. I might take some time to investigate which browsers really need this
.attr( this, name, "" )workaround and build in a check to run this only for the browsers which need it. Because skipping this step would bring performance improvements if you call.removeAttr()on many elements. So the fix would be "coincidental" and the underlying "issue" with WebKit would remain. (e.g.$("option").attr("selected", "");).So until we decide if the perf improvement to
removeAttr()is worth it I leave this ticket open.