I work on a complicated intranet web app that contains a lot of select boxes. If these are populated in the usual way it makes navigating around our interface very unwieldy so we only populate the select box options "Just in Time" (see the URL for an example). This works brilliantly upto and including Firefox 1.0.4 but on the trunk, this seems to be broken. I'm guessing this bug will be marked as invalid but were that to be the case I think it would be very limiting for future web apps with complicated user interfaces.
Tested with a Deer Park 1, 20050525 winxp build. When you tab to the select and press the arrow down key repeatedly, the select box is populated transparently to the user. When you click on the select, only the initial value is displayed until you release the mouse and click the select again. It appears that the select is not redrawn when the new options are added. Not js engine, over to Layout Form Controls.
Assignee: general → nobody
QA Contact: general → layout.form-controls
this regressed between linux trunk 2005042805 and 2005042901, probably bug 240276.
Depends on: 240276
Keywords: regression, testcase
I believe that this regression should be fixed for 1.8b3 or atleast 1.8b4. Reproduced on Windows XP aswell, setting OS -> All, blocking1.b3 -> ?
OS: Linux → All
I think everything's OK except the dropdown widget isn't being resized.
Created attachment 186565 [details] [diff] [review] fix The bug is that the combobox frame doesn't allow its dropdown listbox's view to resize during reflow. Usually this is OK and a performance optimization because we resize and reposition the view when we show the dropdown. Of course, when the dropdown is already showing during reflow, we need to let the view resize. (I don't know how this worked before!) This patch is simple and does that.
13 years ago
*** Bug 298198 has been marked as a duplicate of this bug. ***
Comment on attachment 186565 [details] [diff] [review] fix Simple fix to a regression that hurts dynamic Web sites
Attachment #186565 - Flags: approval1.8b3?
Comment on attachment 186565 [details] [diff] [review] fix a=chofmann
Attachment #186565 - Flags: approval1.8b3? → approval1.8b3+
Status: ASSIGNED → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → FIXED
It doesn't look like backing this out helped btek Tp, though unfortunately Neil backed out his change so we only get to see one cycle's worth of data.
You need to log in before you can comment on or make changes to this bug.