User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/535.19 (KHTML, like Gecko) Chrome/18.0.1025.162 Safari/535.19 Steps to reproduce: Reduced the issue I was having to this test case: http://jsfiddle.net/una3y/ Actual results: Firefox 12 renders this differently to all other browsers, including older versions of Firefox

Confirmed on http://hg.mozilla.org/mozilla-central/rev/cc5254f9825f Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120426 Firefox/15.0a1 ID:20120426030504 And gfx.canvas.azure.enabled = false helps. Regression window(m-c): Works: http://hg.mozilla.org/mozilla-central/rev/450e4d9ea2d5 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0a1) Gecko/20110624 Firefox/7.0a1 ID:20110625025936 Fails: http://hg.mozilla.org/mozilla-central/rev/48ad4ffc4230 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0a1) Gecko/20110625 Firefox/7.0a1 ID:20110625030821 Pushlog: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=450e4d9ea2d5&tochange=48ad4ffc4230 Regression window(m-i): Works: http://hg.mozilla.org/integration/mozilla-inbound/rev/c65f1fb0449d Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0a1) Gecko/20110624 Firefox/7.0a1 ID:20110624094307 Fails: http://hg.mozilla.org/integration/mozilla-inbound/rev/46c3d095bc75 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0a1) Gecko/20110624 Firefox/7.0a1 ID:20110624104626 Pushlog: http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=c65f1fb0449d&tochange=46c3d095bc75 Regressed by: Bug 651858

Adding an extra ctx.stroke() fixes this for now: http://jsfiddle.net/una3y/1/

So the problem here is that ::EnsureWritablePath will create a device space path builder. But it will never mark mPathTransformWillUpdate false to indicate the changing transform (caused by the restore) has been dealt with. This patch fixes that, reftest incoming.

Need to get this regression fix everywhere.

https://hg.mozilla.org/integration/mozilla-inbound/rev/877276e291b8 https://hg.mozilla.org/integration/mozilla-inbound/rev/5abd27624d84

https://hg.mozilla.org/mozilla-central/rev/5abd27624d84 https://hg.mozilla.org/mozilla-central/rev/877276e291b8

It's not yet clear whether this would be a ride along for a FF12 chemspill - we'll evaluate at that time. We should, however, get this fix on Aurora and Beta already.

(In reply to Robert O'Callahan (:roc) (Mozilla Corporation) from comment #5) > Need to get this regression fix everywhere. Actually, can we have more insight into why you feel this regression from FF7 needs to land on all branches?

Because Web compatibility breakage regressions are really bad?

(In reply to Robert O'Callahan (:roc) (Mozilla Corporation) from comment #10) > Because Web compatibility breakage regressions are really bad? Yes, they're bad. But "Need to get this regression fix everywhere" implies urgency undue to a regression this old. We'll evaluate risk/reward when the fix is ready.

The fix has already landed on mozilla-central. What else are we waiting for?

Comment on attachment 618920 [details] [diff] [review] Properly mark mPathTransformWillUpdate false [Approval Request Comment] Regression caused by (bug #): User impact if declined: Testing completed (on m-c, etc.): Risk to taking this patch (and alternatives if risky): String changes made by this patch:

(In reply to Bas Schouten (:bas) from comment #13) > Comment on attachment 618920 [details] [diff] [review] > Properly mark mPathTransformWillUpdate false > > [Approval Request Comment] > Regression caused by (bug #): Bug 651858 > User impact if declined: Canvas rendering incorrect > Testing completed (on m-c, etc.): Landed on m-c > Risk to taking this patch (and alternatives if risky): Low risk - I don't see any serious risks. > String changes made by this patch: None

Comment on attachment 618921 [details] [diff] [review] Add reftest for path continuation after transform changes If we uplift the patch we might want to uplift the test as well, not sure what the policy is there.

Comment on attachment 618920 [details] [diff] [review] Properly mark mPathTransformWillUpdate false [Triage Comment] Given the risk evaluation, approving the fix for this regression for both Aurora 14 and Beta 13. If we see any regressions over the next 3 weeks, we'll be quick to back this out (although that's unexpected).

I will land this.

https://hg.mozilla.org/releases/mozilla-aurora/rev/046f1d37eea0 https://hg.mozilla.org/releases/mozilla-aurora/rev/8f5e65a6d540 https://hg.mozilla.org/releases/mozilla-beta/rev/935ca7392a0c https://hg.mozilla.org/releases/mozilla-beta/rev/7ed8711c7249

The automated test for this bug passed on all OSs on Firefox 13.0 beta: https://tbpl.mozilla.org/php/getParsedLog.php?id=12159689&full=1&branch=mozilla-beta https://tbpl.mozilla.org/php/getParsedLog.php?id=12163243&full=1&branch=mozilla-beta https://tbpl.mozilla.org/php/getParsedLog.php?id=12164769&full=1&branch=mozilla-beta I have also tried to verify this fix manually but I got the same image rendered on: IE9 Chrome 19.0.1084.46 Firefox 11.0 Firefox 12.0 Firefox 13.0 beta 6. If anyone can reproduce this issue on pre-fix builds, please try to verify this issue manually.

Alice, would you mind confirming if this is fixed for you? It seems we have inconsistent results as per comment 19.

I can reproduce the Issue in http://hg.mozilla.org/releases/mozilla-release/rev/a294a5b4f12d Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20100101 Firefox/12.0 ID:20120420145725 I cannot Reproduce anymore in http://hg.mozilla.org/releases/mozilla-beta/rev/5de6e4bd8ede Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20100101 Firefox/13.0 ID:20120523114940 http://hg.mozilla.org/releases/mozilla-aurora/rev/89176b6d643c Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120530 Firefox/14.0a2 ID:20120530042008 http://hg.mozilla.org/mozilla-central/rev/65fa5cb6f79c Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/15.0 Firefox/15.0a1 ID:20120530030519

Thanks a lot, Alice!