User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8.1b1) Gecko/20060804 BonEcho/2.0b1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8.1b1) Gecko/20060804 BonEcho/2.0b1
In 1.8.1: When drawing an image, and then creating a path which is not an integer-aligned rectangle and then setting it as the clipping path, it actually ends up with the clipping path being (as far as I can tell) the intersection of that path and the image's destination rectangle. (The image shouldn't affect the clipping path.)
This has regressed somewhere between "Gecko/20060728 Firefox/22.214.171.124" and "Gecko/20060710 Firefox/2.0b1". It still fails in the latest 1.8 branch (with the checkin from bug 346421). It does work in "Gecko/20060804 Minefield/3.0a1" (from just before that checkin).
(This is affecting the canvas-using program I'm working on, and I can't think of any particularly nice workaround. I'm actually clipping to a non-rectangular polygon, so I can't just round it to integer coordinates. I suppose I could draw a zero-sized rectangle before the clip path and after the image, which does seem to fix it but doesn't seem like an entirely elegant solution...)
Steps to Reproduce:
1. See test case.
There is a black canvas, with a gradient image in the top left corner, and a green rectangle in the bottom right corner of that image (not extending into the black region).
The green rectangle should be extending outside the image, and should appear centred on the canvas.
Created attachment 232227 [details]
Ugh. I'll try to fix, but the underlying bug is a pain.. maybe i'll just turn on the workaround on the branch as well.
A non-obvious js-level workaround is to put:
after the drawImage() call. I'll see if I can make this unnecessary.
This WFM on trunk, and I assume we're not going to be making any branch changes.