I'm experiencing quite an odd issue with <select> menus. When I go back to a page containing a <select> after I have clicked out of it (or minimized it) the <select> sometimes collapses and becomes unresponsive. I have checked all of my code, and it is 100% valid, further I have seen this happen on other sites as well.
I have experienced <select> menus collapsing in the latest version of Safari (available for OSX 10.6.8) as well as the latest versions of Chrome and Firefox (tested both on Windows Vista and OSX 10.6.8). Oddly enough I have not been able to reproduce the <select> collapse in Chrome running on Windows 8... One last tidbit: it seems that the length of the <select> element affects the probability of the menu collapsing (that is to say, the more <option> elements in a <select>, the more likely it is to collapse. Sometimes a <select> menu will collapse after being selected and clicked out of once, sometimes it can take 5 or 6 attempts.
My question is: What causes this <select> collapse issue, and is there a known work around? Please see the example code below, it's very simple, but the <select> menu has nonetheless collapsed in the browsers/operating systems I mentioned earlier. Thanks in advance!
<!doctype html>
<html>
<head>
<title>Select Test</title>
</head>
<body>
<select name ="Test">
<option value = "0">0</option>
<option value = "1">1</option>
<option value = "2">2</option>
<option value = "3">3</option>
<option value = "4">4</option>
<option value = "5">5</option>
<option value = "6">6</option>
<option value = "7">7</option>
<option value = "8">8</option>
<option value = "9">9</option>
<option value = "10">10</option>
<option value = "11">11</option>
<option value = "12">12</option>
<option value = "13">13</option>
<option value = "14">14</option>
<option value = "15">15</option>
<option value = "16">16</option>
<option value = "17">17</option>
<option value = "18">18</option>
<option value = "19">19</option>
<option value = "20">20</option>
<option value = "21">21</option>
<option value = "22">22</option>
<option value = "23">23</option>
<option value = "24">24</option>
<option value = "25">25</option>
<option value = "26">26</option>
<option value = "27">27</option>
<option value = "28">28</option>
<option value = "29">29</option>
<option value = "30">30</option>
<option value = "31">31</option>
<option value = "32">32</option>
<option value = "33">33</option>
<option value = "34">34</option>
<option value = "35">35</option>
<option value = "36">36</option>
<option value = "37">37</option>
<option value = "38">38</option>
<option value = "39">39</option>
<option value = "40">40</option>
<option value = "41">41</option>
<option value = "42">42</option>
<option value = "43">43</option>
<option value = "44">44</option>
<option value = "45">45</option>
<option value = "46">46</option>
<option value = "47">47</option>
<option value = "48">48</option>
<option value = "49">49</option>
<option value = "50">50</option>
<option value = "51">51</option>
<option value = "52">52</option>
<option value = "53">53</option>
<option value = "54">54</option>
<option value = "55">55</option>
<option value = "56">56</option>
<option value = "57">57</option>
<option value = "58">58</option>
<option value = "59">59</option>
<option value = "60">60</option>
<option value = "61">61</option>
<option value = "62">62</option>
<option value = "63">63</option>
<option value = "64">64</option>
<option value = "65">65</option>
<option value = "66">66</option>
<option value = "67">67</option>
<option value = "68">68</option>
<option value = "69">69</option>
<option value = "70">70</option>
<option value = "71">71</option>
<option value = "72">72</option>
<option value = "73">73</option>
<option value = "74">74</option>
<option value = "75">75</option>
</select>
</body>
</html>
Update:
Here is a screenshot of a collapsed/unresponsive <select> menu in Safari 5.1.9 running on OSX 10.6.8 (this is a different mac than the one I was using earlier). It became unresponsive after 3 attempts (selecting an option, then clicking out of the browser). It does not reveal the option list when clicked, and is completely unresponsive until the page is reloaded. I'll be downloading chrome on the mac shortly.
Update 2:
According to #webdad3, this issue is also present in IE9
Update 3:
Here is a link to the source code I posted above, but in JSbin. Courtesy of #starbeamrainbowlabs.
http://jsbin.com/eXOMeRI/1/edit
Update 4:
According to #Zarazthuztra, this issue is also present in OSX 10.8.
Update 5:
I'm taking #cloudcoder2000's advice and posting this link in the question itself. I believe it shows that a <select> should not collapse (like many of us are experiencing) regardless of the number of <option>s it contains.
Is there a max number of options (values) in HTML drop down control?
I would like to also thank everyone for their help thus far.
Update 6:
I fear this question is beginning to stagnate... If anyone has any theories as to what is causing this issue (regardless of how "off-the-wall" it may seem) let me know and I'll test it asap.
Update 7:
Just confirm: I've experienced this collapse issue on several pages that do not use Javascript. Further, the example code I posted above (which does not contain any Javascript) has collapsed for me and a few other stackoverflow users (across different operating systems and browsers).
Update 8:
#Capile was able to reproduce the collapse issue in Safari 7.0.1 running on Mac OS X 10.9.1.
Update 9:
By using #Capile's code, I was able to get the <select> to "uncollapse" in Safari 5.1.10 (running on OSX 10.6.8). Please read his answer for the full details. I will be testing his code in Chrome and Firefox later today, or tomorrow. This is really promising, I think we're getting close to solving this. I would just like to thank everyone again for their help thus far, you guys are great!
Update 10:
I finally got a chance to test #Capile's code in Chrome on one of my Snow Leopard (10.6.9) machines. I had quite a bit of trouble getting the <select> to collapse this time, but after a few minutes of trying, it finally did. After pasting his code into the console the <select> "uncollapsed" (to put it as inelegantly as possible). This is quite curious, because if this "collapse" issue is related to system-level garbage collection, then one would think that the a <select> would "collapse" fairly consistently across browsers, but this isn't the case. I've tested a myriad of browsers (across multiple operating systems) and <select> "collapse" seems exceedingly common in certain browsers (such as Safari)... I'm admittedly not an expert programmer so I may be wrong, but in any case, I just wanted to update this question so that greater minds could mull over the new information.
Update 11:
I just added a bounty to this question in an attempt to generate more interest (I hope it helps). Anyway, I was able to get the <select> to collapse in the latest version Firefox (running on OSX 10.6.9) last night. I unfortunately did not get a chance to test #Capile's code in Firefox, but I will try to do so today.
Since the <select> element UI is handled by the OS in several browsers (which makes their complete styling much more complicated, or impossible), I would guess that's it is a bug on OS level, or a bug at the browser that relates to some OS UI functionality — definitely not a problem of the source HTML, which is plain simple and according to specs).
For the browser, the <select> element is completely normal: you can see it at DOM, even manipulate it (it also listens to events as well). If you detach and reattach it to the DOM, it works normally again (open up and enable selecting). If you just run the code below at the console window, you'll get it working again:
var s=document.getElementsByTagName('select'),
i=s.length,
a=document.createElement('div'),
b;
while(i-->0) {
s[i].parentNode.insertBefore(a, s[i]);
b=s[i].parentNode.removeChild(s[i]);
a.parentNode.insertBefore(b,a);
a.parentNode.removeChild(a);
b=null;
}
My guess is that when the browser is blurred, the UI elements might get caught by some sort of OS garbage collector, and when you get back at the browser, it just expects the OS to display it again (but it can't find it). But it's just a guess — I'd need to profile Safari memory in order to really get to it.
I could replicate it on Safari 7.0.1 running on Mac OS X 10.9.1, but couldn't replicate it on Firefox 28.0a2 (Aurora) or Chrome 34 (Canary).
You have an issue not related to <select>.
Some if not most DHTML web-application logic not work well with "back" and "forward" buttons, these are almost are history.
The source code you provided is OK.
Update the browser or change it for another that is capable of the task.
in your browser has any problem with plain select about 75 items - contact your browser provider.
The limitation for an amount of elements in select does exist as for everything. We are limited by amount of memory per app - depends on platform and amount of memory left.
The browser has some internal collections of elements and these collections are limited to some quantities. The same goes for every application. Though these limits are far from barely hundred of items, the select may contain a lot more but it's an another pain to render them.
In some intranet applications ppl use thousands of options per select and multiple selection of 75.
Check your JS instead, it's possible you have a script working on the select element that is causes it to misbehave.
UPD: might be a problem with
<!doctype html>
it's ver 5 non-standard so far. 03.2014
(for more info take a look at http://www.w3.org/html/wg/drafts/html/master/)
try
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">
to prevent a browser from trying to parse HTML ver 5.
As mentioned in the comments, this seems like lag. Whether it is caused by the specs of your computer, the browser, plugins/extensions, or something else on the page, you can't put 75 options in a select and expect Safari and IE to keep up. I'm not sure if lag could cause a page to freeze and force the user to reload it, but I honestly don't know what else could have caused it.
I'm not really sure where you would need a select with 75 options, but if you do really need it, I'd recommend a simple text input where you limit what the user can input to 1-75. Yes, it's not exactly as simple and elegant as a dropdown select, but it will get the job done, and you shouldn't have to worry about glitches.
Aaaahhhh, this is a longshot, but...
Try removing the spaces in your HTML attributes (not inside quotes), so value = "0" becomes value="0".
I've seen similar behaviour with the select element but it was usually not the cause of the problem. If the basic browser components are lagging then it's usually because there is a long running script in the background that is consuming all of the browser resources. Is the page you pasted above the entire page or is there also significant javascript being run on the page?
Find the browser which works for you while waiting for an update/patch. Whenever I encounter a browser issue I usually switch between Firefox, Google Chrome, and IE.
As for your code, I suggest looking into JavaScript, which should make your life easier by turning all those hard-coded <option> into something dynamic. Something like:
// Starting from index 0,
// create an <option> with the value of the current index
// keep creating <option> until you hit index 75.
here your problem solution use javascript for print values in select tags like:
for(i=1969;i<=2014;i++)
{
document.write(''+i+''); }
Related
I have a drop down list of countries, where each entry consists of the country flag and then the country name. This is an excerpt of my drop down:
<select>
<optgroup label="Asia">
<option label="🇦🇫 Afghanistan" value="string:Afghanistan">🇦🇫 Afghanistan</option>
<option label="🇦🇲 Armenia" value="string:Armenia">🇦🇲 Armenia</option>
<option label="🇦🇿 Azerbaijan" value="string:Azerbaijan">🇦🇿 Azerbaijan</option>
</optgroup>
<optgroup label="Europe">
<option label="🇦🇽 Åland" value="string:Åland">🇦🇽 Åland</option>
<option label="🇦🇱 Albania" value="string:Albania">🇦🇱 Albania</option>
<option label="🇦🇩 Andorra" value="string:Andorra">🇦🇩 Andorra</option>
</optgroup>
</select>
When I try to find an entry in the drop down by typing, nothing happens. When I get rid of the flags it does work, but I'm still not able to select a country like Åland, thanks to the Å.
Is there some way to tell the browser to ignore the flags when searching? Or would it have to be a custom solution?
This whole select is generated by angular using ng-options. Just in case it is needed, this is the array expression in use:
ng-options = "selectionValue.name as vm.getCountryDisplayName(selectionValue) group by vm.mmTranslate.tr(vm.getCountryElementGroup(selectionValue)) for selectionValue in vm.countries"
The list of countries in vm.countries does NOT have the flags, they're added here in the expression via the vm.getCountryDisplayName function. vm.getCountryElementGroup retrieves the continent of the country.
I couldn't really try anything else because searching for this specific issue yielded only minimal search results, none of which were helpful. I tried modifying the label and value options, but it seems like the Browser is always using the label attribute to do the search.
<select [(ngModel)]="scheduleComment" class="form-control"
(change)="getSchedCommentsList($event)"
#sched="ngModel">
<option [ngValue]="null">Choose Schedule Comments</option>
<option *ngFor="let scheduleComment of scheduleComments"
[ngValue]="scheduleComment">{{scheduleComment}}</option>
</select>
I've tried using the [(ngModel)] capability to update a field with a new value assigned within a component (separate from the assignment made within the select '*ngFor="let scheduleComment of scheduleComments'" option).
However, the select box value seems impervious to any updates outside the of the initial selection. I've seen other examples using ngChangeForm as well but that doesn't seem to be applicable to this situation, unfortunately.
Can anyone provide an example of how this might be done? That is updating a value independently from the initial value selected.
Thanks
Im beating my head against the wall - someone please help.
Using IE webbrowser i simply used the following.
collection as htmlcollection = htmldoc.getelementbytagname("select")
for each ele in collection
dim options = ele.children
'some if thens to match the option to the option i need selected
ele.setattribute("value",optionselectedbyuser)
All this worked great, it set the value and selected it in the webpage dropdownbox. Now that the website requires Firefox i have to redo my coding and the drop down boxes are killing me this is what i have tried
dim collection as gecko.geckoelementcollection =htmldoc.getelementbytagname("select")
for each ele as gecko.element in collection
'some if thens to make sure im in the correct dropdown control
for each child in ele.childnodes
'using this to obtain the options of the dropdownbox and make sure it matches what user has selected, if it does i assign the element that value
if child.textcontent.tostring.toupper = inputfromusertoselect.toupper then
ele.setattribute("value",child.nodevalue("value"))
end if
next
next
After assigning the value, i reread the outerhtml code and the value i set is now in the html but on the webpage the actual item isnt selected. I also notice in the outerhtml there is an option tag with its own value. Im wondering if this is where i need to set the value but i cant seem how to assign the value of the options. see outer html
<select selected="selected" value="Detached" id="GarageType" name="GarageType" class="required"><option value="">-- Select Garage Type --</option>
<option id="GarageTypeNone" value="None">None</option>
<option id="GarageTypeAttached" value="Attached">Attached</option>
<option id="GarageTypeDetached" value="Detached">Detached</option>
<option id="GarageTypeCarport" value="Carport">Carport</option>
<option id="GarageTypeBuiltIn" value="Built In">Built In</option></select>
as you can see in html code, i have already set the value to "Detached" and by trouble shooting i set the selected =selected. but to no avail it still doenst change value on page. What am i doing wrong with geckofx!!!HELLLP
Tested in Visual Studio 2013 - VB.NET:
Dim el1 As Gecko.DOM.GeckoSelectElement = _
GeckoWebBrowser1.Document.GetElementsByName("GarageType")(0)
el1.Options.item(<NUMBER>).Selected = True
Sorry, code only answer since I do not speak English.
I am in the process of converting an old client/server app to a web browser-based application, and have an issue with the standard HTML SELECT element. Users of this app enter search term/operator pairs to construct a search on a large database (see sample markup below).
<input type="text" id="txtTerm1" />
<select id="selOp1">
<option value=""></option>
<option value="or">Or</option>
<option value="near">Near (any)</option>
<option value="near2">Near (within 2 words)</option>
<option value="near4">Near (within 4 words)</option>
<option value="before">Before (any distance)</option>
<option value="before2">Before (within 2 words)</option>
<option value="before4">Before (within 4 words)</option>
</select>
A search term is entered into txtTerm1, and then TAB or ENTER is pressed to move to selOp1. The users like to use the keyboard exclusively to choose an operator from selOp1. When they quickly press "n", the select control iterates through the "near" options perfectly. But if the user then decides they want to switch to "Or" and types "o," the control does not select the "Or" option.
Test: Type n,n,n,n,n,o in rapid succession
It seems that if you type quickly and then change characters, the SELECT element groups the two characters together, "no" in this case, and does not find an OPTION with that text. If I wait a few seconds after typing the n's and then press o, it works. But this slows the users down and is confusing. This behavior seems to be the same in Chrome, Firefox and IE.
The question:
Is there a way to force a SELECT to only use the first character of the OPTION text when trying to locate an OPTION with the keyboard? Or does anyone have any other clever solutions? Any advice is greatly appreciated.
I have a <select> tag with various options, and I would like to know what determines what happens when the user starts typing.
Say I have a list like the following:
<select id="userlist">
<option value="nothing" selected="selected"></option>
<option value="AdamT">Adam T</option>
<option value="AidanC">Aidan C</option>
<option value="IanQ">Ian Q</option>
<option value="JamesR">James R</option>
</select>
Sometimes if I type A followed by I, I end up with Aidan C selected.
Other times, if I type just fractionally slower, I end up with Ian Q selected.
What determines what ends up being selected, and at what speed of typing? Is it browser-specific, or is it set in the HTML spec?
That is browser or OS specific, depending if the browser uses native or custom widgets, I think.
There is certainly nothing in the HTML spec about it.
The < select > is setup so that it performs a new autocomplete in about 1000 milisecond intervals between key presses. If you keep typing before the timer is up, it will continue the autocomplete with your current prefix. However, if you wait a second between key presses, it will start a new prefix, forgetting what you previously typed.