Open Bug 351764 Opened 18 years ago Updated 2 years ago

Image region changes color when flexed

Categories

(Core :: Layout: Images, Video, and HTML Frames, defect)

1.8 Branch
x86
Linux
defect

Tracking

()

People

(Reporter: myk, Unassigned)

References

Details

(Keywords: testcase)

Attachments

(1 file)

When a certain image is included in a XUL file via a XUL "image" tag and the CSS "list-style-image" and "-moz-image-region" properties, and the image tag is flexed in order to stretch the image, then the appearance of the image changes.  Most of it becomes white, although one pixel in the image stays the same color.

This is affecting theme changes in Firefox 2 that make the Go and Search buttons, among other elements, stretch to accommodate the size of their corresponding Location and Search textboxes.  See bug 347616 and bug 348138.

Testcase coming up.
Here's a simple testcase which demonstrates the problem.  It's a XUL file with embedded CSS which references an image in a data: URL.
Blocks: 351618
So I found when this got fixed on trunk. Unfortunately, I think it was fixed by enabling cairo on Linux, since that happened during the range I found.

http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=PhoenixTinderbox&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2006-04-06+03&maxdate=2006-04-07+05&cvsroot=%2Fcvsroot

Can anyone using non-cairo trunk say whether this still occurs?
Summary: image region changes color when flexed → Image region changes color when flexed
Yeah, I see this with a non-cairo trunk build...
Well if you thought that was bad, the GTK1 gfx code can only stretch an image starting from the top-left corner, effectively moving the region to (0, 0).
Keywords: testcase
(In reply to comment #4)
> Well if you thought that was bad, the GTK1 gfx code can only stretch an image
> starting from the top-left corner, effectively moving the region to (0, 0).

I'm compiling against GTK2.  Does it have the same problem?  If so, that could explain this bug, since the first row of the image has a bunch of white pixels.
GTK1 and GTK2 use the same image scaling code last I checked.  And it's badly broken; this is a known problem.  See the XXX comments in nsImageFrame.cpp where we don't intersect dirty rects with the image bounds because doing so causes completely busted rendering.
Hmm.  Anyone know how hard this would be to fix?  If it's not easy + safe, we'll need to modify our solutionsn for a couple of Firefox 2 bugs to not trigger this.  My guess is that fixing this bug is way too risky for Firefox 2.
So the original bug I filed on this is bug 254659.  See in particular bug 254659 comment 3 and bug 254659 comments 7 and 8.
Depends on: 254659
OK, bug 254659 comment 8 makes it pretty clear that this will not be fixed for 1.8.  So on the branch we'll need to adjust our solution for these buttons.
Product: Core → Core Graveyard
Product: Core Graveyard → Core
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: