Using a release build from 05/08/01 on win2k....(I've been seeing it since new modern landed though)... when I start up the browser, my personal toolbar is covered with vertical black lines making it hard to read the text for each bookmark. If I actually mouse over the particular bookmark the hash lines go away. Note: I believe I have 'large fonts' turned on for this machine. that may be a cause. also, my url bar has 2 horizontal hash marks just to the left and right of the urlbar.

Scott, you'll have to show me this one in person.

does this mean you are coming over to my house? =) I still saw it using a build from friday.

I have exactly the same problem : vertical black lines in personal toolbar, and horizontal marks in urlbar (Build ID 2001051308)... I'm using large fonts too.

I can see this on Linux. Mozilla build ID: 2001051708. Changing OS to ALL Oddly enough, on my W2K it doesn't appear... System configuration - specific?

I'm seeing this on Win2K ever since modern3 landed. It affects some other toolbars as well: Formatting toolbar in message composition window. Mode toolbar in JavaScript Console window when the window is maximised. Toolbar in Bookmarks window when it's maximised.

that screen shot is exactly what I get. I'm going to nominate this for .9.1 and let PDT decide. I think it makes for a pretty bad first impression. I get it all the time at home.

hey joe, did PDT have a chance to triage this and determine it's not a beta stopper before moving this to .9.1? Just wondering. I was trying to get it on their radar.

Hmm using 2001051804 on Win2k and I'm not seeing this..

are you using large fonts? As the bug states you have to be using large fonts to see this. It's pretty easy to reproduce if you use large fonts. Joe, I don't know if you saw my previous comment but did PDT have a chance to triage this to .9.2? I wanted them to take a look at this to determine the severity and they won't see it if you moved it to .9.2 yourself =).

My apologies, I missed the large fonts note on the bug report. I see this with Large fonts turned on...

This indeed happends when you have Large fonts set with Window, doesn't happend with Small fonts. And it affects maximised windows. So basically steps to reproduce are: 1. Set your system to use Large fonts. 2. Maximise Mozilla windows (Browser, Bookmarks, JS Console, Composer). This basically affects most of users who use high-res sceen modes? Verrrrrrrry off-puting.

Yes, I've seen on windows 98 (2001-05-22-06-Mtrunk). Steps to reproduce: 1. Go to the control panel > Display > Settings > Advanced > FontSize: Large Fonts. 2. Reboot the machine. 3. Launch the browser. 4. Go to Edit > Preferences > Fonts. 5. Select the large fontsize like 72. Notice that the black hash marks in the personal toolbar for new modern. Screen shot will attach.

the image i see on win2k is more severe than the win98 case. What I see matches the first image in this bug where the entire toolbar is covered in vertical black hash bars to the point that you can't read the text in the personal toolbar.

The window on the second screenshot is not maximised. The severe case usually shows itself when you maximise it. But in other ttoolbars it often covers only part of them. So maybe this is actually the same thing, but covers tiny part of the toolbar because of huge font size being selected for the browser.

To clarify, it appears in non-maximised windows as well. Just on maximised ones it appears *always*, and in non-maximised ones - it often appears normally.

Actually it seems to be dependant on the width of the window. When you slowly resize it horisontally, for each pixel that you move it, it disappears/re-appears.

*** Bug 82831 has been marked as a duplicate of this bug. ***

*** Bug 82763 has been marked as a duplicate of this bug. ***

*** Bug 84112 has been marked as a duplicate of this bug. ***

SPAM: suggest keywords to get proper attention/prioritization: 4xp, correctness, mozilla0.9.1, regression

This is definitely a problem with libpr0n. The personal toolbar uses a tiled background image (chrome://global/skin/toolbar/tb-mid.gif), and apparently on some configurations libpr0n is having trouble painting this image. Reassigning...

*** Bug 86833 has been marked as a duplicate of this bug. ***

I'm surprised this bug has a 'normal' severity. Let's face it, most people use 800x600 or 1024/768 these days and the latter desktop size is hardly legible with small fonts. This is not a heavy bug in a technical sense, as everything works just fine. However, from a marketing point of view, this one is a killer. Starting up to a hash toolbar gives an impression that is not in line with the massive amount of work that has been put into Mozilla over the last few years, or the technical achievements in it.

I see it under Win2K with large fonts. Present in 0.9.1, but not in 0.9 (build 2001050515).

c'mon pav, you know you want to fix this.

pushing out. 0.9.2 is done. (querying for this string will get you the list of the 0.9.2 bugs I moved to 0.9.3)

adding nsbranch consideration keyword.

*** Bug 88959 has been marked as a duplicate of this bug. ***

This is a really annoying bug, since it destroys the nice impression of the modern theme. The strange thing is that the hash lines go away, when you move over them, or they are redrawn (by moving another window over it and away again). But they reappear after minimizing/maximizing(window). Configuration: Win2K, Large Fonts, 1280X1024, Matrox G450

*** Bug 89241 has been marked as a duplicate of this bug. ***

Works for me as of build 2001070404, no more black hash lines. But now the text is displayed one Pixel higher in original view (after maximizing) than after updating by moving over the bookmarks. This looks slightly croocked, if there were overlapping windows, so that part of the text is higher than the rest.

are you using large fonts? I still see this problem.

2001070504, win2k, large fonts I confirm Michael Wesoly's comments, the black hash marks have disapeared, but I have the 1 pixel higher problem

I'm still seeing it on 2001070504

I am using large fonts at 125% (120dpi). And I don't see it anymore. Strange that it only seems to work for some now. Updated mozilla from 0.9.2. to 2001070404 by mozilla installer (installing files directly over internet). Installed the 0.9.2. from scratch with the talkback package. Maybe it depends on installation method, although that wouldn't make much sense. But the regular daily build zip-Files come with directories \bin which is \Mozilla in the packaged version.

*** Bug 86243 has been marked as a duplicate of this bug. ***

*** Bug 89416 has been marked as a duplicate of this bug. ***

The attachment created on 07/08/01 was a snaphsot of the problem observed with Mozila 0.9.2 and Netscape 6 PR1 on Win2k SP2. -Moiz

Update (was: works for me as of 2001070404): The hash marks reappeared today, when I was resizing the browser window. The behavior seems to depend on horizontal size of the window. If the number of pixels is odd, then the hash marks appear, if the number is even, the toolbar is drawn correctly. (Or vice versa, I didn't know how to verify) This is still with 2001070404. Steps to reproduce: 1. Open browser window 2. Resize very slightly in horizontal size (by one) Can anyone confirm?

Michael Wesoly: I'm seeing the same weird even/odd behavior as you. Looks just like the 5/17 screenshot to me. In other words, ugly. This is on W2k, SP2, Mozilla Build ID 2001071004. "Large Fonts" turned on for this machine--does anybody do any differently?

I haven't seen any movement on this one for a while and the 0.9.3 freeze is next week. Is this bug still for 0.9.3 or is it to be moved out again? If so, too bad. I was looking forward to prodding my friends and colleagues to move to Mozilla, but they'll be less than enthousiastic on first sight if this bug is still there.

attached another screenshot Confirm with build id 2001071604 I see this for many months but only with the modern theme. I have a NVidia TNT2Ultra card with detonator3 drivers, not that it should matter. The hash marks appear mostly at the empty regions of the toolbar but are in a way unpredictable. I think they used to appear on an older (months) old version of the sidebar as well. Mozilla became so good now that this is a major issue for me :)

This is on NT4SP6a, large fonts, 96dpi. Confirm alternating appearance when resizing horizontally. added me to cc voted

I have nVIDIA TMT2 card as well. Could this be chipset/driver specific? Does anyone with a different chipset sees this problem? Additionally, the effect of this bug on Windows ME was totally different from Windows 2K. It had long horisontal lines in the toolbar, or even TVset-like noise. Sorry I can't attach a screenshot. I must agree with ovvldc@netscape.net comment. This bug is a major reason for me not to go telling my friends that Mozilla rocks my world and installing it on their PCs. It basically embarrases the "greatness" of entire browser. I myself at first wanted to stop using Mozilla until this gets fixed, but learned to get around this bug by manually resizing browser to full screen, instead of maximising the window.

I don't think it's a hardware problem. I have the same problem on a Matrox G400 on Windows 2000.

It is not hardware dependent. I have using GeForce2 on Win2K with Large Fonts using Build 2001071604 using the Modern Theme only. I also confirm the previous observation made on 2001-07-10 that it is a function of the horizontal size. If you resize your browser horizontally you can get it to work/not-work.

I am using a Celeron 300, 64 MB RAM, 4MB S3 Virge DX videocard (I don't play games in my office), NT4 SP6. I honestly doubt this is hardware dependent.

I personally think this is the most important-to-fix bug in Mozilla right now. It is 100% reproducable and probably effects 1/3 - 1/2 of all Windows Mozilla users. Also, if it effects you, there's no way you're not going to notice it; it is completely "in your face." Netscape CANNOT (or would be incredibly stupid to) release a product with this bug in it. It seems like it should be a snap to fix, so why isn't it? Also, no one has really commented on the two little hash marks to the left and right (and slightly below) the URI bubble. These are probably unrelated (since they never go away), but should also be fixed. Are these in a seperate bug somewhere?

With bug 77675 almost out of the way I agree totally. I wonder why this one doesn't have a PDT+ keyword. The strange thing is that it is apparently confined to the modern theme. Neither the two stripes James just metioned or the toolbar mess is evident in the classic theme. There is one vertical stripe at the left of the toolbar for no apparent reason but I get two in the modern. You can see it on the screenshots, I suppose. So if one theme renders fine and the other does not, is this one properly linked to ImageLib? Could it be regression caused by the new modern theme or something? I would expect this bug to go to Themes or Skinability or XP: Menus or whatever....

<< So if one theme renders fine and the other does not, is this one properly linked << to ImageLib? Could it be regression caused by the new modern theme or something? << I would expect this bug to go to Themes or Skinability or XP: Menus or whatever.... If a theme brings out a bug in ImageLib, it is still a bug in ImageLib. The problem is in ImageLib, and not the theme, and definitely not in "something." Changing the theme would only be a temporary hack.

-> 0.9.4

It is so sad, that this bug is pushed back to the next milestone, again. I guess, there are more serious bugs, but this one is visible to everyone and not just some. And - as pointed out before - it makes a desastrous impression on the state of the whole application. It is just like buying a new shirt and you discover that it has a HOLE in it. You wouldn't buy it, even if the vendor would say: Well, but it is a very nice FABRIC.

I asked the drivers about the deferrence stragtegy here and got a terse sounding email back from Chris Blizzard roughly saying 'If it is that important, fix it yourself. We have other priorities.' So I still don't understand the reasoning. I haven't coded for over seven years and I never was a C guru. Any takers in the field to fix this one?

*** Bug 92961 has been marked as a duplicate of this bug. ***

I am amazed that this bug is not even mentioned in the release notes for 0.9.3. I guess it is just not on any radar screen for really annoying bugs. If I only had some programming skills...

one short of a 10 dupes, adding mostfreq keyword also adding mozilla0.9.3 and mozilla0.9.4 keywords hopefully this will get some attention if not for 0.9.3, then for 0.9.4 release It will be amusing if Netscape 6.1 comes out with this bug staring in people's faces. :o)

Maybe modern and nscatfood keywords should be added, since those keywords seem to match this bug. Actually, I think it is going to go like this: NS6.1 is cut and built and lands on the desk of someone in the marketing department. He/she installs, runs it and on opening of the browser window says something along the lines of 'you must be *joking*, right?' And that will be the end of it (hence the catfood nomination).

Hopefully that would be the case. But I believe it starts with classic skin by default. AND they would have %50 percent chance of seeing this bug since it depends on window width. Maybe the reason drivers haven't been paying much attention to this because they got enormous monitors with resolution width that just doesn't trigger it? Either way I can live with workaround for this issue. It's more of a matter of in-your-face embarrasement of the project. adding modern keyword.

I believe I found what's going wrong. It's happening in some cases during the tiling process When the size is odd, the size of the image to be tiled is miscalculated (in this case, 2 instead of 1). I have a proposed patch, in the attachment above

Thanks, Antoine! The right person to review this would probably be kmcclusk; I've cc'd him on the bug. Also, it's convention to attach ``diff -u'' output, which is a bit easier for humans to read.

Oops, kmcclusk is away for now. dcone, could you take a look?

*** Bug 93358 has been marked as a duplicate of this bug. ***

*** Bug 93556 has been marked as a duplicate of this bug. ***

If I understand it right, this patch affects only Windows, however this bug can be seen on other OSes as well (at least Linux). Antoine, could you check and correct corresponding files for other platforms if nessesary? Also I don't think it explains why on Windows it's not affecting users who use Small system fonts?

*** Bug 93767 has been marked as a duplicate of this bug. ***

I ported my changes to all corresponding files on other graphic platforms where the DrawTile function is implemented. I cannot build/test on other platforms than win2000, so I hope some people can do it. Why it only affects large fonts ? The problem is a rounding problem, and the value to round depends on many things including the width of the rect to tile into. My explanation is that with small fonts, it's possible that the wrong case never happens.

*** Bug 94157 has been marked as a duplicate of this bug. ***

Yeah, that could be the same, it looks quite similar. I can't reproduce on 2001080603 (trunk), win2k, big fonts, so I can't tell you if my patch corrects it.

*** Bug 94334 has been marked as a duplicate of this bug. ***

Can't reproduce either (with 2001080110). BUT it is interesting, that you don't have the little hash mark on the lower end of either side of the url-area. (see attachment from 07/18/01) Maybe that is the same error as you have in your browserwindow. Is the problem with horizontal rounding also true for vertical rounding? Antoine could you check?

FYI, I am running build: 2001070604 with display: True Color 1280 by 960 Small Fonts. I no longer see hash marks in the toolbar. I can't remember if that was fixed by an upgraded or when switch my display and font size. I switch font size a while ago to work around another bug. I can try to upgrade if you want, but I've been happy with this version, so I've been reluctant to do so.

I forgot to mention that I'm running large fonts, I have not encountered this problem on my laptop (with small fonts)

Yeah Michael, the rounding problem definitely exists for vertical coordinates as well as horizontal. The hash marks in the URL bar come from a vertical rounding problem, and are fixed by my patch too. About Sean's problem, what make me think it's the same problem is that the distance between the marks is exactly the height of the non-tiled original image. By the way, my patch doesn't fix the 1-pixel higher problem, which come from somewhere else (text is not tiled)

i've checked in a fix that resolves this problem.

2001081003/win2k/32bpp/big fonts the hash marks have disapeared but some new (maybe related) problems have appeared : when you're partially redrawing some of the elements, the background is displayed slightly incorrectly (see following attachement). Steps to reproduce : * move the mouse over a toolbar item what you get : a darker blue line just below the item text expected result : a nice blue gradient in the background * move another window over the URL bar what you get : a lighter blue line below the URL bar expected result : a nice blue gradient in the background

See bug 94608.

no longer seeing the bug on Win2K 2001081003 can people verify for other OSes that were affected?

I can also confirm that the problem is fixed for Win2K, large fonts with build 2001081208. But now I see the lighter grey/blue, darker grey/blue lines under the toolbar items/url bar. (as reported by Antoine) Moving to bug 94608?

*** Bug 95996 has been marked as a duplicate of this bug. ***

*** Bug 96728 has been marked as a duplicate of this bug. ***

I still see this on Mozilla 0.9.4 (build 2001091303), talkback build on WinNT4 SP6a. It looks exactly as in attachment 41609 [details].

Johan, Could you please get a newer build and let me know if you are still seeing this behavior? I am not seeing this on W98 or W2k with large fonts and build 2001-09-17-05-0.9.4, thanks in advance :-)

OK. I *am* seeing this on WNT4.0 SP6a, *small* fonts and build 2001-09-17-03 (which was the most up to date nightly I found). As I am not using large fonts, what I am seeing *may* not be the same bug, but it sure looks *identical* to the attached screenshots.

I have never seen this behavior(large or small fonts) but per Johan's comments, I am re-opening

I have always seen this behavior (attachment 41609 [details]) on my Win2K work machine, but have always thought it was due to the image-redrawing problems on ATI Rage video cards. I've thought it was different than this bug because I've never seen it in the personal toolbar, just around main toolbar buttons, the url bar, and scrollbars. I also see it on scrollbar sliders in the Classic theme. If it's the same problem, count me as another confirmation of it still happening. My system, if it helps any: Compaq Deskpro, PIII 500, 256MB RAM Unknown mainboard ATI Rage Pro video card ESS AudioDrive onboard sound Win2K Service Pack 2 Intel PRO/100 network card Small fonts (I've tried large fonts too, no change.) I don't suspect software incompatibilities because Moz was the first application I installed after the OS.

I added three attachments showing different types of marks I get with 0.9.4 as well as a recent nightly build. Marks on scrollbars occur in mail as well. These types of marks started appearing after the first fix to this bug, which solved the vertical marks in the personal toolbar.

What DPI are you running at? I expect this is a rounding bug.

What DPI are you running at? I expect this is a rounding bug.

DPI? I'm running in 1400x1050x32, on an S3 Savage/IX. The Windows task bar is on the right of the screen and my Mozilla window maximized. If I change the horizontal width the the task bar, I see the patterns change position or disappear.

Aha! Changing my screen resolution made the problem go away. I usually run at 1280x1024 and get the marks. Changing resolution to 1024x768 or 800x600 made the marks disappear. (ouch, 800x600 on a 22-inch monitor hurts!) Changing back to 1280x1024 made them reappear. I'm running at 96 dpi, by the way.

*** Bug 100932 has been marked as a duplicate of this bug. ***

Pavlov, can you let us know when this would be fixed? Sol, how many users have their screen resolution set to 1280x1024?

it isn't all 1280x1024 people.. it some subset.. I'm having trouble reproducing it on my machines.

It seems to be tied to a certain combination of hardware; perhaps it would be helpful for people who are seeing this bug to list their hardware so we can try to narrow it down to certain configurations. Of course I'm not a gfx expert so if this info would not be useful then please say so, so we can avoid unnecessary noise. My system specs are in a previous comment from 2001-09-18 11:58 I should also mention that decreasing video hardware acceleration by one notch clears up the marks for me.

It happens on my machine; I should be in tomorrow or the next day, so you can take a look then. Dunno if this helps, but my p2t=19 (not the normal 15 that everyone on Win32 has).

adding PDT, need to know scope of the problem and how usual this config. is. Doesn't look a stopper at this point

German: Do you have any data on how common it is for users to have screen resolution at 1280x1024? I do not.

Is bug 93552 a dupe of this?

PDT- ... thinking this is a smal percentage of users, and the amount of effort to track it down will take too long.

> thinking this is a smal percentage of users Speculation, your honor. Also, this is an advocacy killer: "Why are you using Mozilla when it looks like crap?" "But that's the only problem with it!" "Sure..."

caillon: I don't think bug 93552 is a dupe of this -- that one appears do be dealing with JavaScript errors, whereas this one deals with Imagelib problems. Is that a typo, maybe?

> thinking this is a smal percentage of users Even if you have 5% of users (and how are you going to get such numbers anyway) having this issue, I don't think it's acceptable because it makes Mozilla look like ****. Just anybody using W2K on an IBM T21 in 1400x1050x32 (which is probably the default) like me will have the problem.

Erik, Johan: Jaime's mark of PDT- is a Netscape-only indication, relevant to the MOZILLA_0_9_4_BRANCH only in this case. That branch is now being managed by netscape.com for a product release, and it's the PDT's look-out to decide what fixes go in and what do not. The PDT- mark says nothing about whether this bug should be fixed in the Mozilla trunk. It should be fixed if at all possible, so please keep helping with the diagnosis. /be

Errr, yes it was a typo, Alex. I meant to ask if bug 93522 was a dupe, not 93552. Sorry for that.

I am running Win2K (Sp2) using an ASUS V6800 graphics card (GeForce 2) and I do NOT see this with 0.9.4 using the modern theme in either of the following configurations: (a) 1280x1024x32bits - Small Fonts - 96DPI (p2t=15.0) or (b) 1280x1024x32bits - Large Fonts - 120 dpi (p2t=12.0) I used to see it with Build 2001071604 (with the Large Fonts settings) but I have not had a problem since the original fixes for that landed.

I "may" have responded too soon with my comments that I dont see any odd behaviours on my Win2K computer at 1280x1024 using 0.9.4. I am seeing odd behavior in the scroll bar of the newsgroup search window. Is this symptomatic of this bug or is it more related to bug 83289? I will create an attachment.

The display has been really bad on Linux using the modern theme since the new graphite color scheme was added (0.9?) This is true only for XFree86 3.3.6 though. XFree 4.0 and 4.1 have no problem. My graphics card is S3-based (968) so this could be a problem with that driver only.

*** Bug 102360 has been marked as a duplicate of this bug. ***

.

*** Bug 98106 has been marked as a duplicate of this bug. ***

*** Bug 104608 has been marked as a duplicate of this bug. ***

*** Bug 104901 has been marked as a duplicate of this bug. ***

Can somebody affected by this bug please go to bug 105986 and see if they are hit by that one also? If you are hit by this bug but *not* by bug 105986, please leave a comment at bug 105986 saying so.

just my 2 cents: I'd like to say that maybe its hardware combo/resolution/color depth/driver problem with S3 graphics and ATI which both have had bad color problems with certain combinations If I recall: citing: reading several graphics card reviews over the last few years. Can those affected try every possible resolution/color depth/OS driver #? and try new drivers for your card to see if this clears up anything. I'd say its not necessarily a problem in Mozilla but the graphics hardware/software bit of it, if its only happening with one resolution.. please check the settings for each resolution that works and doesn't.. Graphics cards are not perfect, some have some serious issues/drivers didn't fix the problems.. some drivers did fix other cards.. S3 968 is quite old. and its possible no good driver exists for Linux. There are several other bugs reporting misc problems with ATI Rage cards.. like slow scrolling, to name 1. That is all I can offer for now, till we get some feedback on resolution configurations.. -dennis

> I'd say its not necessarily a problem in Mozilla Come on, of all dozens of apps I run on my machine, including graphics apps, Mozilla is the only one to exhibit such a symptom. Of course it only happens on certain combinations of software/hardware. And note that most of Mozilla works fine, only the toolbars, url bar and scrollers are affected. Somebody can find a machine with the symptom and fix it, there is no need to endlessly speculate about possible reasons for that bug without looking at the code.

Mozilla 0.9.6, modern theme, leaves black horizontal marks just above the personal tool bar. It looks as if, the button that gets highlighted when I mouse over the personal toolbar folder, doesn't get "dehighlighted" correctly, leaving a mark. I'm running Windows 2000.

I'm seeing this in Windows 98 using a S3 Savage IX video card (for an IBM Thinkpad T20). This appears in the modern theme but not in the classic theme. It happened occasionally in 0.9.6, but I just installed 0.9.7 and it is happening _much_ more often -- like 50% of the time. Michael

More info: I'm running at 96 DPI and 1024x768, small fonts. I'm also seeing Bug 105986 but only a few extra black lines appear -- nothing as bad as the attachment. My drivers are up to date. It looks like there is some sort of font scaling that is screwing up.

*** Bug 118311 has been marked as a duplicate of this bug. ***

*** Bug 120263 has been marked as a duplicate of this bug. ***

removing PDT grafitti. this one looks like its been duped a bit, and it looks like a good one to get in before 1.0.

Removing nsbeta1 nomination because this bug has been plussed.

Unless this is a different bug, it isn't just "black hashmarks" : looks vaguely like one of the previous sites I visited is showing through in places where the image library has failed to paint the scrollbar

Again, I don't know if this is related to this bug, or attachment 72059 [details], but it appeared at around the same time, to the best of my recollection: The messed up area is painted in a similarly patchy fashion - it was out of the viewable window when I loaded the page, but when I scrolled down, the red areas were only partially painted.

I used to see the black hash marks in the title bar, but I am no longer seeing them, and haven't for a while...

Same here, I don't see those anymore. I updated several drivers on my IBM laptop (including I think the graphics card's) in the meanwhile, but I also switched to the Classic theme for a while so I cannot really correlate.

This looks like it could be another single pixel rounding error. Adding this bug to dependency list of tracking bug 134942.

I'm occasionally getting a black line in a drop down from the personal toolbar, using build 2002041711 (1.0RC1) with small fonts. Is this related, or should I file a seperate bug?

It stopped for a while, not it happens all the time on RC1 (2002041711) in the location entry field. I'm using W2K sp2.

Lowering impact to ADT3, because this dropped off for a while, and only seems to happen "occassionly", now. Suggest we nsbeta1- this one, unless this is heppening in greater frequency. mscott - are you stil seeing this problem?

I still see this nearly all the time, at work and on my (own) laptop as well, but not on my desktop machine at home, which has a higher resolution ( the two machines where I see this have 1400x1050, the desktop has 1600x1200 ). [Debian Xfree86 4.1.0].

I see it happen regularly with mozilla 1.1a on win2k sp2. it happens randomly though.

I experience the pattern-like blocks quite alot, to the extent I almost went back to the classig theme, but then I would not notice when the problem is solved. The problem still exists in the last nightly build 2002062421.

*** Bug 155597 has been marked as a duplicate of this bug. ***

another screenshot showing artifacts in scrollbars. I'm using Orbit theme.

What graphic cards are you people using (all you with problems). I've got access to quite a large range of different hardware/cards but I can only remember seing the problem on the integrated i815 (VGA compatible controller: Intel Corp. 82815 CGC [Chipset Graphics Controller] (rev 2).)

I have an ATI 3D Rage PRO PCI (GT-C2U2), win2k, sp2. memory size: 4mb, driver version 5.0.2184.1, Microsoft Windows 2000 Publisher

*** Bug 161234 has been marked as a duplicate of this bug. ***

We have what I think is a dupe of this bug. One thing people in that bug have in common is S3 Graphics Savage cards. I'll mark the dupe.

*** Bug 137921 has been marked as a duplicate of this bug. ***

*** Bug 169659 has been marked as a duplicate of this bug. ***

The lines on the personal bookmark bar can be reproduced by minimizing and then maximizing the browser. If you mouse over a bookmark, the lines over it dissapear. Also, the lines on the vert. scrollbar can be reproduced by scrolling a few times using the scroll arrows. _Technical specifics_ Browser: Mozilla 1.0.1 (Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020826) Skin: Modern (included w/Mozilla 1.0.1 download) OS: Win2K SP3 Screen resolution 1024 x 768, 32 bit color, small fonts Hardware: IBM ThinkPad T20 (using LCD display) Video adapter: S3 Graphics Savage/IX 1014; S3 SDAC; 8 MB memory; adapter bios 4.02.50.39; PCI bus; driver date 6/14/2002; driver version 5.12.1.7084; MS digitally signed driver

Dale: You may want to try upgrading your video drivers (comment #140), lowering your hardware acceleration a notch, or switching to 24 bit color depth (that last work-around apparently works for some people).

*** Bug 190742 has been marked as a duplicate of this bug. ***

*** Bug 200129 has been marked as a duplicate of this bug. ***

*** Bug 197751 has been marked as a duplicate of this bug. ***

Is this still a bug after 5 years since the last comment? I think this should be long gone now in Gecko 1.9.

Resolving WorksForMe. If you still see this, please reopen.