Version: (using KDE KDE 3.2.0) Installed from: Unlisted Binary Package OS: Linux The HTMLSelectElement interface defines the value attribute as a read/write attribute (http://www.w3.org/TR/2003/REC-DOM-Level-2-HTML-20030109/html.html#ID-59351919), yet Konqueror treats it as though it were read only.
Created attachment 4941 [details] Test Case The alert box shows the text 'foo' two times, even though the value is set to 'bar' before the second alert.
Created attachment 7631 [details] Patch for setting the selection using setValue
looks good, but your code seems to unselect the matching value if it's already selected... does that match other browsers behaviour? (reading the spec, I'd have thought unselecting would be done via setValue(""))
Hi Germain, Thank you for the quick reaction. I checked the behaviour with firefox, indeed it also deselects the old choices, no matter if it has multiple enabled or disabled. Also when doing setValue("") or setting a value that is not in any of the options, it simply keeps the old situation. I made a patch so that khtml behaviour is like firefox in this regard, which I'll attach shortly. The only problem I can see with it, is that when programmatically setting a different selection in the list box, the old selection can still have a visual indication of the selection, I am still looking for a solution for this. Funnily enough, firefox seems to have the same visual problem, at least on my system. Cheers, Rob.
Created attachment 7674 [details] Patch for improved behaviour
Hi Rob, the new patch looks OK, but I wonder if you need to match firefox /wrt to deselecting everything else if we are m_multiple... I could check what IE/Opera does... could you post the testcase you used? (I'd like to see also this selection refresh problem you mentioned)
Created attachment 7694 [details] my testcase Hi Germain, Here is my test. I often change it while testing, but it should be a good testcase. It will show you the "selection" problem, ie part of the selection goes wrong. It seems the selection has at least two parts, a selection rectangle and some dashed outline, showing focus or something. This last one is the problem, it sticks to the clicked item, not the programatically selected item. I think fixing this requires some qt knowledge I don't have (yet) :-) Cheers, Rob.
OK, IE 6 behaves the same and Opera 7.54 too (with some bugs for multiple in the latter). > It seems the selection has at least two parts, a selection > rectangle and some dashed outline, showing focus Yes, that's the focus outline. Focus is independant from the selected item, so that's not a bug. If the user did click on an item, it must gain focus whether you programmatically change the selection or not. Please commit at will (BTW, you can simplify your patch by removing the if ( option ) checks, those are statically casted and the options pointers are guaranteed to be valid)
Bug #83479 is closely related, except it also adds items like this: selbox.options[selbox.options.length] = new Option('Select a Version',' ');
has been fixed a while ago