I should mention, when the behavior is exhibited, it isn't clear that the callback will ever be called. As far as I can tell, no progress is being made and toBlob() has stalled completely.

I tried this in 50.0.2624.0, which should be a version slightly before the first .toBlob change landed in January (7ef3a3a242885e3ba1bbc9501ea80f20354bca44, on 1/19/2016): the operation never completes, even with mouse jiggling. So it seems that things are working better than before, but not great.

You are correct. My initial report was misrepresenting the history of this problem. I had been using a polyfill (https://github.com/blueimp/JavaScript-Canvas-to-Blob) for .toBlob() in Chrome up until official native support was release. This is not a regression after all. I had simply forgotten about my polyfill and that Chrome did not have native support when filing the bug. However, the issue of the callback not being called reliably still stands.

Unable to rproduce the issue on Mac 10.11.4 using stable 50.0.2661.86 and the steps mentioned in the orginial report.
shrike@ : Assigning to you as per C#2,Could you please review the attached screen shot and update furhther on this.

Deleted: 606796_Apr_27.mp4 633 KB

606796_Apr_27.mp4 633 KB Download

C#4 would not show the issue because the spinner is not visible. I have attached a video of the behavior. Notice in my video that the spinner is visible, and that the callback does not fire until I move the mouse pointer. Otherwise, it would keep spinning for minutes.

Deleted: 606796_showing_issue.mp4 1.4 MB

606796_showing_issue.mp4 1.4 MB Download

Very strange - I have 50.0.2661.86 installed on my machine and tried it there and saw the problem, which is why I went back to test a version before the blob changes landed. However this morning I am unable to reproduce the problem in 50.0.2661.86 or 52.0.2715.0 Canary.

matt.chambers@, can you see if the bug happens for you in the latest Chrome Canary?

52.0.2718.0 Canary still exhibits the behavior. As noted, the issue is not always reproducible for every toBlob() call. In stable and canary, I've had to click 1 to 8 times before the behavior exhibited itself. The CodePen is the most isolated and reproduceable code I have (even with its randomness).

Also tested with --disable-extensions and --disable-plugins in stable 50.0.2661.86. Behavior is reproducible.

ccing xlai@: could you take a look?

This is most likely an issue with toBlob's asynchronous scheduling policy.

xlia@: I recall you had worked on a timeout mechanism to force immediate completion of the encode in cases where idle period scheduling was not allowing the task to complete in a timely manner. Could we get that code to land?

junov@: Yes it was  Issue 583070 . I still have that patch that get reverted because of a restriction of not leaking ActiveDomObjects in unit test.

The bug was due to a combination of two different issues:

1. A lack of timeout mechanism to force immediate completion of encode
   This has been fixed in  Issue 583070 . Patch lands and now in Chrome Canary. 

2. Idle tasks that canvas.toBlob relies upon sometimes do not fire
   This is an open bug ( Issue 609140 ,  Issue 597006 ) in Blink scheduling. 

But the fix in  Issue 583070  should be enough to get away the problem mentioned here. I just tried running http://codepen.io/anon/pen/RaYVwr/ in latest Canary build in Mac. The problem does not show up after I tried clicking the button 30+ times; sometimes toBlob is slow, but it will eventually execute within 9 seconds. I'll mark this as fixed.