User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:18.104.22.168) Gecko/2008070208 Firefox/3.0.1 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:22.214.171.124) Gecko/2008070208 Firefox/3.0.1 Every single time I attempt to open an SVG file from a local disk (so it's a file:/// URL), instead of displaying the file, the dialog box asking if you want to open the file or save it appears. Bizarrely, SVG files get displayed properly if retrieved from a http: url. In addition, if I use file>open file... then SVG files don't show up if "Images" is selected as the type. Possibly both these problems have the same cause. Reproducible: Always Steps to Reproduce: 1. Find an SVG file on a local disk, or put one there if you haven't already got one. 2. Go to File>Open File... menu item and navigate to the location of the aforementioned file. 3. Notice the SVG file only shows up with the "All Files" filter selected, not with "Images". 4. Open the file. Actual Results: Dialog box appears asking whether I want to open or save the file. Expected Results: The file should have been displayed as an image, like it is if accessed via HTTP.
Step 4 works for me. You will need to restrict the bug to #3 in the steps if the other STR are invalid due to user settings, otherwise it should be filed separately. Please create a fresh new profile and try loading a normal .svg file (not an .svgz file, which doesn't open, that's bug 432795) http://support.mozilla.com/en-US/kb/Managing+profiles
If you still have problems with .svg files you should try the steps listed in bug 303581 comment 3
> If you still have problems with .svg files you should try the steps listed in > bug 303581 comment 3 Nope. Those steps involve UI that was changed between that version of firefox and ff3. The only way to remove an entry from the Tools>Options>Applications list appears to be to edit mimeTypes.rdf, as another comment pointed out. Reading the entire discussion indicated that if HKCR\.svg\Content Type is set to image/svg-xml, Firefox exhibits the incorrect behaviour. Inserting the correct value fixed it. The problem is thus reduced to that registry value being incorrectly set. Perhaps it should be corrected at install time, if the problem is common.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.