Closed Bug 303581 Opened 15 years ago Closed 7 years ago

Loading local SVG brings up Save As dialog, and <embed>ded SVG without 'type' attribute fails


(Core :: SVG, defect)

Windows XP
Not set





(Reporter: codedread, Assigned: longsonr)




(5 files)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b4) Gecko/20050728 Firefox/1.0+
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b4) Gecko/20050728 Firefox/1.0+

Up until yesterday I was able to open local SVG files in Mozilla Deer Park.  To
my mind I have not changed anything but today I am not able to open up local SVG
files.  I get the "Open or Save File" dialog.  

So, instead of "saving" I thought I'd be clever and click "Open" then chose the
firefox.exe file to handle the content, then checked the "Always use this
action".  When I did this and tried to browse to a local SVG file, it opened a
new tab which opened a new tab which opened a new tab which  ... you get the
idea - a chain reaction of tabs opening.

I had to quickly close all the opening tabs, go into Tools > Options and remove
the "SVG File Type" from the "View & Edit Actions" window.  After doing this, I
could bring up a local SVG file without a problem.

NOTE That none of this hindered my ability to display SVG files online.  This
only seems to be a problem with local SVG files.  There may be two problems
here, the issue of Fx occasionally forgetting what to do with local SVG files
and the ability for a user to have a chain reaction of tabs opening if they
choose firefox.exe to handle the content.

Reproducible: Sometimes

Steps to Reproduce:
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b4) Gecko/20050805 Firefox/1.0+

Works for me.
I have downloaded the latest Firefox nightly build (15 Aug 2005) for
Windows, and I am continuing to see a nagging problem that I discovered
with Deer Park 2.

I have no problem viewing SVG files from the network when the proper
MIME type is set. However, when trying to view a local file with .svg
extension, Deer Park keeps offering a dialog box where the file can be
saved. It claims that it is a "SVG Document", but refuses to handle
it itself.

The same happens if I create a HTML file which contains an <object> or
<embed> tag that specifies "image/svg+xml".

I have verified that the native rendering is enabled via about:config
(network files work fine). It just seems to not recognize the MIME
type of the local file. It basically reacts the same as if a file was
sent down the network with the wrong MIME type.

Anyone knows how does Firefox associate a MIME type for a local file? That might
help understanding the mechanics of this bug.
Here is a work around this problem, as offered by the original poster, but with
a change to avoid endless loop of opening tabs:

1. When opening a local SVG file and the "Save As" dialog comes up, select "Open
With" and then select any .exe (does not matter which one, except do not use
firefox.exe to avoid an endless loop). Also, select "Always open this type..."
check box.

2. Go to Tools > Options... > Downloads > View & Edit Actions...  and
remove the file association for SVG (it bogus, evidently)

3. Load local SVG document. It should be rendered correctly by the native renderer.
Just adding this in case it helps anyone else...

I thought I was hitting this bug with Firefox Beta1 - I kept getting the Save-As
dialog with SVG.  However, it turned out that with Windows versions prior to
WinXP you need to install a renderer to view SVG files. Details are at - see the box titled "MS Windows".

Briefly you should probably install GDI+: download from
keep un-zipping until you get the dll and then save the dll in the directory
where you installed Firefox.

I hear rumours that (if all goes to plan) you won't need to do this for much
longer and the Cairo renderer will be supplied with Firefox.
Yes, the GDI+ installation issue is something separate from this problem.  I
have been able to successfully view SVG content using the Firefox browser, this
issue only crops up with local SVG files.
*** Bug 314885 has been marked as a duplicate of this bug. ***
I doubt this is an SVG bug.  What do the file associations look like for people seeing this issue?
I've now experienced this too. The problem appeared after I installed Adobe Photoshop Elements 1.0.1 and decided to allow it to install the ancient Adobe SVG viewer that's bundled with it (ASV v1.0, build 94). This set up file associations for SVG.

In Windows Explorer I went to the Tools menu and selected Folder Options > File Types. Entries already existed for both SVG and SVGZ due to another application I have, but on selecting either and clicking on "Advanced" I found the entries called "open" in the "Actions:" box had been changed. Selecting the action "open" and clicking on "Edit..." showed the form was filled out as follows:

Application used to perform action:
"C:\Program Files\Internet Explorer\iexplore.exe" -nohome

Use DDE <checked>

DDE Message:


DDE Application Not Running:


I deleted the "open" entries, restarted Firefox and hoped everything would be back to normal since that left the file associations as they were before I installed Elements. It wasn't. I still get the "What should Firefox do with this file?" dialogue. I guess I could fix the problem using the steps in comment 3 but I'll wait a bit in case anyone can think up any experements to conduct while FF is horked.
I seem to have two entries in the registry that may be relevant.

  (Default)     REG_SZ  Adobe.SVGCtl
  Content Type  REG_SZ  image/svg-xml

  (Default)     REG_SZ  Adobe.SVGCtl
  Content Type  REG_SZ  image/svg-xml

Note image/svg-xml is the old MIME, type so these are almost certainly from the old version of ASV. (It should now be image/svg+xml.) I don't know what the Adobe.SVGCtl is thought.
So when you get this dialog, what MIME type is listed in it?  Or does Firefox kindly neglect to list MIME types in dialogs?  If so, what happens in a Seamonkey build?
Yeah, totally not useful.  Please try Seamonkey.

Or do NSPR_LOG_MODULES=HelperAppService:5 and attach the log here (or just read it yourself).
My home spun builds and SeaMonkey install (just installed using the Windows installer) aren't affected. They can all open local SVG files just fine. That seems strange since the problem started for me when I installed Elements back while using Deer Park. I thought that the upgrades to the betas and more recently the release candidates (using the Windows installers) would have fixed things, but they didn't. I'll try with NSPR_LOG_MODULES=HelperAppService:5 in RC2 in a bit.
0[272ff8]: Found extension 'svg' (filename is 'svg.svg', handling attachment: 0)

0[272ff8]: HelperAppService::DoContent: mime 'image/svg-xml', extension 'svg'
0[272ff8]: Getting mimeinfo from type 'image/svg-xml' ext 'svg'
0[272ff8]: Windows mime database: extension '.'
0[272ff8]: Extension lookup on '.' found: 0x1c8a0a0
0[272ff8]: OS gave back 0x1c8a0a0 - found: 1
0[272ff8]: Data source: Via type: retval 0x00000000
0[272ff8]: Extension 'svg' matches mime info: 1
0[272ff8]: MIME Info Summary: Type 'image/svg-xml', Primary Ext 'svg'
0[272ff8]: Type/Ext lookup found 0x1c8a0a0
0[272ff8]: Getting mimeinfo from type 'image/svg-xml' ext ''
0[272ff8]: Windows mime database: extension '.'
0[272ff8]: Extension lookup on '.' found: 0x261d7f0
0[272ff8]: OS gave back 0x261d7f0 - found: 1
0[272ff8]: Data source: Via type: retval 0x00000000
0[272ff8]: MIME Info Summary: Type 'image/svg-xml', Primary Ext 'svg'
That's after changing image/svg-xml to image/svg+xml in the registry entries I mentioned in comment 9. I see that there are still two occurances of image/svg-xml in the registry:

HKEY_CLASSES_ROOT\MIME\DataBase\Content Type\image/svg-xml
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\MIME\Database\Content Type\image/svg-xml
Using my home spun branch builds (the ones that happily render local SVG) all I get is:

0[3e56d0]: Windows mime database: extension ''
0[3e56d0]: 4.x Registry: extension ''
0[3e56d0]: Extension lookup on '' found: 0x0
0[3e56d0]: Ext. lookup for 'svg' found 0x327ac70
Hmm.  Could you attach the full log from the failing build?
comment 14 was all there was. The failing build is FF1.5 RC2 installed from the official win32 installer.
> comment 14 was all there was.

Hmm.  We already have a MIME type by the time DoContent is being called there, and the only way a file channel can come up with a type is by calling GetTypeFromFile, which GetTypeFromExtension, which checks mimeTypes.rdf and if it finds nothing in it calls nsOSHelperAppService::GetMIMEInfoFromOS (which logs).

So sounds like you have that bogus MIME type in your mimeTypes.rdf at this point.  Do you?
Attached file jwatt's mimeTypes.rdf
Indeed, the thing's absolutely riddled with image/svg-xml! I already did a search for that string in files in that profile using Windows built in search. Piece of junk turned up no results and I believed it.
Question is, how did it get there. Installing ASV 1.0 shouldn't cause that. And how can we stop this happening to other people?
It got there if Firefox added it; you'll have to look at the helper app UI code (the helper app dialog in particular) to see why and where that happened.  I bet it adds an entry any time it comes up and you pick some action (so that it can preselect that action next time?).  So the first time we got bad info from the OS we stashed it in mimeTypes.rdf, and after that mimeTypes.rdf overrides the OS.
But why would FF suddenly decide it needs the helper app after happily opening SVG files prior to installing ASV 1.0? Prior to that I had installed ASV 3 and that didn't cause any problems.
If there is no OS type association for the extension, we'll use our built-in fallback one, which has the right type...  

For ASV 3, it probably set the right association, so we used that.
Could this also be the reason for SVG not showing for me when it's embedded using <embed> without a 'type' attribute? (The embedded SVG shows fine when viewed standalone.) That would mean we look to the OS for MIME information rather than the HTTP headers sent with the <embed>ded file.
> That would mean we look to the OS for MIME information rather than the HTTP
> headers sent with the <embed>ded file.

For the 1.8 branch, that is exactly what we do.  On trunk we look at the headers.
Suddenly everything becomes clear. This probably explains most, if not all, of the mystery "I can't see SVG" posts to the mozillazine forums. Thanks bz!
No problem.

Sounds like the fix is to fix the OS associations and then go into Firefox helper app prefs and fix the associations there too...
Hmm, maybe we need a doc for that. I'm not sure about the details of either step though. Is there any reason not to just keep pointing people to the steps in comment 3? They seem to work.

BTW, the whole SVG test suite uses <embed> without a 'type' attribute, so any bugs or complaints that Moz doesn't render any of the test suite are probably dups of this bug.
The steps in comment 3 won't work if the OS association is still broken, will they?  Item 2 of comment 3 is the way to "go into Firefox helper app prefs and fix the associations there too" from comment 28, for what it's worth.
Those three steps always seem to fix the problem, without any need to mess with the OS file type associations. Also no file association exists for SVG in the dialogue from step 2 (see the attachment), so there's nothing to delete unless you've done step 1.
Er... so your mimeTypes.rdf has entries but they don't show up in the "download actions" thing?  File bugs on Ben as needed if so.  ;)
Summary: Browsing to local SVG file brings up Save As dialog → Loading local SVG brings up Save As dialog, and <embed>ded SVG without 'type' attribute fails
Hmm, okay I take it back. Those three steps seem to work for everyone...except me. Carrying out step 2 I get a list of exactly zero filename extensions, and the following error in the JavaScript console.

Error: uncaught exception: [Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsILocalFileWin.getVersionInfoField]"  nsresult: "0x80004005 (NS_ERROR_FAILURE)"  location: "JS frame :: chrome://browser/content/preferences/downloadactions.js :: anonymous :: line 251"  data: no]
Hey, if there are issues with the Firefox UI, please file Firefox bugs.  All the helper apps stuff got forked enough in Firefox that I have no idea how the UI works anymore, nor do I really care...
I did try to do the steps in comment 3 and also have an empty dialog as is shown in

So i cannot remove the link from SVG to the application I've choosen (is there a way to update this link manually - I cannot find any reference in the mime.rdf file nor in other files; what file/reg entry is used to store these settings?)

So Jonathan Watt isn't the only one having difficulties. As far i can remember i'd try to execute those steps when using Firefox 1.5 RC1.

Maybe it is interesting to note that I have both Firefox 1.07 (default browser) and Firefox 1.5 installed.
> what file/reg entry is used to store these settings?

The Gecko settings are in mimeTypes.rdf in the profile.

The OS settings are in various places in the registry; see nsOSHelperAppService.cpp (the Windows version) to see where we look.
i have had what seems to be basically the same thing ever since the first cairo build, ff1.5b1.

file assocations with svg or ANY plugins all stopped functioning for files from this build, on older builds everything is good, ( on the same machine at the same time.), BUT embeds still work, its only files that need to be recongised from the extension, local or web where the server doesn't set the type in the header.

same plugins with IE on same machine with same files, no problem.

found that the remove action button was not available on my plugins, tried comment 3 fix, managed to get remove action button to come on, removed it and reassociated with plugin, but now get infinite series of loads, all to the same tab, so just sits there with the title flipping between untitled and loading? removed the new association, all that happened is the remove action button becomes unavailable, assocation still shown, and i'm back to where i started!
(In reply to comment #32)
> Er... so your mimeTypes.rdf has entries but they don't show up in the "download
> actions" thing?  File bugs on Ben as needed if so.  ;)

They don't show in the "download actions" dialogue if NC:alwaysAsk="true" should have a link to this bug.
Duplicate of this bug: 368009
I'm a little unclear where this bug is right now; is it just about Windows, or a general bug for all OSes?
Assignee: general → nobody
QA Contact: ian → general
I have run into the same symptoms on Firefox 7.0.1 on Windows XP: Firefox would offer to download local .svg files. I found the svg fextension listed under a MIME type of application/x-octetstream in mimetype.rdf. Deleting that entry fixed the problem.
Duplicate of this bug: 908069
Note that this is a big problem in Firebug 1.12. In that version most of the icons used inside Firebug were replaced by SVG equivalents and now aren't displayed anymore for some users.[1][2][3]

See bug 908069 for more info and a test case.


Attached patch patchSplinter Review
Does this patch fix it?
Attachment #793933 - Flags: feedback?(sebastianzartner)
Never created a Firefox build by my own, so I first need to see how to do that.
Honza, if you want to you can also check that and give feedback.

Could we perhaps get a (Win32) try build?
Attachment #793933 - Flags: review?(bugs)
Attachment #793933 - Flags: review?(bugs) → review?(jst)
Seems OK when I tested it. If you want to play along at home...

Once completed, builds and logs will be available at:
I could finally compile a patched version and can confirm that it's working.

Attachment #793933 - Flags: feedback?(sebastianzartner)
Attachment #793933 - Flags: review?(jst) → review+
Assignee: nobody → longsonr
Closed: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla26
You need to log in before you can comment on or make changes to this bug.