Cam, is the SVG specification right? It says attribute DOMString crossOrigin; but the html DOM in gecko (and my WIP patch) has attribute DOMString? crossOrigin;
Checking the HTML spec, it looks like it should indeed be "DOMString?". I've updated the spec: https://svgwg.org/svg2-draft/embedded.html#ImageElementCrossoriginAttribute
(In fact the HTML spec changed underneath us.)
Created attachment 8709662 [details] [diff] [review] working patch
Attachment #8708824 - Attachment is obsolete: true
This seems to work but I don't know how to write an automated test for it. Any suggestions?
I imagine the tricky part of the automated test is the cross-origin part, right? That's explained a bit here: https://developer.mozilla.org/en/docs/Mochitest#How_do_I_test_issues_which_only_show_up_when_tests_are_run_across_domains.3F I'd expect you want to write a mochitest which... * ...uses SVG in an iframe and snapshotWindow to see whether stuff rendered or not, like this test: http://mxr.mozilla.org/mozilla-central/source/dom/svg/test/test_use_with_hsts.html * ...uses an <image> & <feImage> that point to 'example.org', which the mochitest web server will recognize and map to your source tree, like in these tests: http://mxr.mozilla.org/mozilla-central/source/devtools/client/inspector/test/browser_inspector_navigation.js http://mxr.mozilla.org/mozilla-central/source/devtools/client/storage/test/storage-listings.html A few other thoughts: * Promises make the iframe load callbacks a bit easier to follow. If you're not too familiar with promises, feel free to crib from my test_use_with_hsts.html test and ping me with questions. Or, traditional async callbacks shouldn't be too complex either. * For robustness, your SVG file (or SVG files) should include both elements (<feImage> & <image>), with the crossOrigin attribute present & not-present.
You need to log in before you can comment on or make changes to this bug.