237766 - background-image gets painted double on link hover

Status: RESOLVED FIXED

(Core :: Layout, defect)

Description

[Martijn Wargers (dead)]

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

Comment 1

[Martijn Wargers (dead)]

Attachment: Double background-image hover testcase

Comment 2

[Martijn Wargers (dead)]

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

Comment 3

[Rene Pronk]

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.

Comment 4

[Boris Zbarsky [:bzbarsky]]

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

Comment 5

[Rene Pronk]

Attachment: Screenshot

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

Comment 6

[Boris Zbarsky [:bzbarsky]]

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

Comment 7

[Rene Pronk]

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.

Comment 8

[Rene Pronk]

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

Comment 9

[Boris Zbarsky [:bzbarsky]]

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...

Comment 10

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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

Comment 11

[Boris Zbarsky [:bzbarsky]]

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

Comment 12

[u116418]

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)

Comment 13

[Teune van Steeg]

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)

Comment 14

[Grey Nicholson (they/them)]

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

Comment 15

[u116418]

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

Comment 16

[Jeremy Hannon]

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?

Comment 17

[Christian Weyland]

screen-resolutions tested:

1280 x 1024 -- WFM
1024 x  768 -- confirmed, seeing double-painting.
 800 x  600 -- WFM

20040427, Win2k, nVidia Geforce 2 MX.

Comment 18

[José Jeria]

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

Comment 19

[Mattias Holmlund]

Attachment: 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.

Comment 20

[Artem Skoretskiy]

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

Comment 21

[:Gavin Sharp [email: [e-mail]]]

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.

Comment 22

[Worcester12345]

(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)

Comment 23

[Martijn Wargers (dead)]

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?

Comment 24

[Worcester12345]

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?

Comment 25

[Ryan VanderMeulen [:RyanVM]]

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

Comment 26

[Oakwine]

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. 

Comment 27

[Worcester12345]

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

Comment 28

[Gordon]

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

Comment 29

[Gordon]

Attachment: Another testcase, slightly different

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

Comment 30

[Gordon]

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>

Comment 31

[Gordon]

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+

Comment 32

[Gordon]

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.

Comment 33

[Martijn Wargers (dead)]

Attachment: image for yet another testcase

Comment 34

[Martijn Wargers (dead)]

Attachment: yet another testcase

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.

Comment 35

[Stephen Deken]

Attachment: tall red block, 16x100 pixels

For following testcase

Comment 36

[Stephen Deken]

Attachment: detailed 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 37

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Comment on attachment 155956 [details]
detailed testcase

What am I supposed to see on this testcase, and what actually happens instead?

Comment 38

[Robert O'Callahan (:roc) (email my personal email if necessary)]

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

Comment 39

[Martijn Wargers (dead)]

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). 

Comment 40

[Worcester12345]

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.

Comment 41

[Robert O'Callahan (:roc) (email my personal email if necessary)]

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.

Comment 42

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Attachment: patch

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

Comment 43

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Comment on attachment 156364 [details] [diff] [review]
patch

might want to add an assertion in nsImageWin::DrawTile that the rect is
nonempty...

Comment 44

[Tom Kiss]

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>

Comment 45

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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

Comment 46

[José Jeria]

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

Comment 47

[Worcester12345]

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.

Comment 48

[u81239]

This seems to fix depending bug 235390 as well.

Comment 49

[Worcester12345]

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

Comment 50

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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.

Comment 51

[Robert O'Callahan (:roc) (email my personal email if necessary)]

agreed

Comment 52

[Asa Dotzler [:asa]]

Comment on attachment 156364 [details] [diff] [review]
patch

a=asa for branch checkin.

Comment 53

[Asa Dotzler [:asa]]

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.

Comment 54

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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.

Comment 55

[Henrik Skupin [:whimboo][⌚️UTC+2]]

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

Comment 56

[Jonathan Griffin (:jgriffin)]

Attachment: invalidate reftest

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 57

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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.

Comment 58

[Jonathan Griffin (:jgriffin)]

Attachment: invalidate reftest v2

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.

Comment 59

[Jonathan Griffin (:jgriffin)]

Attachment: invalidate reftest v3

Oops, attached wrong patch above.

Comment 60

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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.

Comment 61

[Jonathan Griffin (:jgriffin)]

Attachment: invalidate reftest v4

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.

Comment 62

[Jonathan Griffin (:jgriffin)]

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