Bug 76434 - select element can't be set with value attribute
Summary: select element can't be set with value attribute
Status: RESOLVED FIXED
Alias: None
Product: konqueror
Classification: Applications
Component: khtml (show other bugs)
Version: unspecified
Platform: unspecified Linux
: NOR normal
Target Milestone: ---
Assignee: Konqueror Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2004-02-29 19:01 UTC by Dominic Chambers
Modified: 2005-10-09 23:44 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
Test Case (374 bytes, text/html)
2004-02-29 19:04 UTC, Dominic Chambers
Details
Patch for setting the selection using setValue (1.28 KB, patch)
2004-09-22 20:00 UTC, Rob Buis
Details
Patch for improved behaviour (1.69 KB, patch)
2004-09-25 15:58 UTC, Rob Buis
Details
my testcase (524 bytes, text/html)
2004-09-27 20:58 UTC, Rob Buis
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Dominic Chambers 2004-02-29 19:01:49 UTC
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.
Comment 1 Dominic Chambers 2004-02-29 19:04:27 UTC
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.
Comment 2 Rob Buis 2004-09-22 20:00:41 UTC
Created attachment 7631 [details]
Patch for setting the selection using setValue
Comment 3 Germain Garand 2004-09-25 03:26:07 UTC
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(""))
Comment 4 Rob Buis 2004-09-25 15:58:16 UTC
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.
Comment 5 Rob Buis 2004-09-25 15:58:51 UTC
Created attachment 7674 [details]
Patch for improved behaviour
Comment 6 Germain Garand 2004-09-27 17:42:06 UTC
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)
Comment 7 Rob Buis 2004-09-27 20:58:01 UTC
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.
Comment 8 Germain Garand 2004-09-28 20:05:18 UTC
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)
Comment 9 Maksim Orlovich 2004-12-08 18:32:09 UTC
Bug #83479 is closely related, except it also adds items like this:
selbox.options[selbox.options.length] = new Option('Select a Version',' ');
Comment 10 Germain Garand 2005-10-09 23:44:10 UTC
has been fixed a while ago