thanks for the report & jsfiddle.

Able to reproduce this issue on Win7, Mac OS X 10.11.4, Ubuntu 14.04 using Chrome Stable 50.0.2661.87, Beta 51.0.2704.29, Dev 52.0.2716.0 and Canary 52.0.2718.0

Not a regression, issue existing from M30 # 30.0.1549.0 (Official Build 208818) m

Requesting dev team to look into this issue.

This is some kind of <canvas> bug, oddly! Not only does this work for <img> but stepping through this code shows this:

blink::HTMLCanvasElement::parseAttribute (this=0x1dbb673637e8, name="height", oldValue="(null)", value="1000")
    at ../../third_party/WebKit/Source/core/html/HTMLCanvasElement.cpp:159
159	    if (name == widthAttr || name == heightAttr)
(gdb) 
160	        reset();
(gdb) step
blink::HTMLCanvasElement::reset (this=0x1dbb673637e8)
    at ../../third_party/WebKit/Source/core/html/HTMLCanvasElement.cpp:334
334	    if (m_ignoreReset)
(gdb) next
337	    m_dirtyRect = FloatRect();
(gdb) 
340	    bool hadImageBuffer = hasImageBuffer();
(gdb) 
342	    int w = getAttribute(widthAttr).toInt(&ok);
(gdb) 
343	    if (!ok || w < 0)
(gdb) p w
$1 = 0
(gdb) p ok
$2 = false
(gdb) p getAttribute(widthAttr)
$3 = "(null)"

Maybe in this codepath it should use the value argument to parseAttribute instead of calling getAttribute? But I also don't know why this is not returning the new value. Anyway, over to the canvas people.

Moving this nonessential bug to the next milestone.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Hmm, the above still seems suspicious to me but actually this bug will also be fixed by my fix for  bug 598212 

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/c43e0bb044f911727bcb340753de1fe03514a2ff

commit c43e0bb044f911727bcb340753de1fe03514a2ff
Author: cbiesinger <cbiesinger@chromium.org>
Date: Wed Jun 29 22:44:06 2016

Canvas objects did not mark themselves for layout when they're a flex item

See comment in patch -- when we're a flex item, we (likely)
have an override size, so updateLogicalHeight has no effect,
so the check if our size has changed has no effect. Skip
that if we have an override size.

TEST=css3/flexbox/canvas-dynamic-change.html
BUG= 607314 , 598212 
R=eae@chromium.org,dgrogan@chromium.org

Review-Url: https://codereview.chromium.org/2111623002
Cr-Commit-Position: refs/heads/master@{#402973}

[add] https://crrev.com/c43e0bb044f911727bcb340753de1fe03514a2ff/third_party/WebKit/LayoutTests/css3/flexbox/canvas-dynamic-change.html
[modify] https://crrev.com/c43e0bb044f911727bcb340753de1fe03514a2ff/third_party/WebKit/Source/core/layout/LayoutHTMLCanvas.cpp

The user visible part of this is fixed but I'll leave this open in case
canvas people want to investigate further about my comment above

What was observed is normal the width and height content attributes are allowed to be  unspecified (which is indicated by the "!ok" condition), in which case the implementation uses default values for those attributes.

In the example of this fiddle, the width is unspecified.

We can close this IMO