This is like bug 124709, but for SVG.

Pending resolution of bug 124709.

*** Bug 160953 has been marked as a duplicate of this bug. ***

The patch makes image/svg+xml an alias for XML. It specifically does not add the type to the Accept header, because advertising Mozilla's current level of SVG support there could cause problems in the future. In order to avoid a crash, the patch uses the generic XMLDocument CID and not the SVGDocument CID. I supposed the crash is due to to content/svg/document/src/nsSVGDocument.cpp being only partially implemented. Then there is the issue about the correctness of supporting image/svg+xml at this point. Quote from RFC 3023: "Content-type: image/svg+xml" [...] "As a format based on XML, SVG documents SHOULD use the '+xml' suffix convention in their MIME content-type identifier. However, no content type has yet been registered for SVG and so this media type should not be used until such registration has been completed." Quote from the SVG 1.0 Recommendation: "The MIME type for SVG is "image/svg+xml" (see [RFC3023]). The W3C will register this MIME type around the time when SVG is approved as a W3C Recommendation." SVG became a Recommendation 11 months ago. image/svg+xml does not appear in the IANA registry. Even if image/svg+xml is not a proper de jure standard, it is already *the* de facto standard. It is recognized by Adobe's viewer and Batik and it is used for serving the W3C SVG test suite.

Does this mean that svg images in an html <img> tag now load, where tehy didn't before? If so, then this bug must NOT be fixed for security reasons, due to the scripting svgs can do - lots of parts of the browser assume that images can't actively do 'stuff'.

If the rest of the browser assumes that images can't cope with scripting, there is a bug elsewhere. But can you give an example? Since people have to compile mozilla themselves if they want SVG, I think this bit should be put in for debugging reasons. But by all means, output a warning.

Well, currently images can't run scripts. Allowing a theme's throbber to read what page you're currently on and then send it off somewhere is one theoretical example. However, I don't think that changing this will affect that. Its easy to test though; just make an html document which has an <img src="foo.svg"> in it and see if it loads and if it can run scripts via <html:script>

The attached patch will not compile on my RH 7.3 system: c++ -o nsContentDLF.o -c -DOSTYPE=\"Linux2.4\" -DOSARCH=\"Linux\" -DOJI -I./../base/src -I./../html/base/src -I./../html/style/src -I./../xul/content/src -I./../xul/base/src -I./../xul/templates/src -I./../events/src -I./../html/content/src -I./../html/document/src -I. -I../../dist/include/xpcom -I../../dist/include/string -I../../dist/include/gfx -I../../dist/include/layout -I../../dist/include/widget -I../../dist/include/necko -I../../dist/include/rdf -I../../dist/include/docshell -I../../dist/include/dom -I../../dist/include/htmlparser -I../../dist/include/uriloader -I../../dist/include/webshell -I../../dist/include/locale -I../../dist/include/unicharutil -I../../dist/include/lwbrk -I../../dist/include/js -I../../dist/include/pref -I../../dist/include/xul -I../../dist/include/xuldoc -I../../dist/include/xultmpl -I../../dist/include/webbrwsr -I../../dist/include/caps -I../../dist/include/xpconnect -I../../dist/include/imglib2 -I../../dist/include/content -I../../dist/include -I/home/geir/cvs/mozilla/dist/include/nspr -I/usr/X11R6/include -fPIC -I/usr/X11R6/include -fno-rtti -fno-exceptions -Wall -Wconversion -Wpointer-arith -Wbad-function-cast -Wcast-align -Woverloaded-virtual -Wsynth -Wno-ctor-dtor-privacy -pedantic -Wno-long-long -fshort-wchar -pthread -pipe -DNDEBUG -DTRIMMED -O -I/usr/X11R6/include -DMOZILLA_CLIENT -include ../../config-defs.h -Wp,-MD,.deps/nsContentDLF.pp nsContentDLF.cpp nsContentDLF.cpp:115:8: macro names must be identifiers nsContentDLF.cpp:250:8: macro names must be identifiers nsContentDLF.cpp:648:8: macro names must be identifiers The "#ifdef 0" changes in the patch are the causes of these errors. Proposed fix: Uncomment the code instead of changing the macro.

html.txt is the embed tag used to embed an svg button in html through a jsp script. headers.txt are the headers returned by this script. b.svg is the svg button itself.

Attaching a new version of the patch that has #if 0 instead of #ifdef 0. The patch makes Mozilla support SVG as image/svg+xml where previously SVG as application/xml or text/xml was supported. It doesn't add any other SVG fixes. Attachment 94453 [details] doesn't test this patch and is beyond the scope of this bug. The test case doesn't work with Mozilla when served as application/xml or text/xml, either.

The patch does not add any new SVG in <img> support. SVG in <img> is not displayed and, as far as I can see, can't execute scripts.

Comment on attachment 94669 [details] [diff] [review] Patch for making image/svg+xml an alias for XML (fixes #ifdef 0) Why isn't the SVG document class ready to be used?

If I try to register the SVG document class as the handler for SVG, Mozilla crashes when it tries to load SVG as image/svg+xml. I think the reason why this happens is that the SVG document class has unimplemented methods.

1. This is now _partially_ fixed on SVG_20020806_BRANCH (see bug#182533), where nsSVGDocument is working. One peculiarity is that on Linux, when I open a local *.svg file, the mime-type is correctly recognised but Mozilla offers to download the file. It is not being displayed as SVG. On Windows, Mozilla shows the SVG... 2. IMO, letting images run scripts is ok. The scripts are sandboxed in their own document. It's the same loading an iframe or object.

*** Bug 129917 has been marked as a duplicate of this bug. ***

This should be fixed by bug 155730.

*** Bug 208119 has been marked as a duplicate of this bug. ***

This is now fully fixed on SVG_20020806_BRANCH (see bug#182533).

Fixed by branch landing (bug 182533)