New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 278940 link

Starred by 64 users

Issue metadata

Status: Fixed
Last visit > 30 days ago
Closed: Sep 2013
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 1
Type: Bug

Sign in to add a comment

Canvas loses ability to render, is blank even if page reloaded.

Reported by, Aug 25 2013

Issue description

UserAgent: Mozilla/5.0 (Windows NT 6.2; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/29.0.1547.57 Safari/537.36

Example URL:

Steps to reproduce the problem:
1. Load this uri:
2. Open the dev tools
3. Zoom into the chart by doing a click and drag over its content
4. Hit reload on the page. 
5. Notice blank chart.
6. Hit reload again.
7. Notice chart is still blank.
8. Close tab.
9. Reopen tab.
10. Notice chart is displayed.

What is the expected behavior?
Since the exact same JS code is being run and the exact same canvas ops are happening every tiem, the chart should ALWAYS display.

What went wrong?
With the dev tools open, and the canvas has been interacted with, a reload causes the canvas to not render any content. It is as if it cannot talk to the GPU? And this remains broken, regardless of further reloads until the tabs process is killed and restarted.

Does it occur on multiple sites: Yes

Is it a problem with a plugin? No 

Did this work before? Yes Hard to tell, probably sometime before version 28?

Does this work in other browsers? Yes IE 11 

Chrome version: 29.0.1547.57  Channel: stable
OS Version: 6.2 (Windows 8)
Flash Version: Shockwave Flash 11.8 r800

I believe the tab's process is getting hosed and can no longer get surfaces for the GPU to render into. I can tell that all the same canvas ops are being run, but there is no content displayed. I tried to create a simpler repro, but have been unable to repro with something less complex than the chart.
I cannot reproduce your exact example, but I have the same issue in a different context. I'm pretty sure the dev tools have nothing to do with it, for starters, because I've had this happen to all users of my site, and most of them never use any dev tools.

When I leave my canvas rendering for about 30 minutes, it just stops drawing anything. The site is still responsive, everything works, but the rendering is gone. Again, the only way to fix it is to close the tab and open a new one - refreshing does NOT help.

I've also found that by reducing the size of the canvas, you can start the rendering again. The problem with the 30 minute waiting of course is that it is difficult to reproduce. Maybe if we put our heads together we can figure out what is going on here and create a reproducable example?

Comment 3 by, Aug 25 2013

In this particular instance, I can only repro it with the dev tools open, but I'm sure the issue may have other repro paths. Which is why this probably shouldn't be treated as an edge case. Its very easy to repro with this page though.

I didn't ever notice anything like this until recently, so I think it must have started happening in chrome 28 or chrome 29.

Comment 4 by, Aug 25 2013

Doesn't sound related to that other bug.
Actually, I CAN reproduce your example. It only requires some extensive scrolling before refreshing for it to occur. And when it occurs, you CAN actually fix the rendering by reducing the size of the canvas through the DOM to 200x150.

When that happens, you can draw rectangles again in the upper left corner (they are rendered through canvas), so the rendering works again. Make it bigger again, and the rendering stops.

So this is definitely the same issue I am having.

Comment 6 by, Aug 25 2013

actually, nevermind, I think I can repro it without the dev tools too. 
Load this uri: (same one)

Put the mouse over the chart and roll the mouse wheel in and out a bit. Then reload. Sometimes it will come back blank, and then wont recover till you reopen the tab.

I agree this is new. I also wasn't having this when I was testing 2 months ago. So this makes me think it's related to Chrome switching to the Blink form from Webkit.
Actually, just "hanging around" on the chart with your mouse is enough to trigger the crash. You don't even need to interact or trigger anything. Just hover the mouse over the graph, move around a little, and refresh.

The moving seems to be essential. Just hovering it over the graph and holding still will not trigger it. But moving it around for a while will.

Comment 9 by, Aug 25 2013

Labels: -Cr-Content Cr-Blink-Canvas Cr-Internals-GPU-Canvas2D

Comment 10 by, Aug 25 2013

When you are hovering over it, getImageData is being called periodically on CanvasContext2D since the chart does per pixel hit testing to tell if you are over the content. So my theory was that it had to do with some bug in that method, but I've been unsuccessful in trying to repro the issue in an isolated environment:

Comment 11 by, Aug 25 2013

If someone has the ability to edit the opening description, you may want to remove that is only happens with dev tools open. This isn't true. It just makes it a bit easier to repro.
When I use dev tool experiments to take snapshots of the canvas while it is not being drawn, it still shows perfectly fine in the snapshot preview. It's just not rendering on screen. So there's definitely nothing wrong with the actual drawing calls or code. It's got something to do with updating the browser area or something like that.
Actually, any canvas up to size 256x256 works perfectly fine when the bug is "in action". But 257x256 or 256x257 will not work.

To see this in action:
1. trigger the bug on the page above
2. execute the following code in dev tools:
var canvas = document.createElement("canvas");
canvas.width = 256;
canvas.height = 256;
canvas.fillRect(0, 0, 200, 200); // works
canvas.width = 257;
canvas.fillRect(0, 0, 200, 200); // does nothing

This definitely sounds a memory related issue. This really feels like there's a video buffer overflowing somewhere or something like that.

Comment 14 by, Aug 26 2013

256x256 is the minimum size for accelerating 2d canvases on the GPU in Chrome.  This bug is most likely related to GPU acceleration.

Comment 15 by, Aug 26 2013

Status: Assigned

Comment 16 by, Aug 26 2013

I am having a hard time reproducing this problem.
Please provide more information on your graphics configuration.
1. Navigate to chrome://gpu
2. Save the page
3. Attach it to this bug.

Comment 17 by, Aug 26 2013

Here is the gpu info
78.0 KB View Download

Comment 18 by, Aug 26 2013

Ok, I have a laptop with the same GPU.  I was able to reproduce in Chrome 29, but the problem appears to be already fixed in Chrome 30 (currently in beta).

@gmurray: It would be great if you could confirm that this is in fact fixed in Chrome 30.

Perhaps we could bisect to find out what fixed it.

Comment 20 by, Aug 27 2013

I haven't been able to repro it yet in Chrome 30.
I also tried in Chrome 30, it seems fixed.

It's pretty wide spread in 29... here's an example that crashes WITHOUT dev tools:

Comment 24 by, Aug 28 2013

 Issue 280153  has been merged into this issue.
Is there any hope of getting a fix pushed to Chrome 29 stable?

If not, when is Chrome 30 likely to hit stable? 

It's affecting real world applications.

Comment 26 by, Aug 28 2013

There has been too much code churn in this area of the code in M30 for us to start cherry-picking patches to bring back into M29.  This seem serious enough to warrant working on a fix directly in the M29 branch.

kerz: what do you think?  Do we fix in M29 or just hold tight until M30? This bug is causing trouble in production all over the place, including Google properties.

Comment 27 by, Aug 28 2013

Chrome 29 still has the CANVAS_USES_MAILBOX gyp variable in it, and I think none of the code dependency have been ripped-out in the branch.  I will try a local build to see.  If that works we can revert canvases to to their M28 implementations by the flip of a switch.  That variable also affects WebGL, which is not affected by this bug, so I might fork the gyp var into two.

piman, dana: Do you anticipate any issues with disabling Mailboxes in M29? 
I think it would be okay, given we're not shipping ubercomp anywhere in 29. But piman should double check me on this for texture layer.

Have you tried a build of the 29 branch with the variable off?

Comment 29 by, Aug 28 2013

@#28: still struggling with gclient/svn.  Checking-out from branch is more painful than I recall. 

Before trying any fixes, I want to repro in a debug build to fully understand what is going on.  Vangelis pointed-out that turning of mailboxes at this point is a bit scarry. I tend to agree because the surrounding blink and compositor code has evolved since the switch to mailboxes was made.  I have an idea for a less scary fix...  I will post an update as soon as I have something interesting to report.

Comment 30 by, Aug 28 2013

I think it should be ok on 29.

Comment 31 by, Aug 29 2013

Figured out what the problem is.  It is a bug that has been in skia for two years and went undetected until now. GrGpuGL::onCreateTexture is calling TexParameteri before binding the newly created texture.  The call to TexParameteri is for setting the GL_TEXTURE_USAGE property, which is just a hint. You wouldn't expect such a catastrophic problem from setting a hint on the wrong texture, which is why the bug went undetected for so long.  What changed in M29 is that Canvas2DLayerBridge::prepareMailbox was binding texture id 0 to GL_TEXTURE_2D before exiting.  If texture Id 0 is still bound to the ShareGC3D when GrGpuGL::onCreateTexture is invoked, the the call to TexParameteri will produce a GL error, which is detected and causes an early exit of onCreateTexture.  Because the early exit was leaving GL_TEXTURE_2D bound to texture 0, subsequent calls to onCreateTexture will also fail, sometimes leaving skia in an unrecoverable state, which explains why the only way to recover is to restart the render process (restart in a new tab)

The bug is specific to Windows because texture usage support is an angle extension.

The repro is flaky because it depends on a sequence of calls that is timing dependent (If the shared GC3D does anything, like a canvas draw, between the prepareMailbox and onCreateTexture, we're safe.

Course of action:
Although the bug is only manifesting itself in Chrome 29, the fix will be landed in trunk (Chrome 31). It is a longstanding bug in skia, so we need to carry the fix forward. Then we will consider merging the fix back to earlier versions.

This fix is very safe.  We are just moving a function call that was out of sequence.
@bsalomon can confirm this assessment.
Wow! Excellent detective work, Justin!

Comment 34 by, Aug 29 2013

Labels: M-29

Comment 35 by, Aug 29 2013

Labels: -Pri-2 Pri-1 Merge-Requested
Fix committed:

Comment 36 by, Aug 29 2013

Summary: Canvas loses ability to render, is blank even if page reloaded. (was: Canvas loses ability to render, is blank even if page reloaded. Only if dev tools are open.)
Is this going to be merged back into M29? Seems pretty widespread and also is affecting google apps.

Comment 38 by, Aug 29 2013

Skia patch was just rolled into the Chromium trunk:

Comment 39 by, Aug 29 2013

Merge CL on standby:

Comment 40 by, Aug 29 2013

Labels: -Merge-Requested Merge-Approved
Project Member

Comment 41 by, Aug 30 2013

Labels: -Merge-Approved merge-merged-1547
The following revision refers to this bug:

r41380 | | 2013-08-30T12:44:20.996886Z


Comment 42 by, Aug 30 2013

Labels: -M-29 M-30 Merge-Requested
Landed in the Chrome 29 branch.  

Now for Chrome 30...
Even though the repro steps don't seem to trigger the bug in M30, the bug still technically exists there.  Because the failure depends on a race condition, I am concerned that a different set of repro cases might trigger the bug in 30. I advise merging the fix to M30 to be on the safe side.
With the merge approved how long will it be until the M29 fix is be pushed out to end Chrome users?

Comment 44 by, Aug 30 2013

The fix will be included in the next stable channel update for Windows.  The previous update was released on August 28, next one is not scheduled yet. You can follow the news here:

Comment 45 by, Aug 30 2013

 Issue 280153  has been merged into this issue.

Comment 46 by, Aug 30 2013

Labels: -Merge-Requested Merge-Approved
hmm okie. 

Comment 47 by, Aug 30 2013

skia r11048 merges the fix into skia branch m30_1599
DEPS still need to be rolled in branch 1599.
Status: Fixed
Issue resolved.

No roll needed for M30 after all. DEPS in branch 1599 are configured to take ToT from skia branch m30_1599, so it is already in.

Fix has not yet shipped except for canary channel. Next dev, beta and stable channel updates will have the fix.
The DEPS change from comment #41 does not seem to have triggered the windows M29 official builder, so I was unable to test from an archived official build.
@kerz: does the builder need to be triggered manually or something?
Any idea as to when the fix will be coming to the stable channel?

Comment 51 by, Sep 3 2013

Build will need to be kicked by hand.  I'll do this later this week when we've picked up some other stuff.

Comment 52 by, Sep 3 2013

Labels: -Merge-Approved
Is the fixed deployed in 29.0.1547.66?
>>Is the fixed deployed in 29.0.1547.66?

No, I'm still able to reproduce the error in 29.0.1547.66. I can confirm it's fixed in 30.
@kerz When is this fix going out to stable?
It will be about 3 more weeks before M30 hits the Stable channel.

I thought this fix was going to hit M29?

I've had to tell hundreds of our users to stop using Google Chrome. We've actually had to officially remove support from Google Chrome to our applications because of this.

Comment 58 by, Sep 10 2013

Yep, way to exemplify why multi-vendor rendering engines can be a terrible idea. More QA next time please.
I stand corrected. It looks like junov@ did merge this to the M29 branch. 

However, kerz@ , kareng@ is 1547 the right branch for M29? We got burned by this with  issue 279472  where the fix was merged in 1547 but the actual release was cut from 1547_57. 
actually had to officially remove support from Google Chrome to our
applications because of this.

Even we have to officially remove chrome 29 support because of this issue -
this is on for almost 2 weeks now. A fix on 29 will be really appreciated.
On the meantime, is there any way to detect that the canvas is down ? getImageData still seems to return valid data ...
getImageData still seems to return valid data ...

You can use one of my sites to reproduce the problem:

1 Go to
2 Click Music
3 Click BACK in the browser
4 Click Music again, the canvas has disappeared

This only occurs in Chrome, occurs in 29, but not 30 onwards. The site uses
canvas via the kinetic.js library.

As you can see, it totally breaks the site which fortunately I haven't
launched yet.
Big supporter of Chrome, but had to tell my customers to use other browser till this get fixed. Really would like to tell my customers to use chrome as their default browser again. Any new news?

Comment 64 by, Sep 10 2013

i believe 1547_57 is the one jason's been pushing.
Status: Assigned
Justin, it sounds like the fix will need to be merged to a different branch.

Comment 66 by Deleted ...@, Sep 11 2013

Just another user of Google Chrome disappointed with the lack of urgency regarding this issue.  It would be really nice if this could get merge and released to v29 as soon as possible.  We have a production application that is not rendering canvas elements in Chrome only.  We've had to tell our clients to avoid Chrome.
Status: Fixed
Changing back to "fixed". The fix has indeed been merged to the right branch and will be picked up by the next M29 update (if there is one). 

@kerz is there going to another M29 update?  (Hopefully soon)

This regression is causing major issues in production for many different applications as seen above.

Comment 69 by Deleted ...@, Sep 19 2013

Our app is broken too b/c of this bug in chrome 29
click on pricing
select a size
upload an image.
uploaded images shows up blank.
Works in all other browsers (even in maxthon).  Telling clients to avoid chrome at the moment.

Comment 70 by Deleted ...@, Sep 19 2013

looks like it is working now in 29.0.1547.76 m

Comment 71 by, Sep 19 2013

Yes the update is being deployed progressively over the next few days, but you can force your browser to update to the latest version immediately by navigating to chrome://chrome/ (or click About Google Chrome in Chrome's menu)
>>looks like it is working now in 29.0.1547.76 m

Confirmed and good news!

>>Yes the update is being deployed progressively over the next few days

It would be great to know when the deployment is complete.

Comment 73 by, Sep 24 2013

 Issue 290409  has been merged into this issue.
Labels: hasTestcase

Sign in to add a comment