Bugzilla

The bottom line here is that things are pretty wildly non-interoperable for the interesting cases.

The simplest thing to start out here might be to just use the fallback 300x150 size if the SVG image doesn't have a full intrinsic size, if that's easy. I suspect that'll make us match WebKit and is probably good enough for common cases to work, as a quick fix to stop the pain here.

I think Chrome's more-nuanced behavior is probably what the spec actually calls for, though.

FWIW the relevant spec text here seems to be under `Establish the source and destination rectangles as follows:` in https://html.spec.whatwg.org/multipage/canvas.html#dom-context-2d-drawimage-dev  (dw/dh = destination width & height [omitted in megatests 1 and 2], sw/sh = source width and height [omitted in all tests here I think]. Quoting the spec, bold section being the most-relevant bit:
> If not specified, the dw and dh arguments must default to the values of sw and sh, interpreted such that one CSS pixel in the image is treated as one unit in the output bitmap's coordinate space. If the sx, sy, sw, and sh arguments are omitted, then they must default to 0, 0, the image's intrinsic width in image pixels, and the image's intrinsic height in image pixels, respectively. **If the image has no intrinsic dimensions, then the concrete object size must be used instead, as determined using the CSS "Concrete Object Size Resolution" algorithm, with the specified size having neither a definite width nor height, nor any additional constraints, the object's intrinsic properties being those of the image argument, and the default object size being the size of the output bitmap.**

The bottom line here is that things are pretty wildly non-interoperable for the interesting cases.

The simplest thing to start out here might be to just use the fallback 300x150 size if the SVG image is missing either a pixel-valued width or height. I suspect that'll be easy, will make us match WebKit (so some interop improvement), and is probably good enough for common cases to work, as a quick fix to stop the pain here.

I think Chrome's more-nuanced behavior is probably what the spec actually calls for, though.

FWIW the relevant spec text here seems to be under `Establish the source and destination rectangles as follows:` in https://html.spec.whatwg.org/multipage/canvas.html#dom-context-2d-drawimage-dev  (dw/dh = destination width & height [omitted in megatests 1 and 2], sw/sh = source width and height [omitted in all tests here I think]. Quoting the spec, bold section being the most-relevant bit:
> If not specified, the dw and dh arguments must default to the values of sw and sh, interpreted such that one CSS pixel in the image is treated as one unit in the output bitmap's coordinate space. If the sx, sy, sw, and sh arguments are omitted, then they must default to 0, 0, the image's intrinsic width in image pixels, and the image's intrinsic height in image pixels, respectively. **If the image has no intrinsic dimensions, then the concrete object size must be used instead, as determined using the CSS "Concrete Object Size Resolution" algorithm, with the specified size having neither a definite width nor height, nor any additional constraints, the object's intrinsic properties being those of the image argument, and the default object size being the size of the output bitmap.**

The bottom line here is that things are pretty wildly non-interoperable for the interesting cases.

The simplest thing to start out here might be to just use the fallback 300x150 size if the SVG image is missing either a pixel-valued width or height. I suspect that'll be easy, will make us match WebKit (so some interop improvement), and is probably good enough for common cases to work, as a quick fix to stop the pain here.

I think Chrome's more-nuanced behavior is probably what the spec actually calls for, though.

FWIW the relevant spec text here seems to be under `Establish the source and destination rectangles as follows` in https://html.spec.whatwg.org/multipage/canvas.html#dom-context-2d-drawimage-dev  (dw/dh = destination width & height [omitted in megatests 1 and 2], sw/sh = source width and height [omitted in all tests here I think]. Quoting the spec, bold section being the most-relevant bit:
> If not specified, the dw and dh arguments must default to the values of sw and sh, interpreted such that one CSS pixel in the image is treated as one unit in the output bitmap's coordinate space. If the sx, sy, sw, and sh arguments are omitted, then they must default to 0, 0, the image's intrinsic width in image pixels, and the image's intrinsic height in image pixels, respectively. **If the image has no intrinsic dimensions, then the concrete object size must be used instead, as determined using the CSS "Concrete Object Size Resolution" algorithm, with the specified size having neither a definite width nor height, nor any additional constraints, the object's intrinsic properties being those of the image argument, and the default object size being the size of the output bitmap.**

The bottom line here is that things are pretty wildly non-interoperable for the edge cases.

The simplest thing to start out here might be to just use the fallback 300x150 size if the SVG image is missing either a pixel-valued width or height. I suspect that'll be easy, will make us match WebKit (so some interop improvement), and is probably good enough for common cases to work, as a quick fix to stop the pain here.

I think Chrome's more-nuanced behavior is probably what the spec actually calls for, though.

FWIW the relevant spec text here seems to be under `Establish the source and destination rectangles as follows` in https://html.spec.whatwg.org/multipage/canvas.html#dom-context-2d-drawimage-dev  (dw/dh = destination width & height [omitted in megatests 1 and 2], sw/sh = source width and height [omitted in all tests here I think]. Quoting the spec, bold section being the most-relevant bit:
> If not specified, the dw and dh arguments must default to the values of sw and sh, interpreted such that one CSS pixel in the image is treated as one unit in the output bitmap's coordinate space. If the sx, sy, sw, and sh arguments are omitted, then they must default to 0, 0, the image's intrinsic width in image pixels, and the image's intrinsic height in image pixels, respectively. **If the image has no intrinsic dimensions, then the concrete object size must be used instead, as determined using the CSS "Concrete Object Size Resolution" algorithm, with the specified size having neither a definite width nor height, nor any additional constraints, the object's intrinsic properties being those of the image argument, and the default object size being the size of the output bitmap.**