Closed Bug 237766 Opened 19 years ago Closed 18 years ago

background-image gets painted double on link hover

Categories

(Core :: Layout, defect)

x86
Windows 2000
defect
Not set
normal

Tracking

()

RESOLVED FIXED

People

(Reporter: martijn.martijn, Assigned: dbaron)

References

Details

(Keywords: fixed-aviary1.0, fixed1.7.5, qawanted, Whiteboard: [patch])

Attachments

(10 files, 3 obsolete files)

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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Rene, what OS is that on?  Could someone post a screenshot of the incorrect
rendering?
Keywords: qawanted
Attached image Screenshot
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...
Hmm... yeah, changing that define doesn't make the bug appear either.  :(
Blocks: 241851
Blocks: 235390
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.
Flags: blocking1.8a3?
Attached file 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.
For following testcase
Attached file 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 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.
Attached patch patchSplinter Review
The Windows DrawTile function does something weird when given a width of 0, but
why not make this case faster cross-platform?
Attachment #156364 - Flags: superreview?(roc)
Attachment #156364 - Flags: review?(roc)
Assignee: nobody → dbaron
Whiteboard: [patch]
Comment on attachment 156364 [details] [diff] [review]
patch

might want to add an assertion in nsImageWin::DrawTile that the rect is
nonempty...
Attachment #156364 - Flags: superreview?(roc)
Attachment #156364 - Flags: superreview+
Attachment #156364 - Flags: review?(roc)
Attachment #156364 - Flags: review+
Flags: blocking1.8a3? → blocking1.8a3-
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.
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → FIXED
Flags: blocking-aviary1.0PR?
Whiteboard: [patch] → [patch] needed-aviary1.0?
*** 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.
Flags: blocking-aviary1.0?
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.
Attachment #156364 - Flags: approval1.7.3?
Attachment #156364 - Flags: approval-aviary?
Comment on attachment 156364 [details] [diff] [review]
patch

a=asa for branch checkin.
Attachment #156364 - Flags: approval1.7.x?
Attachment #156364 - Flags: approval1.7.x+
Attachment #156364 - Flags: approval-aviary?
Attachment #156364 - Flags: approval-aviary+
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.
Flags: blocking-aviary1.0PR?
Flags: blocking-aviary1.0PR-
Flags: blocking-aviary1.0?
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.
Whiteboard: [patch] needed-aviary1.0? → [patch]
Depends on: 451332
With the fix on bug 471365 we can handle invalidation issues now. Asking for in-testsuite based on bug 451332 comment 8.
Flags: in-testsuite?
Attached patch invalidate reftest (obsolete) — Splinter Review
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.
Attachment #384993 - Flags: review?(dbaron)
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.
Attachment #384993 - Flags: review?(dbaron) → review-
Attached patch invalidate reftest v2 (obsolete) — Splinter Review
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.
Attachment #384993 - Attachment is obsolete: true
Attachment #387959 - Flags: review?(dbaron)
Attached patch invalidate reftest v3 (obsolete) — Splinter Review
Oops, attached wrong patch above.
Attachment #387959 - Attachment is obsolete: true
Attachment #387960 - Flags: review?(dbaron)
Attachment #387959 - Flags: review?(dbaron)
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.
Attachment #387960 - Flags: review?(dbaron) → review+
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.
Attachment #387960 - Attachment is obsolete: true
Flags: in-testsuite? → in-testsuite+
You need to log in before you can comment on or make changes to this bug.