Open Bug 241574 Opened 20 years ago Updated 2 years ago

Save filepicker should not rely on registry to filter file list for a known file type.

Categories

(Firefox :: File Handling, defect)

Product:
Firefox
Component:
File Handling
Platform:
x86
Windows Server 2003
Type:
defect

Tracking

()

People

(Reporter: alexeyc2003, Unassigned)

Details

(Keywords: regression) 

Builds affected:
Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.7b) Gecko/20040322
Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.8a) Gecko/20040423
Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.8a) Gecko/20040424
Firefox/0.8.0+

This is a regression that happened 2-3 months ago. It did not exist in Firefox
0.8 release. It already existed in 20040322 Mozilla build.

To reproduce:
1. Create 2 JPEG files in the same directory, one with extension .jpg and
another - .jpeg.
2. Open the .jpeg file in Mozilla.
3. Navigate the Save Image filepicker into the same directory and observe that
filepicker lists both files.
4. Repeat the same with .jpg file and see that filepicker doesn't list the .jpeg
file, and only shows .jpg.

Observed behaviour: When saving .jpg images filepicker does not list .jpeg files.
Expected behaviour: Both .jpg and .jpeg files listed in filepicker, just like
it's done when you save .jpeg images.

I'm not sure wether other OSes or other file types apart from JPEG are affected.
so if you use a firefox 0.8 build today, and follow your steps to reproduce,
this is happening?

>I'm not sure wether other OSes

I'd guess not...

Of interest would be your registry entries for:
HKCR\.jpeg\Content Type
HKCR\.jpg\Content Type
and:
HKCR\MIME\Database\Content Type\image/jpeg

As I said this bug does not exist in Firefox 0.8.

I also tried .jpe extension.

Saving .jpg:
New: lists only .jpg files
Old: lists both .jpg and .jpeg but not .jpe

Saving .jpeg:
New: lists both .jpg and .jpeg but not .jpe
Old: lists both .jpg and .jpeg but not .jpe

Saving .jpe:
New: lists both .jpg and .jpe but not .jpeg
Old: lists both .jpg and .jpeg but not .jpe

Also when saving .jpe in old builds, it wants to append .jpeg extension to the
file name: as so: .jpe.jpeg. SO old builds have no support for .jpe at all.

Also during save in old builds filepicker displays type as "JPEG Image" while
new builds use the type name from the registry.

I also tried .txt and .text extensions, which unlike JPEG have different file
type names in my registry. Old builds are always listing both file types, while
new builds don't list .text at all even if the file being saved is .text.

So obviously Mozilla filepicker has moved from recognising filetypes internally,
to relying on Windows registry. And since Windows can have only one extension
per MIME type, this has badly affected the functionality.

I accept that the the new functionality may be useful when saving MIME types
unknown to Mozilla, but it is bad for known file types.

I now always have to manually type in *.* to get all files listed during my
saving. Which is quite annoying compared to old behaviour.

Changing summary:
From: Save Image filepicker does not recognise .jpeg extension as JPEG files
To: Save filepicker should not rely on registry to filter file list for a known
file type.
Summary: Save Image filepicker does not recognise .jpeg extension as JPEG files → Save filepicker should not rely on registry to filter file list for a known file type.
CCing James Turner who has worked on bug 125216 and might be familiar with
relevant code.

alexey, could you tell us what your registry settings are for the keys mentioned
in comment 1?
[HKEY_CLASSES_ROOT\MIME\Database\Content Type\image/jpeg]
"AutoplayContentTypeHandler"="PicturesContentHandler"
"CLSID"="{25336920-03F9-11cf-8FD0-00AA00686F13}"
"Extension"=".jpg"
"Image Filter CLSID"="{607fd4e8-0a03-11d1-ab1d-00c04fc9b304}"

[HKEY_CLASSES_ROOT\MIME\Database\Content Type\image/jpeg\Bits]
"0"=hex:02,00,00,00,ff,ff,ff,d8

[HKEY_CLASSES_ROOT\.jpg]
"Content Type"="image/jpeg"

[HKEY_CLASSES_ROOT\.jpeg]
"Content Type"="image/jpeg"

[HKEY_CLASSES_ROOT\.jpe]
"Content Type"="image/jpeg"

why shouldn't we rely on the registry?

if i mark .newjpeg as image/jpeg (in my registry),
why shouldn't mozilla display *.newjpeg in addition to whatever other things are
image/jpeg? :)

(I can think of one reason not to do this, but i don't consider it to be a good
reason.)
(In reply to comment #6)
> why shouldn't we rely on the registry?
> 
> if i mark .newjpeg as image/jpeg (in my registry),
> why shouldn't mozilla display *.newjpeg in addition to whatever other things are
> image/jpeg? :)

Because while .newjpeg is mapped to image/jpeg (in registry), image/jpeg is not
mapped to .newjpeg (in registry). And Mozilla filepicker filters by MIME type.
So the bug is exactly about the opposite: Mozilla not displaying *.newjpeg even
though it is mapped to image/jpeg in registry.

It is a many-to-one-to-one scenario.
The extensions tell which MIME type they belong to, the type does not tell which
extensions belong to it except for one. Therefore Mozilla currently lists only
one extension and not all of them. Before it did not rely on registry and used
to correctly list different file extensions for the same type.

i know what it is. i'm asking why you think retreating to hard coding
jpeg,jpe,jpg is better than actually building a correct list from the system.
I simply noticed the regression.
If a better way can be implemented - great.
But for now it's broken, while it worked before.
So I would rather have it reversed to the old working way, instead of this new
broken way.
(In reply to comment #7)
> Before it did not rely on registry and used
> to correctly list different file extensions for the same type.

let me point out that no such change happened. at least not intentionally.
(In reply to comment #10)
> let me point out that no such change happened. at least not intentionally.

0.8 uses name "JPEG Image" for this file type.
New builds use different name, taken from the registry.
0.8 always lists both .jpg and .jpeg files.
New builds list only the extension given by registry for image/jpeg type.

I don't know, but the change looks quite obvious.

(In reply to comment #11)
> I don't know, but the change looks quite obvious.

well let me rephrase. 0.8 should have also taken the name from the registry, it
had code to do that.

Could have the new folderpicker from bug 232443 affected filepicker too?

I think not... that bug looks like it really only affected folders.
Assignee: file-handling → nobody
QA Contact: ian → file-handling
Product: Core → Firefox
Version: Trunk → unspecified
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.