Build ID 2000-041908 M16 Linux After the fix for bug 30091 was in, the behaviour of dropdown boxes changed a little. Sample URL bugzilla.mozilla.org/query.cgi The mispainting consists of various ascii signs being written on dropdownbox arrow button, and to the right of it, once a select is made. The signs that are "mispainted with" depends on what you wrote in the searchfield, but it's not 100% consistant from time to time. In addition, the mispainting doesn't occure for all the selects, just some. Attaching screenshot.
Reassigning to Rod
Assignee: troy → rods
i don't see this anymore. build 2000-042609 M16
I guess I will mark it works for me.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → WORKSFORME
*** Bug 38394 has been marked as a duplicate of this bug. ***
Isn't this bug a dup of a much older one? In any case, reopening in light of bug 38394, which I was able to reproduce. See that bug for some more details, adding URL.
Status: RESOLVED → UNCONFIRMED
Component: Layout → HTML Form Controls
Resolution: WORKSFORME → ---
changing QA, confirming
Status: UNCONFIRMED → NEW
Ever confirmed: true
QA Contact: petersen → ckritzer
the mispainting mentioned in 38394 is somewhat visible on linux too, but not as clear: it seems to be located lower on the button, so only the top of something displays. Different from when this bug was originally submitted, the mispainting is now only ON the button, no longer extending out on the webpage to the right of it. A click on the button seems to refresh it and the "characters" go away.
I don't see that. Some things still do carry onto the content area -- for example, choosing the "HP" option under the "Platform" dropdown box in the URL above will still cause garbage ASCII to extend into the area surrounding the box. Furthermore, in the aforementioned example, a mere click on the button doesn't cause the characters to disappear, as you said. I'm seeing this in 2000050608 win98.
This might be a clipping problem or it could be related to 36558. 36558 changes how the display area is created, what frames are used and how they are resized. Once that is checked in we should recheck this on Linux.
Status: NEW → ASSIGNED
Depends on: 36558
Target Milestone: --- → M16
This should be fixed, can anybody reproduce it?
can only speak for linux, where i don't see the problem now. (2000-050820)
I did see this in a build yesterday or the day before, but not today's build. ( 2000050920 ) -WD
I will close this out because we are getting close to the tree closing, if you see it, open this back up.
Status: ASSIGNED → RESOLVED
Last Resolved: 19 years ago → 19 years ago
Resolution: --- → FIXED
vrfy fixed, no longer seeing in 2000052508
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.