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)
Tracking
()
NEW
People
(Reporter: myk, Unassigned)
References
Details
(Keywords: testcase)
Attachments
(1 file)
1.86 KB,
application/vnd.mozilla.xul+xml
|
Details |
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.
Reporter | ||
Comment 1•18 years ago
|
||
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.
Comment 2•18 years ago
|
||
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
Comment 3•18 years ago
|
||
Yeah, I see this with a non-cairo trunk build...
Comment 4•18 years ago
|
||
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).
Reporter | ||
Comment 5•18 years ago
|
||
(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.
Comment 6•18 years ago
|
||
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.
Comment 7•18 years ago
|
||
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.
Comment 8•18 years ago
|
||
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
Comment 9•18 years ago
|
||
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.
Assignee: jdunn → nobody
Updated•6 years ago
|
Product: Core → Core Graveyard
Updated•6 years ago
|
Product: Core Graveyard → Core
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•