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/188.8.131.52" 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...) Reproducible: Always Steps to Reproduce: 1. See test case. Actual Results: 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). Expected Results: The green rectangle should be extending outside the image, and should appear centred on the canvas.
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: ctx.beginPath(); ctx.rect(0,0,0,0); ctx.fill(); 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.