The default bug view has changed. See this FAQ.

MIME type image/svg+xml should be supported

RESOLVED FIXED

Status

()

Core
SVG
RESOLVED FIXED
15 years ago
13 years ago

People

(Reporter: Aaron Kaluszka, Assigned: Alex Fritze)

Tracking

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

Trunk
x86
All
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 2 obsolete attachments)

(Reporter)

Description

15 years ago
This is like bug 124709, but for SVG.
(Reporter)

Updated

15 years ago
Blocks: 160883
(Reporter)

Comment 1

15 years ago
Pending resolution of bug 124709.
Depends on: 124709
*** Bug 160953 has been marked as a duplicate of this bug. ***
Created attachment 94353 [details] [diff] [review]
Patch for making image/svg+xml an alias for XML
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'.

Comment 6

15 years ago
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>

Comment 8

15 years ago
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

15 years ago
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.
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.
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.
(Assignee)

Updated

15 years ago
Depends on: 182533
(Assignee)

Comment 14

15 years ago
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: 155730
*** Bug 208119 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 18

14 years ago
This is now fully fixed on SVG_20020806_BRANCH (see bug#182533).
(Assignee)

Comment 19

13 years ago
Fixed by branch landing (bug 182533)
Status: NEW → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.