12.17 KB, image/gif
11.94 KB, image/gif
11.38 KB, image/gif
12.04 KB, image/gif
User-Agent: Mozilla/5.0 (OS/2; U; Warp 4.5; en-US; rv:1.7.12) Gecko/20050922 Build Identifier: Mozilla/5.0 (OS/2; U; Warp 4.5; en-US; rv:1.7.12) Gecko/20050922 If you scroll too fast in the Message Filters UI (filter rules), all entries appear blanked, if you use the arrow buttons adjacent to the scroll bar, the topmost or the bottommost entry stays and only the other two (only three rules are visible at the same time) do actually scroll. Reproducible: Always Steps to Reproduce: 1. Open Message Filters dialog 2. Edit any filter to contain several rules 3. Scroll using the scroll bar and the arrow buttons Actual Results: The display (only the field values) get garbled up. Expected Results: Content should scroll normally I haven't tested on Linux and Win, but to my memory this is an OS/2 only problem, also, I couldn't find any bug describing this behaviour, although I have seen this on very many Mozilla builds so far.
Confirmed. This error cannot be reproduced on Linux (Mozilla/5.0 (X11; U; Linux i686; de-AT; rv:1.7.11) Gecko/20050729), so this seems to be an OS/2-only bug. If you create a set of filter rules with some visually helpful content, e.g. checking the subject line to contain a pattern of 1s and 0s (subject contains 0001 subject contains 0010 subject contains 0100 and so on, about 16 of such rules), you can see that the algorithm that paints the content of the window is called more than ones, the content thus gets painted several times, and obviously the algorithm is not called with the same parameters. If you click on the arrow buttons instead of dragging the scroll bar, you should not have any adverse mouse effects, just one pure click, so it should be expected that the content is only painted once. Even then it is painted multiple times with different parameters, which can be clearly observed with the described patterns. So on OS/2 maybe these different "passes" do not all paint the entire content anew, but only parts of it, thereby garbling the window content. What is also to be noted that on Linux there are four lines of filter rules visible, on OS/2 only three - both on default font settings by the OS, using the same screen resolution (1600 x 1200).
As there won't be any non-security fixes to the 1.7 line, please also test with SeaMonkey 1.0beta. I just created 12 filters so that the scrollbars showed and it never garbled the display.
Created attachment 207336 [details] Message Filters dialog (initial) This is the Message Filters dialog after opening, everything looks good.
Created attachment 207337 [details] Message Filters dialog after grabbing the scroll bar This is the Message Filters dialog after grabbing the scroll bar. Note the dupe: This is a painting problem, there are no duplicate filter rules...
Created attachment 207338 [details] Message Filters dialog after scrolling down and up This is the Message Filters dialog after scrolling all the way down and back to the top: All field values are blank, even the boxes around them magically disappeared.
Created attachment 207339 [details] Message Filters dialog after some scrolling with the arrows This is the Message Filters dialog after some scrolling using the arrow buttons. As you can see, there is one dupe (artificial, there are no duplicate rule definitions), and when you compare this screenshot to filter1.gif: In both screenshots the scrollbar is topmost, but the rules displayed are all different. All lines are rules that are defined far down the list, so all three lines displayed are wrong...
Created four screenshots to show the effect. My apologies for the language that can be seen on these shots. As this is from my real Spam filter definition, it does contain explicit language, so beware...
Note comment 2, please test it with SeaMonkey branch builds from http://ftp.eu.mozilla.org/pub/mozilla.org/seamonkey/nightly/contrib/latest-mozilla1.8.0/
Assignee: general → mail
Component: General → MailNews: Main Mail Window
QA Contact: general
OK, the screenshots help me to see that you were actually refering to the dialog for a single filter (I still don't know how you got the wait pointer that appears in the screenshots, but that doesn't really matter.) I do see that this dialog causes some weird effects, especially when used with the Modern theme in 1.7.12 on OS/2. But I tested with several themes with SeaMonkey 1.0beta and there it is fixed. And as 1.7.x non-crititcal bugs won't get fixed and this seems to be an OS/2 specific problem where I would probably be the one to fix it, I mark this one WONTFIX, sorry.
Severity: normal → minor
Status: UNCONFIRMED → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → WONTFIX
Version: unspecified → 1.7 Branch
The screenshots are made with pmcamera 2.12 by simply pressing the printscreen button. I have seen the painting problem on several versions of the 1.7 branch, I do not recall when it started. And this is the only UI dialog that causes such a problem, everywhere else scrolling is no problem at all.
You need to log in before you can comment on or make changes to this bug.