289943 - Scaled image not correctly restored after leaving :hover

Status: RESOLVED FIXED

(Core :: Web Painting, defect)

Description

[Rob Janssen]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b) Gecko/20050217
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b) Gecko/20050217

See the demo URL.  Hover over the 3 large squares on the left, which causes a
menu to pop-up (created with CSS :hover, always nice to impress IE fans).
When leaving one menu, the underlying image is not correctly restored.
Other pages on the same site, where there is no image map on the covered image,
show no problem.
Works OK in 1.7.6, broken in 1.8b.

Reproducible: Always

Steps to Reproduce:

Comment 1

[Rob Janssen]

Attachment: Screenshot showing the problem

Comment 2

[Andrew Schultz]

Attachment: testcase

this testcase exhibits the bug for me with current CVS/gtk2.  On load, "bar"
appears inside the image with a white background (should be orange).  After
covering up the white background area and exposing it, it looks fine (orange
background).

Comment 3

[Andrew Schultz]

FWIW, this WORKSFORME with a gtk1 build
oh, and the image is scaled by a pixel.  The bug doesn't show up if it's not scaled.

==> views (?)

Comment 4

[Andrew Schultz]

Attachment: testcase v2

oops.  img should actually point at a valid image.

Comment 5

[Rob Janssen]

(In reply to comment #3)
> FWIW, this WORKSFORME with a gtk1 build
> oh, and the image is scaled by a pixel.  The bug doesn't show up if it's not
scaled.
> 
> ==> views (?)

Thanks for finding that!  I had done many comparisons between pages on the site
and found only the presence of a map as a factor causing this bug.
But now it actually turns out to be not because of the map but because of the
scaling.  When I set the picture size correctly on the original site, it works OK.

Changing the summary.  Removing reference to original site (as it will be
fixed).  Attachment "testcase v2" still shows the problem.

Comment 6

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

Attachment: fix

The XlibStretchRect code has some problems. When startColumn is nonzero and
we're only stretching horizontally, we get into trouble because
XlibStretchHorizontal uses "x1 - startColumn + offsetX" as the destination x
coordinate (where x1 is the offset within the image after scaling). It should
be using just x1 + offsetX. So I've pulled the -startColumn part out to the
caller for use just in the stretchVertical case, where it is needed. There's a
similar issue with the vertical coordinate used. Also, the !skipVertical code
doesn't handle dstOrigX correctly, so I fixed that too.

Comment 7

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

Comment on attachment 180551 [details] [diff] [review]
fix

fairly straightforward fix to some fairly broken GTK1/2 image stretching code.
This could fix a variety of bugs.

Comment 8

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

checked in