Bug 172728 - Page that allocates and destroys canvas elements in a loop gets jettisoned on iOS
Summary: Page that allocates and destroys canvas elements in a loop gets jettisoned on...
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: Canvas (show other bugs)
Version: WebKit Local Build
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Nobody
URL: http://jsfiddle.net/vcubzdgo/1/
Keywords: InRadar
Depends on:
Reported: 2017-05-30 13:32 PDT by Simon Fraser (smfr)
Modified: 2017-05-31 13:45 PDT (History)
5 users (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Simon Fraser (smfr) 2017-05-30 13:32:25 PDT
Load this page

on iPad, and the tab will get killed because it goes above the jetsam high watermark.

It's allocating and destroying canvas elements in a loop, so ideally would not get jettisoned. Why is GC not kicking in?
Comment 1 Simon Fraser (smfr) 2017-05-30 13:41:10 PDT
The repro url is http://jsfiddle.net/vcubzdgo/1/
Comment 2 Radar WebKit Bug Importer 2017-05-30 13:41:30 PDT
Comment 3 Simon Fraser (smfr) 2017-05-30 17:09:19 PDT
From the web inspector, and via code instrumentation, WebKit is retaining all the canvas elements and their image buffers while the loop is running. Chrome seems to be able to GC them as the loop runs.
Comment 4 Simon Fraser (smfr) 2017-05-30 17:46:37 PDT
This is something about fabric's addListener(fabric.window, 'resize', this._onResize); code.
Comment 5 Simon Fraser (smfr) 2017-05-30 17:59:50 PDT
If I comment out the line in fabric.js, the bug goes away:

  this._onResize = this._onResize.bind(this);
Comment 6 Joseph Pecoraro 2017-05-30 21:56:55 PDT
I think this is primarily a programming error in the page that will cause the "fabric.Canvas" instances to be kept alive by leaked global resize listeners being registered.

I boiled it down to:

    MyCanvas = function() {

    MyCanvas.prototype.initialize = function() {
        this.a = document.createElement('canvas');
        this.f = (function() {}).bind(this); // 2nd time this will overwrite "this.f"
        window.addEventListener('resize', this.f);

    MyCanvas.prototype.dispose = function() {
        window.removeEventListener('resize', this.f);

    window.addEventListener("load", function() {
        var canvas;
        for (var count = 0; count < 100; count++){
            console.log("count", count);
            canvas = new MyCanvas(); // initialize once
            canvas.initialize(); // initialize again
    }, false);

It looks like the page effectively calls initialize twice. This means:

  1. First call to initialize happens via new fabric.Canvas constructor:
      - creates the 1st this._onResize = this._onResize.bind()
      - adds this as a "resize" listener
      - note this constructor is generated within fabric.util.createClass as this.initialize.apply(this, args)

  2. Second call to initialize is explicit in the loop
      - overwrites the 1st this._onResize with a second
      - adds this as a "resize" listener

  3. Dispose clears the second this._onResize

Nobody ever clears the first resize listener added to the window as part of (1). And nobody can do that as nobody holds a reference to the function to the original onResize before it was rewritten. The reason why the resize handler is significant is because it is on the window, therefore global and will stay around forever unless removed. The others are localized to an element and can be collected with the element.


Compare to this fiddle:


> for(var count = 1; count < 100; count++){
>    console.log("count", count);
>    canvas = new fabric.Canvas();
>    canvas.initialize(canvasElement, {height:2000, width: 2000});
>    canvas.add(rect);
>    canvas.dispose();
> }


> for (var count = 1; count < 100; count++){
>     console.log("count", count);
>     canvas = new fabric.Canvas(canvasElement, {height:2000, width: 2000});
>     canvas.add(rect);
>     canvas.dispose();
> }

This doesn't call initialize twice, and doesn't have the same leaks.


Now, even after diagnosing this as the issue doesn't mean we can't make a change to WebKit to improve WebKit's behavior in these situations. I don't think any of these Canvas elements are actually attached to the page, so maybe we can free some of the memory held by them.
Comment 7 Simon Fraser (smfr) 2017-05-30 22:08:38 PDT
Thanks for the analysis, Joe! I wonder why Chrome doesn't show the same memory growth.
Comment 8 Simon Fraser (smfr) 2017-05-31 13:45:22 PDT
I filed an issue on Fabric.js: