Version: 3.5.6 (using KDE 3.5.6, Kubuntu (edgy) 4:3.5.6-0ubuntu1~edgy1) Compiler: Target: i486-linux-gnu OS: Linux (i686) release 2.6.17-10-generic If <select> has "width:100px" and <option> has "width:100%" then when showing the options they should use all the required width, even if it's bigger then 100px. That's how it works in Firefox. But in KHTML the CSS "width" does nothing in <option> CSS. Try this simple code in Firefox and Konqueror to undersantthe bug: <select style="width: 50px"> <option style="width: 100%">short</option> <option style="width: 100%">very very very very very very very long, more than 100px</option> </select> In Konqueror the <option>'s width is always the <select>'s width.
I have created a simple HTML code to show the problem. It's here: http://ibc.43i.net/khtml-select-width-issue/index.html
Sorry, the link is wrong. This is the correct one: http://ibc.43i.net/khtml-select-width-issue.html
If the above link fails (because the free web hosting that deletes the content) I attach the page that show the problem.
Created attachment 21376 [details] Web page showing the issue
Please, any comment about this issue? really nobody confirms it at least? I think it's very obvious that the bug does exist. Thanks.
Confirmed on 3.5.8, but seems to be fixed in 4.0 beta4.
The bug still exists in Suse KDE4 live CD: KDE 4.0 RC2 (3.97.0) I'm not sure if 4.0beta4 is higher than RC2 3.97.0.
This is **not** fixed in KDE 4.0.1 of Kubuntu.
Sadly, this still exists in 4.0 branch r793993.
Still occurs in KDE 4.2.2.
Hello all, I loaded attachment 21376 [details] in Konqueror 4.4.3 (Linux 2.6.31-19-generic i686 32bits; Kubuntu package; Qt 4.6.2) and when expanded, the list of options was as wide as its widest option (the 2nd option which was obviously wider than 50px). No clipping occured. So, as far as I can see, this bug was FIXED. Otherwise this WORKSFORME. Note that the testcase has invalid document structure (document root and body node are inferred), no doctype declaration; so it triggers "quirks" backward-compatible rendering mode, not standards compliant rendering mode. Also, the style="width: 100%" for the option is totally, entirely pointless, irrelevant if the webpage uses valid code and declares a doctype triggering standards compliant rendering mode. So, the problem could/would have been fixed just by upgrading the markup code to begin with. regards, Gérard
Fixed in 4.5.4, closing this report.