Closed Bug 52975 Opened 24 years ago Closed 22 years ago

[CBX]option item of select doesn't behave correctly inside a fieldset

Categories

(Core :: Layout: Form Controls, defect)

Product:
Core
Component:
Layout: Form Controls
Platform:
x86
All
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
VERIFIED FIXED
Milestone:
Future

People

(Reporter: Erich.Iseli, Assigned: rods)

References

Details

(Keywords: testcase, Whiteboard: workaround)

Attachments

(2 files)

Testcase
1.02 KB, text/html
Details
Simpler-to-debug testcase
645 bytes, text/html
Details
From Bugzilla Helper: User-Agent: Mozilla/4.7 [fr] (Win98; I) BuildID: 2000091505 When selecting an item of a select element, the old choice remains visible. the new choice gets set only when you remove focus of the element. Reproducible: Always Steps to Reproduce: 1.load testcase 2.select alternative choice in first option list (inside a div) 3.select alternative choice in second option list (inside a fieldset) Actual Results: 1.When clicking on the Alternative Choice inside the div, the list closes and the selected value is shown 2.When clicking on the Alternative Choice inside the fieldset, the list closes _but_ the initial value is shown. Expected Results: Inside fieldset the selected value should replace the initial value. Note that when the element loses focus, the selected value gets finally shown.
Attached file Testcase —
Yes, this looks bad because it appears the select isn't getting the repaint notification it should. If you cover the window and have it repaint it is fine. I'll take a look.
Status: NEW → ASSIGNED
It works fine without a legend, hmmmm....
Rod, that might be useful for debugging, but keep in mind that the legend element is *required* inside the fieldset. Makes sense also: what's a fieldset without a legend? just a border around a form, and this could be done with other means. For your record, the DTD says: <!ELEMENT FIELDSET - - (#PCDATA,LEGEND,(%flow;)*) -- form control group --> taken from: http://www.w3.org/TR/html4/interact/forms.html#edef-FIELDSET
I should have added more text to my comment. I just wanted to capture what I discovered in case I have to come back to this later, which it is beginning to look like. I have spent a couple of hours and can't seem to find the difference between having a legend and not having it and why it isn't updating correctly. The combobox does get its new value and the comboxbox is being asked to be painted. dirty rects look ok, I need to look closer at the clip rects but they seem to look ok also.
Updating QA contact.
QA Contact: ckritzer → bsharma
*** Bug 55633 has been marked as a duplicate of this bug. ***
Summary: option item of select doesn't behave correctly inside a fieldset → [CBX]option item of select doesn't behave correctly inside a fieldset
Target Milestone: --- → Future
QA Contact Update
QA Contact: bsharma → vladimire
This is weird as heck. I will end up debugging this to some extent, my bug 34297 patch doesn't even let you *open* it. Setting this as a blocker until I figure out what is going on.
Blocks: 34297
OK, it seems fine in my patch now. Removing block. Still no idea what's going on though.
No longer blocks: 34297
*** Bug 74069 has been marked as a duplicate of this bug. ***
Keywords: testcase
*** Bug 105615 has been marked as a duplicate of this bug. ***
Any solution for this bug insight? We have a couple of <SELECT> dropdowns nested in a <FIELDSET> here and could use some advice to fix the above behaviour. Thanks.
Reik Schatz, I've got a simple workaround to this bug. The only thing to do is add onchange="blur()" to the select tag. This will remove the focus from the select element and repaint. I can see a little delay between selecting and getting it repainted, but otherwise I'd say it's ok ;-)
Whiteboard: workaround
Erich, I know about this workaround but things are a little bit more complicated here. Imagine two <SELECT> dropdowns, one featuring months the second featuring days. Both nested inside a <FIELDSET>. When the users clicks on "April" for example, I have the "31st" dynamic removed from the days dropdown via javascript and the selectedIndex set to 0. The onChange event on both dropdowns should fire here because both <SELECT> elements have been changed, one by user input and one by script, correct? Unfortunately the blur() only seems to work for the <SELECT> element that was changed by the user :(
*** Bug 104904 has been marked as a duplicate of this bug. ***
*** Bug 109316 has been marked as a duplicate of this bug. ***
OS: Windows 98 → All
Blocks: 121127
Priority: P3 → --
*** Bug 142633 has been marked as a duplicate of this bug. ***
*** Bug 144411 has been marked as a duplicate of this bug. ***
I just want to note that the new Bugzilla Query form shows this problem quite nicely with the "Email and Numbering" fieldset. (would someone please add http://bugzilla.mozilla.org/query.cgi?format=modern to the URL field here? It would have helped me find this bug sooner...)
dkoppenh@null.net, I tried your link and funnily all drop downs inside the fieldset work very well. The testcase, however, shows that this feature is still broken. Can anyone repro this behavior? (btw: Mozilla 1.0)
*** Bug 158096 has been marked as a duplicate of this bug. ***
*** Bug 160336 has been marked as a duplicate of this bug. ***
Maybe this is obvious, but I haven't seen it in the comments yet, so here goes: I have a workaround for this that seems to work perfectly fine, which goes as follows: <SELECT onKeyUp="javascript:this.focus();" onClick="javascript:this.focus();"> HTH
This one is easier to debug--click on "Switch to y" and it will switch the box to y but it won't show up until you drag a window over the area. You can change the testcase to a div and it should look almost identical--have same coordinates. Funny thing is, it appears to be receiving the Paint() call.
Fixed with bug 121127.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
*** Bug 163384 has been marked as a duplicate of this bug. ***
Confirm fixed 2002081612/winXP.
Status: RESOLVED → VERIFIED
Confirm fixed 2002081612/winXP.
Merp. My apologies, marked this verified by an accident.
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
returning to original "resolved fixed" state.
Status: REOPENED → RESOLVED
Closed: 23 years ago → 22 years ago
Resolution: --- → FIXED
verifying on build 2002-08-27-04-trunk win 2k and linux red hat
Status: RESOLVED → VERIFIED
Sorry if this is somewhat off-topic - I will welcome a suggestion where is a better place to ask. Is there - in general, or at least in this particular case - a way to determine from the version/build ID, either on the server side (from User-Agent) or with JavaScript, whether a particular bug is fixed in that build? The problem I see and perhaps don't understand is this: I know that there are "branches" in the code development, so for any given date there can be multiple different builds. I know when the bug was fixed - in the case of this bug, on 2002-08-16 or earlier. But does comparing the build ID to this date do the right thing? (I need to activate a reasonable workaround for the buggy versions, and only for them, because it has unpleasant side effects.) Thanks for any advice!
The build ID is the date Gecko was built on, yes.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: