Last Comment Bug 160882 - MIME type image/svg+xml should be supported
: MIME type image/svg+xml should be supported
Status: RESOLVED FIXED
:
Product: Core
Classification: Components
Component: SVG (show other bugs)
: Trunk
: x86 All
: -- normal with 4 votes (vote)
: ---
Assigned To: Alex Fritze
: Bradley Baetz (:bbaetz)
Mentors:
: 129917 208119 (view as bug list)
Depends on: */*+xml 124709 svgbranch
Blocks: 160883 129917
  Show dependency treegraph
 
Reported: 2002-08-03 11:41 PDT by Aaron Kaluszka
Modified: 2004-02-10 05:23 PST (History)
13 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
Patch for making image/svg+xml an alias for XML (7.91 KB, patch)
2002-08-07 11:03 PDT, Henri Sivonen (:hsivonen) (Not reading bugmail or doing reviews until 2016-09-26)
no flags Details | Diff | Splinter Review
SVG fragments which cause the patch already uploaded to fail - works with Adobe SVG viewer. (1.51 KB, application/x-gzip)
2002-08-08 03:46 PDT, Geir Hedemark
no flags Details
Patch for making image/svg+xml an alias for XML (fixes #ifdef 0) (8.12 KB, patch)
2002-08-09 13:31 PDT, Henri Sivonen (:hsivonen) (Not reading bugmail or doing reviews until 2016-09-26)
no flags Details | Diff | Splinter Review

Description Aaron Kaluszka 2002-08-03 11:41:13 PDT
This is like bug 124709, but for SVG.
Comment 1 Aaron Kaluszka 2002-08-03 11:47:13 PDT
Pending resolution of bug 124709.
Comment 2 Kai Lahmann (is there, where MNG is) 2002-08-04 07:06:42 PDT
*** Bug 160953 has been marked as a duplicate of this bug. ***
Comment 3 Henri Sivonen (:hsivonen) (Not reading bugmail or doing reviews until 2016-09-26) 2002-08-07 11:03:27 PDT
Created attachment 94353 [details] [diff] [review]
Patch for making image/svg+xml an alias for XML
Comment 4 Henri Sivonen (:hsivonen) (Not reading bugmail or doing reviews until 2016-09-26) 2002-08-07 11:31:54 PDT
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.
Comment 5 Bradley Baetz (:bbaetz) 2002-08-07 16:55:03 PDT
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'.
Comment 6 Geir Hedemark 2002-08-08 00:34:42 PDT
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.
Comment 7 Bradley Baetz (:bbaetz) 2002-08-08 01:32:00 PDT
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>
Comment 8 Geir Hedemark 2002-08-08 02:41:02 PDT
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.
Comment 9 Geir Hedemark 2002-08-08 03:46:55 PDT
Created attachment 94453 [details]
SVG fragments which cause the patch already uploaded to fail - works with Adobe SVG viewer.

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.
Comment 10 Henri Sivonen (:hsivonen) (Not reading bugmail or doing reviews until 2016-09-26) 2002-08-09 13:31:19 PDT
Created attachment 94669 [details] [diff] [review]
Patch for making image/svg+xml an alias for XML (fixes #ifdef 0)

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.
Comment 11 Henri Sivonen (:hsivonen) (Not reading bugmail or doing reviews until 2016-09-26) 2002-08-09 13:38:15 PDT
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 12 Bradley Baetz (:bbaetz) 2002-08-09 16:56:53 PDT
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?
Comment 13 Henri Sivonen (:hsivonen) (Not reading bugmail or doing reviews until 2016-09-26) 2002-08-10 00:25:54 PDT
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.
Comment 14 Alex Fritze 2002-11-29 00:41:41 PST
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.
Comment 15 Henri Sivonen (:hsivonen) (Not reading bugmail or doing reviews until 2016-09-26) 2002-12-11 14:59:16 PST
*** Bug 129917 has been marked as a duplicate of this bug. ***
Comment 16 Hixie (not reading bugmail) 2003-02-10 10:12:42 PST
This should be fixed by bug 155730.
Comment 17 Boris Zbarsky [:bz] (still a bit busy) 2003-06-03 18:45:33 PDT
*** Bug 208119 has been marked as a duplicate of this bug. ***
Comment 18 Alex Fritze 2003-07-02 13:57:41 PDT
This is now fully fixed on SVG_20020806_BRANCH (see bug#182533).
Comment 19 Alex Fritze 2004-02-10 05:23:40 PST
Fixed by branch landing (bug 182533)

Note You need to log in before you can comment on or make changes to this bug.