Closed Bug 215889 Opened 21 years ago Closed 11 years ago

Open file dialog should have .svg and .svgz files as option in drop down "Files of Type" list.

Categories

(Toolkit :: General, defect)

Product:
Toolkit
Component:
General
Platform:
x86
Linux
Type:
defect
Priority:
Not set
Severity:
minor

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: darryl, Unassigned)

References

Details

Attachments

(2 files)

Add SVG extension to image filter
461 bytes, patch
Details | Diff | Splinter Review
fix (un-bitrotted)
1.24 KB, patch
Details | Diff | Splinter Review 
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5b) Gecko/20030809
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5b) Gecko/20030809

In an SVG enabled build, the Open File dialog should know about svg file
extensions.  In the drop down list of file types and extensions, there should be
an entry for SVG files (.svg .svgz) or those extensions should be added to the
list of image type extensions.

Reproducible: Always

Steps to Reproduce:
Version: Trunk → Other Branch
Status: UNCONFIRMED → NEW
Ever confirmed: true
That would ideally be fixed by adding those file name extensions to

http://lxr.mozilla.org/seamonkey/source/toolkit/components/filepicker/locale/filepicker.properties#10
http://lxr.mozilla.org/seamonkey/source/xpfe/components/filepicker/res/locale/en-US/filepicker.properties#10

but we can't do that until SVG is built by default. So unless we can do
something else like change the following files I don't see this happening. Given
that you can use All Files to allow you to pick the file this isn't high priority.

http://lxr.mozilla.org/seamonkey/source/xpfe/components/filepicker/src/nsFilePicker.js#157
http://lxr.mozilla.org/seamonkey/source/widget/src/xpwidgets/nsBaseFilePicker.cpp#148
According to timelyx and biesi the right way to fix this is to rewrite the
browser File > Open code to obtain the list of extensions for the filters by
enumerating the gecko-content-viewers category for supported mime types, and
obtain the file extensions from them. (So the lists in filepicker.properties
would be discarded/not used.) The problem that would have to be overcome to do
this is that on Windows you can only get from one mime type to one extension,
and from one extension to one mime type - unless someone can think of a way
around this? 
Mass reassign of SVG bugs that aren't currently being worked on by Alex to
general@svg.bugs. If you think someone should be assigned to your bug you can
join the #svg channel on mozilla.org's IRC server ( irc://irc.mozilla.org/svg )
where you can try to convince one of the SVG hackers to work on it. We aren't
always there, so if you don't get a response straight away please try again later.
Assignee: alex → general
SVG files are not shown when either XML, text, or images is chosen.
Opera 9.01 did add SVG in the filter of the file dialog
Another simpler way would be conditionally add a vector graphics entry to the list depending of whether it's an svg build since all the image types in the current list a bitmap graphics.

(Alternatively always add it and grey it out if not available.)

This may be a good way highlight the presence of svg, a format ppl are little familiar with but that is often more suitable that a bitmapped image.



I think at http://www.xulplanet.com/references/xpcomref/ifaces/nsIFilePicker.html#const_filterApps
PRInt32  	 filterSVG  	= 128
should be added


Reading
http://www.xulplanet.com/references/xpcomref/ifaces/nsIFilePicker.html#method_appendFilter
i think somewhere (i don't know where)
appendFilter("SVG Files","svg; svgz");
should be added

I suspect that's not all
This seems rather straightforward for "svg" file extension. On the other hand, this doesn't seem the case for "svgz" file extension (gzip compressed format for SVG). If one tries to drag an "svgz" file to Firefox (simulating "File"/"Open" action) the famous "XML Parsing Error: not well-formed" error is displayed due to "Content-Encoding" header not being set for local files.

IMHO, this issue could be partially addressed by allowing open of "svg" file extension now and dealing with "svgz" extension later - probably by creating a specific issue for it.

Creating a new issue makes even more sense if the "svgz" somehow broken behavior for local files is related to a more general FILE protocol subject. I also take the opportunity to link with bug 308153's comment 7 [1].

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=308153#c7
Only SVG (not SVGZ) for now would already be great
Patch for http://lxr.mozilla.org/seamonkey/source/  I hope these sources are used for FireFox3 Beta 1, which still has this bug.
Attachment #322093 - Flags: approval1.9?
FireFox RC1 in Windows 2000 is unable to detect SVG as image extension as well.
techtonik, your patch fixes a different bug to this one. It would be better if you raised a new bug for it and put your patch in there.

you also need to get it reviewed by a toolkit peer before asking for 1.9 approval.
Robert, I would be glad to open a new bug report, but I have no idea what is this different issue that is fixed by this patch. If http://lxr.mozilla.org/seamonkey/source/ is wrong path for FF3 then point me to the right sources.

You are right and I was wrong. You have fixed the right file.

You still need a toolkit peer review though.
Attachment #322093 - Flags: ui-review?(benjamin)
Comment on attachment 322093 [details] [diff] [review]
Add SVG extension to image filter

I'll delegate to beltzner, but: this is in a localized file and we're in string freeze, so this won't make 1.9.0.x at all (but why is this a localized file!?)
Attachment #322093 - Flags: ui-review?(benjamin)
Attachment #322093 - Flags: ui-review?(beltzner)
Attachment #322093 - Flags: approval1.9?
Probably because filters and filter labels (that should be localized) are added into UI at the same time from this file and there is no better place for them to stick together.
FWIW there is this note at the top of the file

# LOCALIZATION NOTE FILE
# --do not localize the extensions, only the titles

"SVG" is "SVG" in every locale.
Whatever "Files" becomes is the same as the other entries (plus i think should be removed from all entries anyhow)
Assignee: general → nobody
QA Contact: bbaetz → general
(In reply to comment #9)
> This seems rather straightforward for "svg" file extension. On the other hand,
> this doesn't seem the case for "svgz" file extension (gzip compressed format
> for SVG). If one tries to drag an "svgz" file to Firefox (simulating
> "File"/"Open" action) the famous "XML Parsing Error: not well-formed" error is
> displayed due to "Content-Encoding" header not being set for local files.

Regarding the ".svgz" issue, I'd say this issue should depend on bug 52282... :-)


Also, this issue is related with bug 455086 and, in my opinion, should be coordinated with it.
Comment on attachment 322093 [details] [diff] [review]
Add SVG extension to image filter

Not sure if this is still relevant, am sure I'm not the right reviewer :)
Attachment #322093 - Flags: ui-review?(mbeltzner)
Benjamin Smedberg  delgated this to you on 2008-05-23

It's taken you 5 years without comment to say you're not sure whether it's still relevant.

May be in 5 years you'll be sure?

FFox can open and display svg , why the hell isn't it in the list of file extensions when I want to open something?

Is this really that complicated an issue?
(In reply to ffux from comment #22)
> It's taken you 5 years without comment

Note that this was (apparently) non-actionable at that time, because we were in a string-freeze.  It seems to have just dropped off of people's radars after that.

(Also, beltzner no longer works for Mozilla, so I don't think he's been actively doing reviews for some time now; and as he said, this particular bug doesn't make sense for him to review.)

> to say you're not sure whether it's
> still relevant.

IIUC, he was simply *not commenting* on the relevance -- he wasn't implying that it's not relevant.

> FFox can open and display svg , why the hell isn't it in the list of file
> extensions when I want to open something?

It probably should be. The attached patch simply needs review sign-off from someone in toolkit (the area of code that's being modified) as noted in comment 13 & comment 15.
Component: SVG → General
Product: Core → Toolkit
Version: Other Branch → Trunk
Also, the patch doesn't actually apply anymore -- the file it touches has been moved, and the tweaked line of that file has been changed elsewhere.

Here's a new patch. Testing locally, & I'll request review after verifying that it works.
Assignee: nobody → dholbert
Status: NEW → ASSIGNED
Actually, this already works in my Linux nightly -- File|Open, change All Files to Image Files, browse to a directory that I know contains a .svg file --> the SVG file is correctly listed.

(Maybe this is because on Linux we're using the native file-picker, which has its own definition of "Image Files" (and their definition includes SVG files)?)

Is this still broken on non-Linux operating systems?

Mozilla/5.0 (X11; Linux x86_64; rv:21.0) Gecko/20130122 Firefox/21.0
(In reply to Daniel Holbert [:dholbert] from comment #23)
> (In reply to ffux from comment #22)
> > to say you're not sure whether it's
> > still relevant.
> 
> IIUC, he was simply *not commenting* on the relevance -- he wasn't implying
> that it's not relevant.

Right, beltzner's comment is simply that he doesn't know if a five year old patch is still applicable.

As it happens it isn't since this was fixed nearly three years ago by bug 377624.

> > FFox can open and display svg , why the hell isn't it in the list of file
> > extensions when I want to open something?
> 
> It probably should be. The attached patch simply needs review sign-off from
> someone in toolkit (the area of code that's being modified) as noted in
> comment 13 & comment 15.

I do see .svg and .svgz in the list in file - open, if you don't then you should probably file a new bug on it so we can figure out what is going wrong for you.
Assignee: dholbert → nobody
Status: ASSIGNED → NEW
Depends on: 377624
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
(In reply to Daniel Holbert [:dholbert] from comment #25)
> Is this still broken on non-Linux operating systems?
> 
> Mozilla/5.0 (X11; Linux x86_64; rv:21.0) Gecko/20130122 Firefox/21.0

WFM on Win7
Comment on attachment 705590 [details] [diff] [review]
fix (un-bitrotted)

>-imageFilter=*.jpe; *.jpg; *.jpeg; *.gif; *.png; *.bmp; *.ico; *.svg; *.svgz; *.tif; *.tiff; *.ai; *.drw; *.pct; *.psp; *.xcf; *.psd; *.raw
>+imageFilter=*.jpe; *.jpg; *.jpeg; *.gif; *.png; *.bmp; *.ico; *.svg; *.svgz; *.tif; *.tiff; *.ai; *.drw; *.pct; *.psp; *.xcf; *.psd; *.raw; *.svg

Sure enough, it's right there in the file that my patch touches ----^ ----^
:)

Thanks, Mossop & Ryan!
Does svgz actually work in file open. I'd expect it not to and that it should be removed until it does.
It doesn't really work, no -- if I do file|open and pick a svgz image, we pop up a dialog for opening it w/ an external app.

However, I suspect we need it to be included in order for image-specific file-upload controls to successfully accept SVGZ. (I expect that it works in that context, where we aren't directly trying to open the file, but instead are just picking a file.)  That seems to be what bug 377624 (which added it) was geared towards.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: