Bug 39059 – canvas drawImage does not render SVG with embedded images correctly

• Component: SVG
• Status: NEW

[Justin Cormack]

Created attachment 55968 [details]
simple svg file with embedded image

If you load an SVG image into a canvas using drawImage(), it does not draw any <image> items that are in the SVG file.

Example included - 2 files, 1 SVG file which renders correctly (3 circles and a red bitmap blob), plus Javascript that loads that image into canvas and does not show the bitmap.

[Justin Cormack]

Created attachment 55969 [details]
file that loads the svg file into canvas, renders without bitmap

[Dirk Schulze]

Created attachment 231289 [details]
Test case

I think this might be a duplicate of other bugs where an SVG image doesn't load embedded images.

[Dirk Schulze]

The embedded image gets rendered on reloading the document. I am not sure if the embedded image might not be encoded in time for the onload event. I also don't know if onload requires images to be encoded and ready for rendering. But how else would the user know if the SVG is ready to render?

[Said Abou-Hallawa]

Created attachment 291366 [details]
test case (working) - wait for sub-resources

[Said Abou-Hallawa]

(In reply to comment #3)
> The embedded image gets rendered on reloading the document. I am not sure if
> the embedded image might not be encoded in time for the onload event. I also
> don't know if onload requires images to be encoded and ready for rendering.
> But how else would the user know if the SVG is ready to render?

I added a new test case where it waits for 100ms after onLoad() event to ensure the sub-resources are loaded/decoded before drawing the image to the canvas. Of course this will not be a reliable way to fix the issue if the data url sub-resource is big or the hardware is slow.

The data url image is the only exception to be allowed as a sub-resource in an SVG. No loading from network is involved since all the data are loaded with the SVG itself. The only overhead is decoding the the data url to an image.

The sub-resources can also be nested if the data url image is an SVG image which has a data url image.

[Ahmad Saleem]

If I use the attached test case [test case(working) - wait for sub-resources], it renders "red" fog pixelated in Safari 15.5 on macOS 12.4 but when using Safari Technical Preview 148, it renders it similar to other browsers (Chrome Canary 105 and Firefox Nightly 104).

I think it is fixed along the lines. Can this be marked as "RESOLVED CONFIGURATION CHANGED" considering it is fixed in future versions? If someone knows exact bug, where it is fixed or likely fixed as knock-off effect then it can be marked as Duplicate of XYZ. Thanks!

[Alexey Proskuryakov]

I think that the bug will be fixed once Dirk's "Test case" passes, and that still doesn't, at least not in a clean browsing session.

[Ahmad Saleem]

Created attachment 460563 [details]
Safari 15.5 vs STP 148

@ap - I tested it in "Private Browse" where cookies and cache does not impact and this attached is screenshot of STP 148 behavior compared to Safari 15.5. STP behavior matches with Chrome Canary 105 and Firefox Nightly 104. If I am testing it incorrectly, please educate, so in future I don't make those mistakes. Thanks!

[Alexey Proskuryakov]

I think that you tested with "test case (working) - wait for sub-resources", but not with "Test case"? As Said explained when posting it, that was a demonstration meant to help isolate what the bug is - it always passed, in contrast to the actual test case for the bug.

When loading the actual test case in a clean session, there are only the three overlapping circles displayed.

[Brent Fulgham]

Safari, Chrome, and Firefox all agree on rendering for this test case. I don't believe there is any remaining compatibility issue.

[Brent Fulgham]

Actually -- I see the issue: There is a race condition. If you reload the SVG test case it works. The first load lacks the background image.

[Radar WebKit Bug Importer]

<rdar://problem/97095682>

[Karl Dubost]

Created attachment 478899 [details]
zip for the testcases

All browsers behave the same here. I don't see a difference. in the local tests I have created with a server. 

unzip.
cd to the place you unzip 
then start a server:
   python3 -m http.server
then request in firefox, chrome, and safari.
   http://127.0.0.1:8000/test-canvas-external.html