Closed Bug 160882 Opened 22 years ago Closed 21 years ago

MIME type image/svg+xml should be supported

Categories

(Core :: SVG, defect)

Product:
Core
Component:
SVG
Platform:
x86
All
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: megabyte, Assigned: alex)

References

(Depends on 1 open bug, Blocks 1 open bug)

Details

Attachments

(1 file, 2 obsolete files)

Patch for making image/svg+xml an alias for XML (fixes #ifdef 0)
8.12 KB, patch
Details | Diff | Splinter Review 
This is like bug 124709, but for SVG.
Blocks: 160883
Pending resolution of bug 124709.
Depends on: 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.
Attachment #94353 - Attachment is obsolete: true
Attachment #94453 - Attachment is obsolete: true
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.
Depends on: svgbranch
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.
Blocks: 129917
*** Bug 129917 has been marked as a duplicate of this bug. ***
This should be fixed by bug 155730.
Depends on: */*+xml
*** 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)
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: