Closed Bug 39992 Opened 25 years ago Closed 24 years ago

<SELECT> Drop-down/combo box repaints incorrectly upon item selection

Categories

(Core Graveyard :: GFX, defect, P3)

Product:
Core Graveyard
Component:
GFX
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED
Milestone:
Future

People

(Reporter: willd, Assigned: kmcclusk)

References

Details

(5 keywords, Whiteboard: [nsbeta3-][pdtp3])

Attachments

(4 files)

screenshot demonstrating the problem
14.99 KB, image/gif
Details
simple testcase: a drop-down select box within a form
120 bytes, text/html
Details
does not occur if <select> is a direct child of <body>
93 bytes, text/html
Details
Testcase to display <select> boxes leaving garbage in one another
472 bytes, text/html
Details
I noticed while in the Bugzilla site, that when I picked a certain drop box to make a selection, that it dropped "up" (not the problem) and when an item was selected, it did not repaint the screen correctly (i.e. left artifacts) when the selection box closed. All selection boxed that dropped "down" repainted correctly.
Verified w/ Linux build 2000052109 This only happens with certain dropdown menus. For example, the "Target Milestone" dropdown on this very page. Click on it, (to drop it), and then click elsewhere. It leaves artifacts. Click again elsewhere, and the artifacts are gone. This does not happen with any of my Windows builds... Just Linux.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Waqar - sounds like it may be a problem with popup windows on Linux not invalidating the parent window when they goaway. I was not able to get fail on WINNT.
Assignee: kmcclusk → waqar
I think this is the bug I was just about to file :) PC/Linux, build 2000060808 and many builds before. 1) run mozilla http://bugzilla.mozilla.org/query.cgi 2) scroll to the bottom of the page 3) select "changed by" from the drop-down box above "What is this stuff?" 4) observe: when the drop-down selectbox is closed, a large part of the left border stays drawn 5) scroll the page. The border remains until it goes off the visible part.
This bug has been marked "future" because the original netscape engineer working on this is over-burdened. If you feel this is an error, that you or another known resource will be working on this bug,or if it blocks your work in some way -- please attach your concern to the bug for reconsideration.
*** Bug 42677 has been marked as a duplicate of this bug. ***
Suggest reconsideration. Dupes are already starting to come in. Maybe someone else on linux could help out? cc reporter of bug 42677.
*** Bug 42932 has been marked as a duplicate of this bug. ***
I'm seeing this when the list drops up and when it drops down; should we change the title here? 061720 linux.
*** Bug 43116 has been marked as a duplicate of this bug. ***
As no one objected, I'm changing the title. Rationale: - Andreas, Will and I are seeing slightly different things. - It is almost certainly the case that all 3 problems are caused b the same code. - Dupes are coming in and I'd like for people to have a better chance of hitting this in a query. Hope no one has a problem with this. feel free to yell at me.
Summary: Drop box paints incorrectly when drops "up" → <SELECT> Drop-down/combo box repaints incorrectly upon item selection
*** Bug 44994 has been marked as a duplicate of this bug. ***
This bug has been marked "future" because the original netscape engineer working on this is over-burdened. If you feel this is an error, that you or another known resource will be working on this bug,or if it blocks your work in some way -- please attach your concern to the bug for reconsideration.
Target Milestone: --- → Future
*** Bug 42189 has been marked as a duplicate of this bug. ***
*** Bug 45157 has been marked as a duplicate of this bug. ***
*** Bug 46397 has been marked as a duplicate of this bug. ***
Nominating for nsbeta3. I think this is an important polish bug, judging by the number of duplicates.
Keywords: nsbeta3, polish
This is an ugly bug, and the initial report that it only happens on some drop down boxes is incorrect: It happens on ALL drop down boxes. Tested on comm build 2000072508.
Looking into it.
Status: NEW → ASSIGNED
Am I the only peson who can't reproduce this bug? On Linux Build 2000072621 (M18), the only thing I am seeing after I use a dropdown box is that the focus highlight remains on the widget until I move focus somewhere else, which is the expected behavior. I don't see any ghosts or nasties, and certainly nothing as hideous as the attached screenshot. For the record, this is Linux 2.4, XFree86 4.0.1 running 24-bit color with 32-bit pixel format, and GTK+ 1.2.8. I have never been able to reproduce this on any M16, M17, or M18 build.
*** Bug 46637 has been marked as a duplicate of this bug. ***
Whiteboard: [nsbeta3-]
Adding helpwanted (since this is Future and [nsbeta3-]).
Keywords: helpwanted
Marked nsbeta3-
Can't reproduce the problem with either attachment on Linux 2000073104 (M18) with the platform previously disclosed.
This happens on all Linux nightlies so far (including 2000073009). Observed e.g. on Linux 2.2.13 i686 [ELF] SuSE 6.4, XFree86 Version 3.3.6, depth 24, bits_per_pixel 32, libgtk-1.2.so.0.5.2*.
Apparently this works fine in M13 and M14. M15 is broken, and the 3/29 nightly shows this bug, too.
Both of the recently attached test cases show the problem!
Yeah, I'm testing on Linux build 2000080108, and both test cases, including the one entitled, "does not occur if <select> is a direct child of <body>", have the shadow problem. I'm running redhat6.2, with the only changes being helix-gnome.
That's funny. Ok, so different people are seeing different things, but at least we all can be sure that there is a bug :)
*** Bug 48011 has been marked as a duplicate of this bug. ***
*** Bug 45580 has been marked as a duplicate of this bug. ***
Uh, how can a bug with this visibility be nsbeta3-? Every single Linux user is going to hit it within an hour of starting the browser, I bet. All the neat Linux-based browsing boxes and embedding applications are going to face this as well. The press will love these kinds of bugs... If you are a user doing online banking or shopping with your browser and you select a product from a list and it leaves a frame behind, how confident will you feel it will keep your data safe?
This is definately and ugly bug. adding keywords.
Keywords: mostfreq, relnote3
Clearing nsbeta3-/Future for reevaluation in light of recent comments (and that I agree w/ them).
Whiteboard: [nsbeta3-]
Target Milestone: Future → ---
*** Bug 48199 has been marked as a duplicate of this bug. ***
*** Bug 48199 has been marked as a duplicate of this bug. ***
rods/waqar -- Your call whether to plus/minus based on # of plussed bugs you have already. Obviously it's a "like to fix" and we are getting lots of DUPs. But we can live with artifacts for RTM at this point if we have to.
*** Bug 46601 has been marked as a duplicate of this bug. ***
*** Bug 48263 has been marked as a duplicate of this bug. ***
Waqar, any idea on how difficult it will be to fix this? Makring [NEEDINFO]
Whiteboard: [NEEDINFO]
*** Bug 48588 has been marked as a duplicate of this bug. ***
*** Bug 48588 has been marked as a duplicate of this bug. ***
Keywords: testcase
*** Bug 48633 has been marked as a duplicate of this bug. ***
isn't this really a dup of bug 9809?
No, this has nothing to do with the 'outline' property.
*** Bug 38773 has been marked as a duplicate of this bug. ***
*** Bug 30122 has been marked as a duplicate of this bug. ***
*** Bug 45498 has been marked as a duplicate of this bug. ***
*** Bug 48892 has been marked as a duplicate of this bug. ***
*** Bug 48890 has been marked as a duplicate of this bug. ***
All/All i'm sorry win doesn't see this, but I think that's because we aren't using non native widgets on win [or weren't]. One dupe is Macos and I see it on linux and solaris. This may be minor to someone but I'm remarking sev:normal. Adding keywords and ccs. Does polish usually mean: unimportant? if so I suggest it be removed from the keyword string.
Severity: minor → normal
Keywords: 4xp, regression, relnote, ui
OS: Linux → All
Hardware: PC → All
Marking nsbeta3+
Whiteboard: [NEEDINFO] → [nsbeta3+]
Not a dupe of 48890
I have set some CSS stuff for the select form element on this page: http://chris.croome.net/ and when a item is selected it crashes the latest version I have - Mozilla/5.0 (X11; U; Linux 2.2.12-20 i586; en-US; m18) Gecko/20000803
it looks fine on WinNT (for what that is worth)
Hmm. WFM also on the latest Linux build (2000082221). Maybe it's been fixed recently?
I've also just tried it with Mozilla/5.0 (X11; U; Linux 2.2.12-20 i586; en-US; m18) Gecko/20000823 and it's working OK for me too :-) It's just a shame that the sizes and layout and all the form elements are not very consistent.
Still broken here, linux CVS from 082318. :-(
I'm still seeing this bug on a clean install of comm build 2000082408 on linux.
*** Bug 50290 has been marked as a duplicate of this bug. ***
*** Bug 50117 has been marked as a duplicate of this bug. ***
I noticed that if I set the background-color using CSS on the SELECT element, this problem doesn't occur for that element. It doesn't help with other SELECT elements on the same page though. (You never know...) In my test case, I tried both 'white' and 'yellow' as background colors; both of them made the problem go away. Other CSS properties don't affect it, however--for example, setting the 'color' property didn't keep it from happening. I hope this helps to track down the problem... I'm not familiar enough with the mozilla codebase to find it myself yet. cheers, p.
Additional comments (Linux build 2000090321): When I select the dropdown box, then scroll a page using scrollbar and then I select other value from the same dropdown box it repaints correctly after drop up. I can drop up/drop down on the box any times I want to and it repaints correctly. However if I try to drop up/drop down another box it repaints incorrectly again till I scroll the box out of the screen and then back. I think it definitely has something to do with getting the focus.
*** Bug 51861 has been marked as a duplicate of this bug. ***
Just a note: You don't have to select an item in the box: Just opening a box and then clicking once outside the box (in empty content area) will close the box and the outline of box hasn't gone away. Clicking once more in empty area makes the outline go away.
*** Bug 52267 has been marked as a duplicate of this bug. ***
Here is some new info: 1) Create an example with a text field and a combobox 2) Load page click in text field 3) Hit tab to tab into the combobox 4) Click on the combobox (everything looks ok) Now: 1) Load page and click in the textfield 2) Now click on the combobox 3) The problem is there Summary: When you tab from the textfield into the combobox and then click on the combobox everything is ok. So this menas that there is some GTK event happening when tabbing that is NOT happening when you just directly click down on it. My guess is a GTK level focus is not happening when you click down but IS happending on the tab.
so we're seeing basically the same thing on windows and linux... after the drop down is opened, when you click elsewhere, on both windows and linux the popup windows goes away, leaving the focus on the element. If i comment out the code in nsWindow::NativeGrab on linux that does the XGrabPointer, you can move the toplevel window around without making the popup go away. What is happening is we are actually drawing the popup's border on both the popup and the window under it. So layout *is* drawing the border. My guess is that on windows it is being clipped or something. When you click again elsewhere to remove focus from the select, then it paints the area including the area where the popup was.
When you say, "so we're seeing basically the same thing on windows and linux..." I not sure what you mean by that. Visually it works on windows so I am not "seeing" the same thing. I am also not sure how we are drawing the border into both the window (the background area) and into the dropdown. And why would it be just the border? It could be a clipping issue, but somewhere in here it is a focus issue or is has to do with focus, because it works fine if you first tab into it.
Rod what I saw was that the list window had the gray/white border, the rectangle that makes it look 3D was duplicated. When we moved the main window the border moved with it, and there was one with the list window that did not move. Plus on the Windows, the Combobox still had the focus same as Linux. There is a gray border in box after it was "closed". when the user clicks some where else the the focus goes away and the repaint happens.
Every combobox on Linux leaves garbage when it's drop down list is popped up. This is a highly visible bug which creates confusion and large numbers of duplicate bugs. Changing priority to P2.
Priority: P3 → P2
Waqar, I'm going to take this bug for now. Talking to Rod it sounds like a viewmanager problem. The viewmanager is drawing the content of the popup window into the parent document.
Assignee: waqar → kmcclusk
Status: ASSIGNED → NEW
No data loss, easy workaround (do anything to cause a reflow.) pdtp3.
Priority: P2 → P3
Whiteboard: [nsbeta3+] → [nsbeta3+][pdtp3]
Target Milestone: --- → Future
In the hopes that this information will possibly be useful to someone, I've posted a bug (bug 53318) that also deals with combo boxes being rendered incorrectly. This bug has to do with the sidebar being moved. Based on Stuart Parmenter's 2000-09-13 15:23 posting, I decided to post here because I'm seeing the border of the combo-box and the contents of the combo box being rendered in two separate places. HTH David
*** Bug 53550 has been marked as a duplicate of this bug. ***
This bug has been annoying me forever, and i usually download mozilla-i686-pc-linux-gnu.tar.gz but didn't today since the build has gained some 3 MB weight the past days. So instead i downloaded mozilla-i686-pc-linux-gnu-sea.tar.gz from ftp://ftp.mozilla.org/pub/mozilla/nightly/2000-09-21-10-M18/ (for some reasons displaying build ID 2000091312 but that is wrong) AND: This bug is not visible in that build! Background of forms is suddenly grey'ish but no garbage outlines remain.
I think this is due to new widgets landing. Does this mean this bug no longer applies? I'm not seeing this problem anymore either.
yes, I think Ian's *.css changes fixed this....right?
Assignee: kmcclusk → ianh
I just downloaded the mozilla-sea build from the 09-21-10 directory (which has build number 2000091312 just like they all have for the past couple days) and I'm still seeing this bug... on this page, as a matter of fact.
tested a clean profile: in bugzilla the outlines still don't show anymore HOWEVER: In the testcase of bug 53590 i still see the problem.
FIXED (as best I could).
Assignee: ianh → py8ieh=bugzilla
Not holding PR3 for this, marking nsbeta3-. Please nominate for rtm if we really need to fix this before shipping Seamonkey.
Whiteboard: [nsbeta3+][pdtp3] → [nsbeta3-][pdtp3]
Does this really need relnoting? It's too trivial for users, and not relevant for developers... The blurb: It seems unclear to me whether this bug requires either of a "developer" or "user" release note for Netscape 6 RTM. If anyone feels it does, can they please draft one and then nominate with the relnote-user or relnote-devel strings in the Status Whiteboard. Thanks :-) Gerv
Keywords: relnote3
Nominating for mozilla1.0. The testcase in the 9/26 attachment is still valid. This bug can be triggered on any bugzilla page by using the "OS" dropdown followed by "Platform", or using "Component" followed by "Product", or ... This really isn't a CSS problem, it's deeper. Ian, are you the correct owner for this bug?
Keywords: mozilla1.0
Not really, thanks for pinging me...
Assignee: ian → kmcclusk
This may be fixed when the new viewmanager lands.
linux x86 2001-03-14-08 I'm not seeing it anymore. Can anyone else reproduce this?
Nope. But I never saw it in the first place.
Andreas: I can't see this either. If you can no longer reproduce, please close. Gerv
I can no longer reproduce either, and I saw it all the time on cnn.com (Linux). Marking Resolved Worksforme rather than Fixed since no fix actually went in (per dbaron advice).
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → WORKSFORME
Ok, so buggy mozilla lost my comment. Typing this again with good old 4.x: This bug has been fixed by the new view manager, indeed: Build 2001032108 still shows this bug (using attachment 15559 [details] from 09/26/00), build 2001032208 works fine. The new view manager has been enabled in rev. 3.28 of nsViewFactory.cpp by roc+@cs.cmu.edu on 03/22 7:54, see http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=SeaMonkeyAll&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=03%2F22+7%3A53&maxdate=03%2F22+7%3A55&cvsroot=%2Fcvsroot Disabling the new view manager in the 03/22 build by adding user_pref("nglayout.debug.enable_scary_view_manager", false); to my prefs.js file makes the bug reappear. Reopening and marking fixed.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
.
Status: REOPENED → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → FIXED
Marking verified in the April 10th Linux build (2001041012).
Status: RESOLVED → VERIFIED
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: