User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7b) Gecko/20040309 Firefox/0.8.0+ Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7b) Gecko/20040309 Firefox/0.8.0+ See testcase coming up. When you hover on one of the links, the background-image gets painted double. This only happens including this css code: ul#sections { list-style: none; margin: 0.2em; padding: 0.2em; } For small em/% (<0.3em/<4%) values of margin and paddings it happens, otherwise not. Reproducible: Always Steps to Reproduce: 1.visit testcase 2.Hover over links 3. Actual Results: Background-image gets painted double. Expected Results: No double-painting

Forgot to mention, it happens with a:hover changing css property: color, text-decoration. Happens not with: border

Confirming with Firefox 0.8 The testcase has some odd properties. For me it only happens if the padding-left is 1em, not any other value, and when the padding is set to 0% and the margin is somewhere between 0.9% en 6%. If the padding changes then the margin range in which it occurs also changes.

Rene, what OS is that on? Could someone post a screenshot of the incorrect rendering?

That's under WinXP. As soons as you hover over the link Mozilla draw the folder under the text.

Hmm.. is this due to the differences in how we invalidate on Linux and Windows? I'm not seeing this on Linux...

Fonts may have something to do with it: If I change the font size from 12pt to any other size, the problem disappears. Perhaps given the right font and the right size you might see it as well under Linux. Furthermore, I noticed that it only occurs if the sum of the ul margin and the ul padding is somewhere between approx 2.0 and 6.9 or between 9.0 and 17.0. Perhaps there are more ranges for which it occurs, I haven't tried. I also noticed that when the problem occurs the 'original' image is slightly displaced: the y pos of the image is 1 less when it occurs compared to when it doesn't.

Furthermore, it depends on the size of the image. Here it happens in the following cases: - image 16x16 and font-size 12pt - image 24x24 and font-size 18pt - image 32x32 and font-size 24pt

Tried a bunch of those possibilities, and still no go on Linux, so this does look like it depends on the smaller amount of invalidation we do on Windows...

You can test the Windows-style invalidation with: http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/widget/src/gtk/nsWindow.cpp&rev=1.420&mark=828#825

Hmm... yeah, changing that define doesn't make the bug appear either. :(

I am not seeing this problem at all. Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7b) Gecko/20040414 Firehawk/0.8.0+ (Lohvarn)

On screen resolution 1280*1024*32 there's no problem with the images, but on screen resolution 1024*768*32 however, images are doubled. WinME, Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.8a) Gecko/20040427 Firefox/0.8.0+ (MOOX)

WFM WinXP Home, Firefox 20040411, default font family sans-serif

Just tried 1024x768 and 1280x1024 from 1400x1050, no problems either.

I can see the problem in the testcase with: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7b) Gecko/20040410 Firefox/0.8 Maybe this was fixed with a different patch in later nightlies?

screen-resolutions tested: 1280 x 1024 -- WFM 1024 x 768 -- confirmed, seeing double-painting. 800 x 600 -- WFM 20040427, Win2k, nVidia Geforce 2 MX.

No need to change screen resolution to see this bug, just trying resizing the window, making it smaller, and you will eventually see the bug in action. Windows XP, rv:1.8a, Gecko/20040508

For me, this bug is visible in the Release-notes document for Mozilla. See for example http://www.mozilla.org/releases/mozilla1.7rc2/README.html The list-items under "Browser" render correctly initially, but if I select an entire line (triple-click) and then click somewhere else on the page, the arrow for the list item is rendered twice in the same way as in the supplied test-case. I'm running Firefox 0.8 on Windows NT4.0SP6, 1280x1024.

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

I am experiencing this bug with the latest AVIARY branch build of Firefox (0524), on both win98 and winXP. Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.7) Gecko/20040524 Firefox/0.8.0+ I resize the window randomly, and eventually the image get painted double on mouseover.

(In reply to comment #19) > Created an attachment (id=148717) > Rendering of Mozilla Release-notes after selecting and un-selecting line > > For me, this bug is visible in the Release-notes document for Mozilla. See for > example http://www.mozilla.org/releases/mozilla1.7rc2/README.html The > list-items under "Browser" render correctly initially, but if I select an > entire line (triple-click) and then click somewhere else on the page, the arrow > for the list item is rendered twice in the same way as in the supplied > test-case. I'm running Firefox 0.8 on Windows NT4.0SP6, 1280x1024. I am getting this as well. Getting it with this version: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040609 Firefox/0.8.0+ (bangbang023)

Not sure if this is useful, but: I don't see the bug in: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 But I see the bug in: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5a) Gecko/20030718 Searched with bonsai --> maybe bug 212723 has got something to do with it?

Still seeing this in Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040624 Firefox/0.9.0+ (bangbang023) and in yesterday's Mozilla Browser Seamonkey Suite product (trunk and branch). Should this be marked as a blocker for Firefox 1.0 and corresponding Mozilla Browser Seamonkey Suite release?

Not seeing it here. Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040713 Firefox/0.9.1+ WinXP SP2 RC2 (build 2149) 1280x960x32

Previously, I could not reproduce this bug on WinXP. Today, I changed the theme from Windows Classic Style to Windows XP Style, and now I can reproduce the bug. Hope this helps to narrow it down.

Was hoping to see this fixed soon. Haven't checked here in a while.

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

Hopefully another testcase that's slightly different will give more insight.

Comment on attachment 154770 [details] Another testcase, slightly different ><!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"> ><HTML><HEAD> ><STYLE type="text/css"> >#test {position: absolute; right: 0; padding-left: 16px; background: >url(http://www.mozilla.org/images/ico-win.png) bottom left no-repeat} >span {padding: 0 7.2px} >span:hover {border-bottom-width: 1px} ></STYLE></HEAD> > ><BODY> ><DIV id="test"> > <SPAN>test1</SPAN><SPAN>test2</SPAN> ></DIV> ></BODY></HTML>

I previously thought that a separator with a "display: none" rule was needed between "test1" and "test2" to make the glitch appear, but I now see that it's not necessary. The version in the comment above will work just the same (no <B>|</B> between the spans - corresponding CSS removed). Anyway, the glitch appears for me at 1152x864x32 at any text size I've tried so far. WinXP Pro SP1 (build 2600) Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a3) Gecko/20040729 Firefox/0.9.1+

A few more insights... It seems that any rule set for "span:hover" that requires the background to be redrawn has the potential to trigger the double image, such as a color or background-color. Even a change in font size (font-size: x-large) will do it, but you have to move the mouse back and forth between the words, and the second image disappears when the mouse is moved away from the span. Having only a rule that has nothing to do with graphics, such as "azimuth", doesn't cause the glitch. If no "span:hover" rules are declared, then, similar to bug 235390, selecting the words and then de-selecting will cause the effect, but only if I double-click. Selecting by dragging or Ctrl+A doesn't do it. Very odd.

Another testcase, because this seems to have some different peculiarities. This is a testcase from http://www.saleserrors.com/ . Hovering over the circles there causes the background duplication. A scrollbar in the document seems to be necessary to trigger the bug. But this testcase bug seems also very dependant on the resolution/window size 1024*768 triggers the bug, but with any other window size, I don't see the bug.

For following testcase

This testcase shows how the subpixel position of the background image affects the duplicated background. Only when the background position has a fractional component < .5 does this bug occur. Note that it affects two divs in each testcase which are aligned on-pixel. This bug also depends on the top of the div being next to the first copy of the background image. If the background image used has a height of 100px, no div aligned with a top > 100px will be able to trigger the behavior. Any image will work as long as it meets that requirement. I feel like I'm not explaining myself very clearly, so I'll just submit and let the testcase talk for itself.

Comment on attachment 155956 [details] detailed testcase What am I supposed to see on this testcase, and what actually happens instead?

Does this bug depend on DPI settings? People who see this bug --- does changing your DPI settings make it appear/go away?

No, that doesn't seem to matter at all. I tried three different dpi settings: 72dpi, 100dpi and 116dpi (my default is 96 dpi). All testcases still exhibit the double paint bug after changing the dpi setting (and restarting the browser in order to activate the changed dpi setting).

You can practice creating the bug's effects by going to to the example page referenced in comment #19. Just go to that page and select and unselect the text a bunch of times. The arrows will pop up sure as sugar.

We need someone with a Windows box to do some debugging here. We need to look at the parameters being passed from nsCSSRendering::PaintBackground to nsRenderingContextWin::DrawTile to the nsImageWin::DrawTile that paints the image incorrectly.

The Windows DrawTile function does something weird when given a width of 0, but why not make this case faster cross-platform?

Comment on attachment 156364 [details] [diff] [review] patch might want to add an assertion in nsImageWin::DrawTile that the rect is nonempty...

I've been having this problem, with an <a href> inside a series of nested <div>s. The <a href>s parent <div> has a CSS background-image applied, and on mouseover the <a href> duplicated the image within the <a href>. Strangely, having read this I can see that this only happens when the browser is on full-screen. Another way I found to eliminate this is was to remove the CSS width attribute from the second root parent <div>. If that makes sense, its that one, quite a way back from the location of the problem. <body><div><DIV>

Fix checked in to trunk, 2004-08-19 14:58 -0700.

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

I was all excited to see this one fixed, but it looks like it is now only in the trunk. Still seeing this on the mozilla release notes with this version: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040823 Firefox/0.9.1+ (bangbang023) Thanks.

This seems to fix depending bug 235390 as well.

How does one make this bug hit Firefox "Aviary" branch as well? Or should a new bug be started? Thanks.

Comment on attachment 156364 [details] [diff] [review] patch This is a really simple fix to a somewhat high-visibility bug, so I'm willing to land it on aviary / 1.7.

agreed

Comment on attachment 156364 [details] [diff] [review] patch a=asa for branch checkin.

We're not going to hold the release for this so the blocking flag has been set to "-" but it has been approved to land on the aviary and 1.7.x branches. If the bug assignee thinks this fix belongs on those branches, he is free to check it in there up until the PR.

Fix checked in to AVIARY_1_0_20040515_BRANCH, 2004-09-08 14:14 -0700. Fix checked in to MOZILLA_1_7_BRANCH, 2004-09-08 14:15 -0700.

With the fix on bug 471365 we can handle invalidation issues now. Asking for in-testsuite based on bug 451332 comment 8.

This test can manually reproduce the problem on the original build reported in this bug by adding: <body onload="setTimeout(doTest, 1000)"> Test passes on trunk.

Comment on attachment 384993 [details] [diff] [review] invalidate reftest I see two problems here: 1) Reftests shouldn't rely on the network. You should rely on an image in the source tree rather than one off www.mozilla.org. 2) it's not clear to me why you have a span:hover rule. Couldn't that change the behavior of the test if the mouse is over it while it's running? (Though I don't think that can happen currently, it still seems worth avoiding.) Other than that, this seems fine.

Thanks for the review. I've removed the :hover styles, replaced the image with one in the tree, and verified that the test HTML can still reproduce the bug on this build: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7b) Gecko/20040302 Firefox/0.8.0+ I've also moved the test out of the /bugs directory and into /backgrounds.

Oops, attached wrong patch above.

Comment on attachment 387960 [details] [diff] [review] invalidate reftest v3 >diff --git a/layout/reftests/backgrounds/background-redraw-1-ref.html b/layout/reftests/backgrounds/background-redraw-1-ref.html I actually think at least using the bug number as the filename is better in this case (although putting it in reftests/backgrounds is ok). I think it's more appropriate to use the bug number because this test isn't part of a set of tests written to ensure that we support redrawing backgrounds correctly; it's just a test to make sure the exact case in this bug doesn't regress. (Though, actually, maybe background-redraw-237766 would be appropriate, but I don't think background-redraw-1 is.) >+// in case the MozReftestInvalidate event isn't supported >+setTimeout(doTest, 5000); Why bother adding this? We support MozReftestInvalidate. r=dbaron with those fixed Sorry for the delay in getting to this.

Renamed test per comment #60 to background-redraw-237766. >>+// in case the MozReftestInvalidate event isn't supported >>+setTimeout(doTest, 5000); > >Why bother adding this? We support MozReftestInvalidate. This construct is from a suggestion from longsonr, see comment #12 in bug 467472. It's useful in this case to verify that the test case reproduces the bug on the original build reported in the bug, which is from 2004 and does not support MozReftestInvalidate.

Pushed test as http://hg.mozilla.org/mozilla-central/rev/20a5a5f15675