661452 - Setting HTML5 canvas context scale to 0 stops future canvas updates

Status: UNCONFIRMED

(Core :: Graphics: Canvas2D, defect)

Description

[Brian Nickel]

User-Agent:       Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0.1) Gecko/20100101 Firefox/4.0.1
Build Identifier: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0.1) Gecko/20100101 Firefox/4.0.1

I frequently use transforms when drawing to the canvas element.  Sometimes I will do the following:
   ctx.save();
   ctx.scale(fraction);
   ...
   ctx.restore();

If fraction is set to zero, Firefox will fail to render any future updates.  No error appears in the console and the code continues to execute as expected.

Reproducible: Always

Steps to Reproduce:
1. Open the attached HTML file in FF4.
2. Click 100%, 20%, 0%, 30%.
3. Click any other percents you feel like.

Actual Results:  
After 2: Beige rectangle inside a red rectangle.
After 3: Updates on other clicks.

Expected Results:  
After 2: Coral rectangle inside red rectangle.
After 3: No canvas updates occur.

Obvious workaround while this is fixed is to wrap code in if(fraction != 0) {}.  Chrome handles this fine.  Don't know what the specification says.

Comment 1

[Brian Nickel]

Attachment: Testcase

Comment 2

[Joseph Lenton]

Confirmed for me in FireFox 6 on Windows 7. I can reproduce it every time, perfectly.

User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:6.0) Gecko/20100101 Firefox/6.0

When it hits the canvas stops working, entirely, and is unusable until it's size is adjusted or is replaced with a new canvas.

If you want cross-browser behaviour, then the workarounds to this are non-trivial.

First workaround is to wrap the call to scale the canvas, and check if the x or y is 0. If so then avoid the call, and instead avoid any future drawing calls until the canvas matrix has been changed (i.e. setTransform, reset or changing the canvas' size). This requires tracking that drawing is disabled, and making checks in all places where you draw to the canvas, which adds minor overhead.

Another workaround is to store the canvas 2D context state, reset the canvas width, and then set the stored stated back to the canvas. This works, if you have not drawn to it.

If you have drawn to it, then you can draw the canvas to another canvas first, data and then draw it back after you have altered the width.

IE 9 and Chrome 15 are not affected by this.

Comment 3

[Mike Rooney]

Confirmed as well on Firefox 6 / Vista and Firefox 6 / OSX 10.7. An easier work-around that should behave mostly as expected is to set the scale to scale || 0.001.

Comment 4

[Wei-ju Wu]

Just stumbled upon this bug, happens on Firefox 8 and 8.01 as well.

Comment 5

[Joseph Lenton]

This no longer happens to me on Firefox 9.0.1 on Windows 7. Both my own test, and the test case provided, work fine.

Looks like it's been fixed.

Comment 6

[Rich Hauck]

This bug is still active for me running Firefox 10.0.2 Mac OSX Lion. I came across it when my animation wouldn't play in Firefox. I solved it by resetting 0 to 0.01, then found this page. Some further documentation on my blog: http://www.mandalatv.net/2012/03/flying-x-experimenting-with-oop-javascript/

Comment 7

[admin]

I still have this on Windows 7 FF 16.0.2.

I also experience the bug if doing a shearing transform with 		context.transform(1,1,1,1,0,0); (or shearing variations thereof)

The scaling solution of setting 0 to 0.01 is sufficient for scaling but I haven't figured out an equivalent for shearing or other arbitrary transforms. So if you are a matrix wizard, please tell me how to detect if a transformation will turn its source rectangle into a 0-width sliver.

Comment 8

[Alex Prokop]

This is still happening on Windows 7 FF 20.0.1. I can confirm that it doesn't occur on Mac OS X 10.8.3

Comment 9

[beeender]

This still happens to my LINUX firefox 21.0

Comment 10

[nicholas.rd.fraser]

I can confirm this with Firefox Linux Nightly 26.0a1 2013-09-16 running on Fedora 14. With the attached test case, as soon as I click 0% the browser starts behaving strangely, having trouble repainting the page at all (alert dialog looks broken, page flashes white, text disappears, selecting it makes it appear again, etc.)

 Graphics
Adapter Description	GLXtest process failed (exited with status 1): No visuals found
GPU Accelerated Windows	0/1 Basic Blocked for your graphics driver version. Try updating your graphics driver to version <Anything with EXT_texture_from_pixmap support> or newer.
WebGL Renderer	Blocked for your graphics card because of unresolved driver issues.
windowLayerManagerRemote	false
AzureCanvasBackend	cairo
AzureContentBackend	none
AzureFallbackCanvasBackend	none
AzureSkiaAccelerated	0

Comment 11

[bernhard.robert.pichler]

It would be great if this could be fixed. This bug is more than 2 years old. I don't see this behavior on Windows 7, but on Ubuntu and other Linux distributions. 

I use the context.setTransform(a,b,c,d,tx,ty) function. 
As soon as a,b,c,d are zero the Canvas element stops rendering.
All other browsers are running fine.

Comment 12

[Thomas Darimont]

This still happens with firefox 37.0.1 on linux.

Comment 14

[joao.r.matos]

Duplicate of this bug:985261

Comment 16

[joao.r.matos]

I CAN REPRODUCE this with the following configurations:

CONFIGURATION 1:
Firefox 37.0.2 for GNU/Linux x86_64 (Mozilla build, self-updated from previous .tar.gz versions)
Debian GNU/Linux 7.8 amd64 ("Wheezy")
Graphics hardware: NVIDIA GT216 (PCI Class 0300: Device 10de:0a20 (rev a2))
Graphics driver: NVIDIA GLX 304.125 (proprietary NVIDIA drivers from Debian's non-free for Wheezy)
Linux: 3.16.0-0.bpo.4-amd64 (from wheezy-backports)

CONFIGURATION 2:
Iceweasel 31.6.0 (Debian build)
Debian GNU/Linux 8.0 amd64 ("Jessie")
Graphics hardware: Intel GM965/GL960 Integrated Graphics (PCI Class 0300: Device 8086:2a02 (rev 03))
Graphics driver: i915
Linux: 3.16.0-4-amd64 (from jessie)

I CAN NOT REPRODUCE this with Firefox for Android, on a 1st gen Nexus 7 (Tegra 3).

I haven't tested any other configurations with Firefox.