Attachment will lose file extension when renamed in "Save as" dialogue and "hide extension for known file types" is set (default for Windows Explorer)

RESOLVED FIXED in Thunderbird 31.0

Status

defect
RESOLVED FIXED
12 years ago
5 years ago

People

(Reporter: info, Assigned: sshagarwal)

Tracking

(Blocks 1 bug, 5 keywords)

Dependency tree / graph
Bug Flags:
wanted-thunderbird3 ?

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [patchlove][ux-papercut?][better STR in comment 19][gs][dupetome], )

Attachments

(1 attachment, 9 obsolete attachments)

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X; hu; rv:1.8.1.11) Gecko/20071127 Firefox/2.0.0.11
Build Identifier: Thunderbird 2.0.0.9 

I received a new mail with attachment "test.zip".
I save as attachment and the opened window i chose a directory and i give new name to the file (for example: test1). The saved file is only test1, not have (lost the zip) extension. 

Reproducible: Always

Steps to Reproduce:
1. save a attachment
2 [review]. rename / chose another name to the file
I think that's expected... I know I wouldn't want thunderbird refusing to save with the name I provided - with changed extension or even without. If you don't want to lose the extension, don't remove it in the rename box.
Status: UNCONFIRMED → RESOLVED
Closed: 12 years ago
Resolution: --- → INVALID
The save as window don't hint the file extension. I just see the filename in the upper box and the file type in the lower box. The file type is fixed (all files), I can't change. The filename box shows the attachment filename without extension. When i choose another name to the file and click save, the thunderbird don't save the extension, only the typed "new" name. If I leave the original file name, everything is OK, thunderbird save the file with extension.
For me its not problem because I use Macintosh, but the windows users can't make a distinction between files without their extension. 
 
  
Status: RESOLVED → UNCONFIRMED
Resolution: INVALID → ---
Ah, this is of course only a problem if windows is set to hide known extensions. Which is the default :/
I see! Had i know if I change this setting on the windows, the filename box show the extension. Its correct! I dont know that not thunderbird problem.
What we do now? Leave this problem bug or change the status fixed?
Version: unspecified → 2.0
I think it's a valid bug after all. 

If someone is interested the code should be around here:
http://lxr.mozilla.org/mozilla/source/mailnews/base/src/nsMessenger.cpp#900

Maybe it would help to set the defaultExtension of the filepicker.

Could also be a filepicker bug I suppose...
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: The attachment lost its extension when I rename it in the "save as" windows → The attachment lost its extension when I rename it in the "save as" windows and hide extension for known file types is set
Not 2.0 only.
Version -> Trunk
Version: 2.0 → Trunk
Duplicate of this bug: 431101
Flags: wanted-thunderbird3?
This also appears if you are saving multiple files with the same name.

On the second (and subsequent) file, it correctly displays a popup stating that the file already exists. If you chose not to overwrite it then you are shown the save as dialogue with the missing filename as above.

If all I want to add is a '2' or '3' etc to the end of the file name this is particularly counterintuitive.
Duplicate of this bug: 467885
Has there been any progress on this bug? It has been a long time and the problem still persists in Thunderbird 3.0
Duplicate of this bug: 540840
Additional information from duplicate bug 540840:

This is not only confusing for users, it is also inconsistent: if you get to
the file picker through the action/open dialog (instead of Save As), the filetype
filter does reflect the file type of the attachment and changing the filename
will not affect the filename extension.

In short:
File->Attachments->foo.doc->Save As... [BROKEN]
File->Attachments->foo.doc->Open->Save File [CORRECT]
Has there been any progress on this bug?
This bug is fixed for me on Thunderbird 5.0
This bug is does not fixed for me on Thunderbird 5.0
Not fixed yet on version 8.

10 minor problems may became one big problem, and people refuse to use Thunderbird.

It should be fixed in my opinion.
How to fix this bug? How can I help? I'm not a programmer
(In reply to Anton from comment #17)
> How to fix this bug? How can I help? I'm not a programmer

Anton, one way of helping would be to ensure the bug report of comment 0 is presented in the right format, with concise Steps to reproduce, Actual Result, Expected Result (as I'll show below in comment 19). Bugs not following that format are less likely to be fully understood and receive action.
Confirming for Trunk 11.0a1 (today's), on Windows XP (can't test other versions right now)

STR

1) on Windows XP, ensure you have Windows Explorer's default setting "hide file extensions for known file types" ENabled (http://www.wikihow.com/Disable-Hidden-File-Extensions-in-Windows-XP)
2) from any attachment's context menu, choose "Save As..."
3a) save using the suggested extionless file name (ensure there's no existing file with same name)
3b) modify the suggested extensionless file name before saving (e.g. for attachment test.zip with base name "test", make it "test1")
3c) add extension to modified base name before saving (e.g. "test1.zip")

Actual result
3a) saving with /suggested/ extensionless file name works as expected (saves "test.zip")
3b) saving with /modified/ extensionless file name will save attachment without extension (saves "test1") - this bug
3c) manually adding the extension saves the attachment as expected (non-trivial workaround)

Expected result
3b) when saving with /modified/ base name, TB needs to ensure file extension is added, as in 3a).

Ideas for fixing:
- perhaps set default file type filter of file picker to match attachment extension
- add secondary file type filter to allow for "all files" if user wants to change extension while saving

I've added Bug 579473 alias attachuxtracker to the "Blocks" field of this bug.
So this bug is added to the "Depends on" field of attachuxtracker. Which ensures the right people can find it in the right place. However, developers are few and time is a scarce commodity...

Can somebody confirm if this happens on newer versions of Windows, too?
Whiteboard: [better STR in comment 19]
Summary: The attachment lost its extension when I rename it in the "save as" windows and hide extension for known file types is set → attachment will lose file extension when renamed in "save as" dialogue and "hide extension for known file types" is set (default for windows explorer)
Duplicate of this bug: 702550
I confirm the behavior on Windows 7 32bits with Thunderbird 9.01
Please fix this bug, it is present since version 1.0 - this is more than 5 years!
Many people complain that they can not open a file without extension.
Bug 514497 might help...
Win 7 64bit, Thunderbird 11.0.1 bug exists.
Duplicate of this bug: 596204
Duplicate of this bug: 746525
Duplicate of this bug: 804196
Win8 64bit Thunderbird 17.0.6

Bug still exists. This is appalling, please fix this bug. I've lost an hours work because of it.
Thunderd 24. Bug still exists :'(
Anyone out there who could try to fix this after all?
Can you CC someone who might know more about native OS dialogues?

This is a small but ever-recurring and very annyoing issue to affected users, who will face problems to open attachments after these have lost their file extensions via normal use patterns with default settings in Windows OS as reported by this bug. Note that with windows default settings, users are never required to enter extension manually for known extensions.

Users in getsatisfaction reports are also annoyed (it's impossible to search systematically on GS, so I just tagged a few and then stopped).

ux-consistency: per Comment 12, we're inconsistent because we DO add extensions in other similar dialogues.

ux-mode-error: UI is in a different state than expected (because such dialogues usually preserve extensions, even in TB)

ux-error-prevention: as a result of ux-mode-error, users are likely to run into this error as they are not aware that they need to add extension manually for this very scenario - we should prevent that by adding/preserving extension

ux-trust: saving attachments under different file name ("Save as") is a basic everyday function of a mailer. Such problem, albeit small technically, can annoy average users very much as they might not find out how to work around it, and then it's a big problem to them as the files without extension cannot be opened easily and they will even appear lost when you try to open them with default filters of target applications (e.g. Word will only show word.docs, so file without extension will not show up). Users will blame us for that and it can undermine trust in our application, see Comment 16:

(In reply to Eduardo Luis from comment #16)
> 10 minor problems may became one big problem, and people refuse to use
> Thunderbird.
> It should be fixed in my opinion.

(In reply to avmaksimov from comment #29)
> Thunderd 24. Bug still exists :'(

Our apologies to affected users. TB is now mostly maintained by volunteers, so it's not easy to find contributors with the right skillset, time, and willingness to fix this particular bug out of all bugs...
Whiteboard: [better STR in comment 19] → [patchlove][ux-papercut?][better STR in comment 19]
(In reply to Thomas D. (away till 23rd Oct) from comment #30)
> Users in getsatisfaction reports are also annoyed (it's impossible to search
> systematically on GS, so I just tagged a few and then stopped).
http://getsatisfaction.com/mozilla_messaging/tags/bug_414865
Whiteboard: [patchlove][ux-papercut?][better STR in comment 19] → [patchlove][ux-papercut?][better STR in comment 19][gs]
Duplicate of this bug: 879834
Summary: attachment will lose file extension when renamed in "save as" dialogue and "hide extension for known file types" is set (default for windows explorer) → Attachment will lose file extension when renamed in "Save as" dialogue and "hide extension for known file types" is set (default for Windows Explorer)
Whiteboard: [patchlove][ux-papercut?][better STR in comment 19][gs] → [patchlove][ux-papercut?][better STR in comment 19][gs][dupetome]
Duplicate of this bug: 871198
Actually, this is a regression of ancient bug 57113, which at the time was declared fixed by bug 117269. Looking into these two might provide some insights and starting points in code.
Blocks: 57113, 117269
Keywords: regression
Thunderd 24.2.0 Bug still exists. Please fix it
Posted patch Patch v1 (obsolete) — Splinter Review
Possible fix.
Is this bug specific to Windows? 
If yes, should I use #ifdefs to determine if the platform is Windows and then work, else skip?
Attachment #8369388 - Flags: review?(neil)
Attachment #8369388 - Flags: review?(mkmelin+mozilla)
Comment on attachment 8369388 [details] [diff] [review]
Patch v1

Review of attachment 8369388 [details] [diff] [review]:
-----------------------------------------------------------------

Wow, Suyash, you'll be the hero of all those who have been suffering from this bug since time immemorial...

I won't do a full review, just some things I noticed.
I'm not sure if this bug is only seen on Windows (probably yes).

::: mailnews/base/src/nsMessenger.cpp
@@ +817,5 @@
>    filePicker->Init(mWindow, saveAttachmentStr,
>                     nsIFilePicker::modeSave);
>    filePicker->SetDefaultString(defaultDisplayString);
>    filePicker->AppendFilters(nsIFilePicker::filterAll);
> +  nsString extension = NS_ConvertUTF8toUTF16(aDisplayName);

Should we use defaultDisplayString instead of aDisplayName?

nsString extension = NS_ConvertUTF8toUTF16(defaultDisplayString);

I understand defaultDisplayString is converted and sanitized version of aDisplayName (the full file name), see line 813:
ConvertAndSanitizeFileName(aDisplayName, defaultDisplayString);

Assuming there's a reason to convert and sanitize the filename, it looks like a risk to use the unsanitized aDisplayName filename for getting the extension. (It would also be interesting to know what exactly "sanitizing" does here, e.g. what it does to pseudo "file.extensions with spaces", see below.)

@@ +822,5 @@
> +  // Check whether the attachment has some extension or not
> +  // and set it as the default extension.
> +  if (extension.RFind(".") != kNotFound)
> +  {
> +    extension = Substring(extension, extension.RFind(".") + 1);

Please add a check after this line to ensure extension doesn't have spaces (pseudo-code):

if extension contains " " then extension = ""

Without that sanity check, this will fail/behave odd for edge cases like file names that happen to have a dot somewhere in the middle, spaces thereafter, and no extension:

"2014.02.03 Valid File Name without extension"

So your extension will become ".03 Valid File Name without extension" which is certainly undesired in 99.5% of usecases. Windows XP doesn't even hide such "extensions with spaces", so there's no need for us to add them.

http://stackoverflow.com/questions/5446509/can-spaces-exist-within-a-file-extension

There are no strict rules for extensions, but by convention, I think we can agree that no sane coder will use spaces in their extensions, and we'll still save even "file with.extension with space" correctly and losslessly but just not show it in file type box as extension when saving.

@@ +823,5 @@
> +  // and set it as the default extension.
> +  if (extension.RFind(".") != kNotFound)
> +  {
> +    extension = Substring(extension, extension.RFind(".") + 1);
> +    filePicker->SetDefaultExtension(extension);

make sure this line works or is if'ed out when extension is empty for edge cases after sanity check above
Comment on attachment 8369388 [details] [diff] [review]
Patch v1

I didn't test the patch on an actual attachment, but I played around with the filepicker object in the Error Console and was able to reproduce the problem.

>   filePicker->AppendFilters(nsIFilePicker::filterAll);
[Hmm, this file picker makes no sense to me, even when the filters are set to, say, text files, it's still not adding the extension for me.]

>+  nsString extension = NS_ConvertUTF8toUTF16(aDisplayName);
NS_ConvertUTF8toUTF16 is only used in this way for a temporary parameter. In this case you could use NS_ConvertUTF8toUTF16 extension(aDisplayName) but in fact you don't need to convert the extension to search for the . anyway.

>+  if (extension.RFind(".") != kNotFound)
A leading . doesn't count as an extension, and you're only looking for a single character, not a string, so you should be using FindChar here, as it allows you to skip the first character in case it's a .

>+    extension = Substring(extension, extension.RFind(".") + 1);
>+    filePicker->SetDefaultExtension(extension);
Pass the substring directly to the file picker, although as it happens, the string gets shared, so it's not as dire as it looks at first sight.
Attachment #8369388 - Flags: review?(neil)
Attachment #8369388 - Flags: review-
Attachment #8369388 - Flags: feedback+
Posted patch Patch v2 (obsolete) — Splinter Review
Possible fix covering the issues mentioned in the reviews.
Attachment #8369388 - Attachment is obsolete: true
Attachment #8369388 - Flags: review?(mkmelin+mozilla)
Attachment #8372140 - Flags: review?(neil)
Attachment #8372140 - Flags: review?(mkmelin+mozilla)
(In reply to Suyash Agarwal (:sshagarwal) from comment #39)
> Created attachment 8372140 [details] [diff] [review]
> Patch v2
> 
> Possible fix covering the issues mentioned in the reviews.

How does this patch address the "leading dot in file name" problem mentioned in comment 38?
Can you (or anyone) pls answer this question from comment 37, or correct me if I'm wrong?

+  NS_ConvertUTF8toUTF16 extension(aDisplayName);

> Should we use defaultDisplayString instead of aDisplayName?
> 
> nsString extension = NS_ConvertUTF8toUTF16(defaultDisplayString);
> 
> I understand defaultDisplayString is converted and sanitized version of
> aDisplayName (the full file name), see line 813:
> ConvertAndSanitizeFileName(aDisplayName, defaultDisplayString);
> 
> Assuming there's a reason to convert and sanitize the filename, it looks
> like a risk to use the unsanitized aDisplayName filename for getting the
> extension. (It would also be interesting to know what exactly "sanitizing"
> does here, e.g. what it does to pseudo "file.extensions with spaces", see
> below.)
(In reply to Thomas D. from comment #40)
> +  NS_ConvertUTF8toUTF16 extension(aDisplayName);
> 
> > Should we use defaultDisplayString instead of aDisplayName?
> > 
> > nsString extension = NS_ConvertUTF8toUTF16(defaultDisplayString);
> > 
> > I understand defaultDisplayString is converted and sanitized version of
> > aDisplayName (the full file name), see line 813:
> > ConvertAndSanitizeFileName(aDisplayName, defaultDisplayString);
> > 
> > Assuming there's a reason to convert and sanitize the filename, it looks
> > like a risk to use the unsanitized aDisplayName filename for getting the
> > extension. (It would also be interesting to know what exactly "sanitizing"
> > does here, e.g. what it does to pseudo "file.extensions with spaces", see
> > below.)

Good point. We could hope that the extension itself does not contain any characters needing to be sanitized, but yes, probably just use the defaultDisplayString to be safe.
Comment on attachment 8372140 [details] [diff] [review]
Patch v2

Review of attachment 8372140 [details] [diff] [review]:
-----------------------------------------------------------------

::: mailnews/base/src/nsMessenger.cpp
@@ +821,5 @@
> +      extension.Find(" ", false, extensionIndex, -1) == kNotFound)
> +  {
> +    filePicker->SetDefaultExtension(
> +      Substring(extension, extensionIndex + 1));
> +  }

What if the extension is hidden, but the user still writes the extension into the filename to be safe?
Think original file is "foo.zip" and user writes "file.zip". Does the picker handle that internally and returns "file.zip", or does it return "file.zip.zip" ?
(In reply to :aceman from comment #42)
> What if the extension is hidden, but the user still writes the extension
> into the filename to be safe?
> Think original file is "foo.zip" and user writes "file.zip". Does the picker
> handle that internally and returns "file.zip", or does it return
> "file.zip.zip" ?
Ya, this is handled nicely. I tried this a number of times.
If the original file is abc.xyz with xyz hidden, and the user saves it as pqr.mno where mno may or may not be equal to xyz. The file is saved as pqr.mno
(In reply to Thomas D. from comment #40)
> How does this patch address the "leading dot in file name" problem mentioned
> in comment 38?
My mistake, I thought since FindChar skips the first character, RFindChar will skip it too. How stupid of me! :P 
(Quoting neil@parkwaycc.co.uk from comment #38)
> >+  if (extension.RFind(".") != kNotFound)
> A leading . doesn't count as an extension, and you're only looking for a
> single character, not a string, so you should be using FindChar here, as it
> allows you to skip the first character in case it's a .

So, yes. This is a problem. I'll just fix this.

> Can you (or anyone) pls answer this question from comment 37, or correct me
> if I'm wrong?
> 
> > Should we use defaultDisplayString instead of aDisplayName?
> > nsString extension = NS_ConvertUTF8toUTF16(defaultDisplayString);
> > 
> > I understand defaultDisplayString is converted and sanitized version of
> > aDisplayName (the full file name), see line 813:
> > ConvertAndSanitizeFileName(aDisplayName, defaultDisplayString);

Possibly yes.

(Quoting :aceman from comment #41)
> Good point. We could hope that the extension itself does not contain any
> characters needing to be sanitized, 

(In reply to :aceman from comment #41)
> but yes, probably just use the
> defaultDisplayString to be safe.

Sure. I don't mind doing that. Its just that I don't want to miss anything from the extension part. 
In fact, I wanted to use contentType, but for some application specific extensions, it showed just application instead of the file extension. So, maybe its possible that defaultDisplayString misses the extension on windows (though, I don't think that will ever happen). I wanted it crude so that I can just scoop out the extension part from the end. But if you all still want that sanitized name should be used, please let me know.

Thanks.
Posted patch Patch v2.2 (obsolete) — Splinter Review
Okay so this bypasses the "leading dot in filename" problem.
But, if the filename has a leading dot and "hide known extensions" option check in Windows explorer. TB doesn't show any filename while saving the attachment(s).
This happens both, with and without this patch. So, not a problem with this bug.
That is, probably a filepicker bug.

Please let me know if that is to be fixed here itself or in a followup bug.

Thanks.
Attachment #8372140 - Attachment is obsolete: true
Attachment #8372140 - Flags: review?(neil)
Attachment #8372140 - Flags: review?(mkmelin+mozilla)
Attachment #8372309 - Flags: review?(neil)
Attachment #8372309 - Flags: review?(mkmelin+mozilla)
Attachment #8372309 - Flags: feedback?(bugzilla2007)
Attachment #8372309 - Flags: feedback?(acelists)
Comment on attachment 8372309 [details] [diff] [review]
Patch v2.2

Review of attachment 8372309 [details] [diff] [review]:
-----------------------------------------------------------------

Looks good now, thanks.

::: mailnews/base/src/nsMessenger.cpp
@@ +812,5 @@
>    filePicker->Init(mWindow, saveAttachmentStr,
>                     nsIFilePicker::modeSave);
>    filePicker->SetDefaultString(defaultDisplayString);
>    filePicker->AppendFilters(nsIFilePicker::filterAll);
> +  NS_ConvertUTF8toUTF16 extension(aDisplayName);

Try to use defaultDisplayString here.

@@ +814,5 @@
>    filePicker->SetDefaultString(defaultDisplayString);
>    filePicker->AppendFilters(nsIFilePicker::filterAll);
> +  NS_ConvertUTF8toUTF16 extension(aDisplayName);
> +  // Check if the attachment has some extension and the extension
> +  // doesn't contain space(s) and set it as the default extension.

Please extend this comment explaining why the extension shouldn't contain a space.
Attachment #8372309 - Flags: feedback?(acelists) → feedback+
Posted patch Patch v2.5 (obsolete) — Splinter Review
Made the suggested changes.
Using sanitized defaultDisplayString now instead of aDisplayName.
Attachment #8372309 - Attachment is obsolete: true
Attachment #8372309 - Flags: review?(neil)
Attachment #8372309 - Flags: review?(mkmelin+mozilla)
Attachment #8372309 - Flags: feedback?(bugzilla2007)
Attachment #8372530 - Flags: review?(neil)
Attachment #8372530 - Flags: review?(mkmelin+mozilla)
Attachment #8372530 - Flags: feedback?(bugzilla2007)
So, this is an optional patch. I request you to please try this over the core patch v2.5
This is a roughly drafted patch, if the idea is approved, we can polish this one and merge both of them.

Thanks.
Attachment #8372877 - Flags: review?(neil)
Attachment #8372877 - Flags: feedback?(acelists)
This patch can be avoided if we do all this work in nsMessenger.cpp
But, considering the possibilities of doing this in a better way in nsFilePicker class, I have put it here. Please let me know if,
this idea is approved and the changes to be made to make it work better.
To be applied on m-c with core patch v2.5 and try patch over mailnews.

Thanks.
Attachment #8372879 - Flags: review?(neil)
Attachment #8372879 - Flags: feedback?(acelists)
Comment on attachment 8372877 [details] [diff] [review]
Patch for "save as type" dropdown. To be applied over patch v2.5

If you want to create a filter based on the content type then you need to use the MIME service to find the information. There's a JS implementation of the code you need here:
http://mxr.mozilla.org/comm-central/source/mozilla/toolkit/content/contentAreaUtils.js?mark=776-792#775
(Don't worry about the rest of appendFiltersForContentType, that's to deal with the case of saving web pages.)
Attachment #8372877 - Flags: review?(neil) → review-
Attachment #8372879 - Flags: review?(neil)
Comment on attachment 8372530 [details] [diff] [review]
Patch v2.5

>+  nsString extension(defaultDisplayString);
Don't need to copy this string.

>+  if (extensionIndex != 0 &&
>+      extensionIndex != kNotFound &&
Could just use extensionIndex > 0 here.

>+      extension.Find(" ", false, extensionIndex, -1) == kNotFound)
Need to use FindChar here.
But 'Patch for "save as type" dropdown. To be applied over patch v2.5' is only if everyone thinks this needs to be included. Do we need this as well?

(In reply to neil@parkwaycc.co.uk from comment #50)
> Comment on attachment 8372877 [details] [diff] [review]
> Patch for "save as type" dropdown. To be applied over patch v2.5
> 
> If you want to create a filter based on the content type then you need to
> use the MIME service to find the information. There's a JS implementation of

I am using aContentType, why is that not fine? Are there some issues related to it?
(In reply to Suyash Agarwal (:sshagarwal) from comment #48)
> Created attachment 8372877 [details] [diff] [review]
> Patch for "save as type" dropdown. To be applied over patch v2.5
> 
> So, this is an optional patch. I request you to please try this over the
> core patch v2.5
> This is a roughly drafted patch, if the idea is approved, we can polish this
> one and merge both of them.

What is this trying to solve?
(In reply to :aceman from comment #53)
> > Patch for "save as type" dropdown. To be applied over patch v2.5
> > So, this is an optional patch. I request you to please try this over the
> > core patch v2.5
> > This is a roughly drafted patch, if the idea is approved, we can polish this
> > one and merge both of them.
> 
> What is this trying to solve?

In the save as dialog box, core patch solved the extension issue with the filename field.
But the "Save as type" dropdown just below it still showed "All files". So this patch addresses it by appending the associated filters. Works on Linux too.
Will the "Save as type" now display the extension of the attachment?
(In reply to :aceman from comment #55)
> Will the "Save as type" now display the extension of the attachment?
It will show the type (E.g. Image files for .jpg etc) if the filter is one of http://mxr.mozilla.org/comm-central/source/mozilla/widget/nsIFilePicker.idl#39
else yes, it will show the extension (E.g. flv for *.flv).
Comment on attachment 8372879 [details] [diff] [review]
Filepicker patch, to be applied over m-c

Review of attachment 8372879 [details] [diff] [review]:
-----------------------------------------------------------------

::: widget/gtk/nsFilePicker.cpp
@@ +239,5 @@
> +  }
> +  else if (aFilterName.EqualsASCII("xul")) {
> +    *aFilterMask = filterXUL;
> +  }
> +  else if (aFilterName.EqualsASCII("xml")) {

Will this actually work with the TB patch? You cut the part before "/" from the content type of the attachment. However, the types for the latter 3 are text/html, application/xul application/xml (or something like that). So you your way of cutting the mime type you will never get values of "html", "xul" and "xml". Also, Neil had some problem with this, suggesting to use proper MIME service.

Would it be able to just always show the real extension of the attachment? If you receive a .jpg file, you want to save it as jpg (even if you change the name). You are not saving it as some abstract "images files" group. Those, groups are mostly intended for loading (opening) files.
Attachment #8372879 - Flags: feedback?(acelists)
(In reply to :aceman from comment #57)
> Filepicker patch, to be applied over m-c
> ::: widget/gtk/nsFilePicker.cpp
> Will this actually work with the TB patch? Would it be able to just always 
> show the real extension of the attachment?
I'll refine it once the idea gets approved. That is, we need it or this is needed.

> If you receive a .jpg file, you want to save it as jpg (even if you change
> the name). You are not saving it as some abstract "images files" group.
> Those, groups are mostly intended for loading (opening) files.
My main intention was to usually show the type of file we are going to save so the users don't wonder what their "filenames without extension" are going to be saved as. Moreover, if the "save as type" is "all files" we can type any random extension and the file will be saved with that extension. But, if the "save as type" is set to some defined filter e.g. ".patch" files and we save our file with some unknown extension e.g. "filename.abcd", the file will be saved as "filename.abcd.patch". OTOH if we had "save as type" set to "all fiels" the file would have been saved as "filename.abcd" only.

So, these are the only two concerns that I had for thinking to implement filter too. Though I had a third intention of making it full proof and professional but that can be ignored as of now :)

Thanks.
(In reply to Suyash Agarwal (:sshagarwal) from comment #58)
> (In reply to :aceman from comment #57)
> > Filepicker patch, to be applied over m-c
> > ::: widget/gtk/nsFilePicker.cpp
> > Will this actually work with the TB patch? Would it be able to just always 
> > show the real extension of the attachment?
> I'll refine it once the idea gets approved. That is, we need it or this is
> needed.
If we just show the real extension then it seems no changes to the picker code are needed.

> > If you receive a .jpg file, you want to save it as jpg (even if you change
> > the name). You are not saving it as some abstract "images files" group.
> > Those, groups are mostly intended for loading (opening) files.
> My main intention was to usually show the type of file we are going to save
> so the users don't wonder what their "filenames without extension" are going
> to be saved as. Moreover, if the "save as type" is "all files" we can type
> any random extension and the file will be saved with that extension. But, if
> the "save as type" is set to some defined filter e.g. ".patch" files and we
> save our file with some unknown extension e.g. "filename.abcd", the file
> will be saved as "filename.abcd.patch". OTOH if we had "save as type" set to
> "all fiels" the file would have been saved as "filename.abcd" only.

That is good question, probably for UX folks :) Do we want to allow users to change the extension?
What happens if there is no extension in the file? Would we be able to add one at least in that case? Set the filter to "all files" in that case ?
This doesn't require the toolkit change. 
Thanks to aceman sir for this idea.
Please let me know if this is acceptable.
Attachment #8372877 - Attachment is obsolete: true
Attachment #8372879 - Attachment is obsolete: true
Attachment #8372877 - Flags: feedback?(acelists)
Attachment #8375800 - Flags: review?(neil)
Attachment #8375800 - Flags: feedback?(acelists)
Attachment #8375800 - Flags: review?(neil)
Posted patch Patch v3 (obsolete) — Splinter Review
Okay so this patch removes the toolkit changes.
Works as follows:

You have an attachment |filename.extension|
-> You save it as |newfilename| with save as type set to "extension files":
   the file will be saved as |newfilename.extension|

-> You save it as |newfilename.newKnownextension| with save as type set to "extension files" or as |newfilename.newunknownextension| with save as type set to "all files": the file will be saved as |newfilename.newKnownextension| or |newfilename.newunknownextension| respectively.

-> You save it as |newfilename.newUnknownExtension| with save as type set to "extension files": it will be saved as |newfilename.newUnknownExtension.extension|.

-> You save it as |newfilename| with save as type set to "all files": it will be saved as |newfilename|.
Attachment #8372530 - Attachment is obsolete: true
Attachment #8375800 - Attachment is obsolete: true
Attachment #8372530 - Flags: review?(neil)
Attachment #8372530 - Flags: review?(mkmelin+mozilla)
Attachment #8372530 - Flags: feedback?(bugzilla2007)
Attachment #8375800 - Flags: feedback?(acelists)
Attachment #8376099 - Flags: review?(neil)
Attachment #8376099 - Flags: review?(mkmelin+mozilla)
Attachment #8376099 - Flags: feedback?(bugzilla2007)
Attachment #8376099 - Flags: feedback?(acelists)
Comment on attachment 8376099 [details] [diff] [review]
Patch v3

Patch behavior as per comment #61.
Attachment #8376099 - Flags: ui-review?(bwinton)
Sorry, the last point "saving as |newfilename| with save as type set to |all files| and expecting it to be saved as |newfilename| itself without any extension" doesn't happen.

(In reply to neil@parkwaycc.co.uk from comment #51)
> >+  nsString extension(defaultDisplayString);
> Don't need to copy this string.

Ya, it wasn't required but I am still copying it because now I am using extension at many places, for generating filter too. So, I thought instead of using Substring() everywhere, I should use an nsString. Please let me know if this isn't correct.

Thanks.
Comment on attachment 8376099 [details] [diff] [review]
Patch v3

Review of attachment 8376099 [details] [diff] [review]:
-----------------------------------------------------------------

Yes, I like this. I can't test it on Windows, but on Linux the 2 available filters ("<extension> files"+"all files") work fine.
As long as it saves the file with any extension (either the original one, or user supplied one, or user+original) then I think it solves the bug.

If this passes through Neil, don't forget to add the string for Seamonkey :)
Attachment #8376099 - Flags: feedback?(acelists) → feedback+
Comment on attachment 8376099 [details] [diff] [review]
Patch v3

Review of attachment 8376099 [details] [diff] [review]:
-----------------------------------------------------------------

Suyash, thank you so much for working on this with so much energy to improve the UX.
This is technical review/feedback only (as far as I can do). Will come back for behaviour later.

::: mail/locales/en-US/chrome/messenger/messenger.properties
@@ +765,5 @@
>  ignoredThreadsFeedback=Replies to the thread that was selected will not be shown.;Replies to the #1 threads that were selected will not be shown.
>  # LOCALIZATION NOTE (ignoredSubthreadsFeedback): Semi-colon list of plural forms.
>  # #1 is number of subthreads
>  ignoredSubthreadsFeedback=Replies to the subthread that was selected will not be shown.;Replies to the #1 subthreads that were selected will not be shown.
> +# LOCALIZATION NOTE (saveAsType): replace %S with the extension.

that's a misleading instruction to translators, should be:
%S will be replaced with the extension of the file to be saved

::: mailnews/base/src/nsMessenger.cpp
@@ +811,5 @@
>    GetString(NS_LITERAL_STRING("SaveAttachment"), saveAttachmentStr);
>    filePicker->Init(mWindow, saveAttachmentStr,
>                     nsIFilePicker::modeSave);
>    filePicker->SetDefaultString(defaultDisplayString);
> +  nsString extension(defaultDisplayString);

I agree with Neil that it's logically confusing to copy defaultDisplayString into extension variable this early in the code (assuming that's what it does, right?). DefaultDisplayString is the full file name, and that should never be saved in the extension variable, not even temporarily. I'll suggest respective changes below.
So here, I think you can just delete the above line.

@@ +812,5 @@
>    filePicker->Init(mWindow, saveAttachmentStr,
>                     nsIFilePicker::modeSave);
>    filePicker->SetDefaultString(defaultDisplayString);
> +  nsString extension(defaultDisplayString);
> +  // Check if the attachment has some extension and the extension

I think we could rewrite this a bit simpler and clearer:

Check if the attachment file name has an extension (which must not contain spaces) and set it as the default extension for the "Save as" dialogue (filePicker).

@@ +815,5 @@
> +  nsString extension(defaultDisplayString);
> +  // Check if the attachment has some extension and the extension
> +  // doesn't contain space(s) (because if it contains spaces, it
> +  // is no longer an extension) and set it as the default extension.
> +  PRInt32 extensionIndex = extension.RFindChar('.');

Per my comment above, logically you can't look inside an extension variable to find an extension. It works technically, but it's confusing to read in the code. So this should be:

PRInt32 extensionIndex = defaultDisplayString.RFindChar('.');

@@ +817,5 @@
> +  // doesn't contain space(s) (because if it contains spaces, it
> +  // is no longer an extension) and set it as the default extension.
> +  PRInt32 extensionIndex = extension.RFindChar('.');
> +  if (extensionIndex > 0 &&
> +      extension.FindChar(' ', extensionIndex) == kNotFound)

Dito, we're still looking at the filename to verify if it's actually an extension (so it's not yet a verified extension we're looking at, and variable names should mirror that):

defaultDisplayString.FindChar(' ', extensionIndex) == kNotFound)

@@ +819,5 @@
> +  PRInt32 extensionIndex = extension.RFindChar('.');
> +  if (extensionIndex > 0 &&
> +      extension.FindChar(' ', extensionIndex) == kNotFound)
> +  {
> +    extension = Substring(extension, extensionIndex + 1);

So here's the right place to initialize your extension variable because only now it's a verified extension. So do here whatever it takes in c++ to get this right, probably something like:

nsString extension = Substring(defaultDisplayString, extensionIndex + 1);

^^ Yep, that looks much better logically...

@@ +827,5 @@
> +      rv = InitStringBundle();
> +      NS_ENSURE_SUCCESS(rv, rv);
> +    }
> +
> +    nsString filterName;

I didn't review the code below this line.
(In reply to Suyash Agarwal from comment #52)
> (In reply to comment #50)
> > Comment on attachment 8372877 [details] [diff] [review]
> > Patch for "save as type" dropdown. To be applied over patch v2.5
> > 
> > If you want to create a filter based on the content type then you need to
> > use the MIME service to find the information. There's a JS implementation of
> 
> I am using aContentType, why is that not fine? Are there some issues related
> to it?

There's nothing wrong with using aContentType if you're passing it to the MIME service to get the description (and optionally default extension - this deals with the case where an extension could not be found in the file name itself.)

(In reply to Suyash Agarwal from comment #63)
> (In reply to comment #51)
> > >+  nsString extension(defaultDisplayString);
> > Don't need to copy this string.
> 
> Ya, it wasn't required but I am still copying it because now I am using
> extension at many places, for generating filter too. So, I thought instead
> of using Substring() everywhere, I should use an nsString. Please let me
> know if this isn't correct.

There are two ways of doing it without an nsString but unfortunately the external string API doesn't support them, so I won't bother mentioning them. However I would agree with Thomas that you should initialise your extension with the substring.
Comment on attachment 8376099 [details] [diff] [review]
Patch v3

>+saveAsType=%S files
Needs suite locale change too please.
Note that Toolkit disagrees about the use of the "s" when saving a file, see http://dxr.mozilla.org/mozilla-central/source/toolkit/locales/en-US/chrome/mozapps/downloads/unknownContentType.properties#17

>+  PRInt32 extensionIndex = extension.RFindChar('.');
Nit: int32_t

>   filePicker->AppendFilters(nsIFilePicker::filterAll);
>-
Why delete this line?
Posted patch Patch v4 (obsolete) — Splinter Review
Made the suggested changes, thanks.
Attachment #8376099 - Attachment is obsolete: true
Attachment #8376099 - Flags: ui-review?(bwinton)
Attachment #8376099 - Flags: review?(neil)
Attachment #8376099 - Flags: review?(mkmelin+mozilla)
Attachment #8376099 - Flags: feedback?(bugzilla2007)
Attachment #8376700 - Flags: ui-review?(bwinton)
Attachment #8376700 - Flags: review?(neil)
Attachment #8376700 - Flags: review?(mkmelin+mozilla)
Comment on attachment 8376700 [details] [diff] [review]
Patch v4

>+    nsString extension;
>+    extension = Substring(defaultDisplayString, extensionIndex + 1);
[Bah, explicit constructors suck.]

>+    filePicker->AppendFilter(filterName, NS_LITERAL_STRING("*.") + extension);
Unfortunately this doesn't work with the external API. Please use
extension.Insert(NS_LITERAL_STRING("*."), 0);
filePicker->AppendFilter(filterName, extension);
Attachment #8376700 - Flags: review?(neil) → review+
Comment on attachment 8376700 [details] [diff] [review]
Patch v4

>+# LOCALIZATION NOTE (saveAsType): replace %S with the extension of the file to be saved.
>+saveAsType=%S file

Still confusing for localizers, you are instructing them (using imperative form) to "replace %S with the extension..."? With what extension should they replace it?

We need something like this:

%S is the extension of the file to be saved (*.xyz).
%S is a placeholder for the extension of the file to be saved (*.xyz).
%S represents the extension of the file to be saved (*.xyz).
%S will be replaced with the extension of the file to be saved (*.xyz).

>+# LOCALIZATION NOTE (saveAsType): replace %S with the extension of the file to be saved.
>+saveAsType=%S file

Dito.
(In reply to Thomas D. from comment #70)
> Comment on attachment 8376700 [details] [diff] [review]
> Patch v4
> 
> >+# LOCALIZATION NOTE (saveAsType): replace %S with the extension of the file to be saved.
> >+saveAsType=%S file

Or perhaps, if you want an instruction for localizers (which is what localization notes are):

Preserve %S as a placeholder for the extension of the file to be saved (*.xyz).
(In reply to Suyash Agarwal (:sshagarwal) from comment #61)
> Created attachment 8376099 [details] [diff] [review]
> Patch v3
> 
> Okay so this patch removes the toolkit changes.
> Works as follows:

OK, let's look at the UX of this (mostly correct, one problem found).
Reminder: We're operating on Windows, with "Hide known file extensions" set in Explorer.

> You have an attachment |filename.extension| 
> -> You save it as |newfilename| with save as type set to "extension files":
>    the file will be saved as |newfilename.extension|

attachment:   oldname.doc
Save as...
shown as:     oldname
File name:    newname
Save As type: *.doc
Result file:  newname.doc (ok)

> -> You save it as |newfilename.newKnownextension| with save as type set to
> "extension files" [...]: the file will be saved as
> |newfilename.newKnownextension|

attachment:   oldname.doc
Save as...
shown as:     oldname
File name:    newname.pdf (different, known extension)
Save As type: *.doc
Result file:  newname.pdf (different, known extension)

This part of the behaviour (if it actually happens, which I doubt) is a recipe for UX disaster.

1) We shouldn't allow users to save oldname.doc as newname.pdf if we are not able to actually convert the file. Users will end up with newname.pdf which however is internally a Word document with wrong extension and thus will fail to open as a pdf (back to square one, the problem of this bug).

2) What's the point of showing "Save as type" e.g. "*.doc files" if you don't respect/apply it? Violates ux-wysiwyg and ux-consistency with all other apps on the same OS.

a)(New File name, new known "ext")   newname.pdf + *.doc (Save as type) must result in newname.pdf.doc

We might be surprised how many users actually use such double extensions when they convert documents from one format into the other, ending up with .doc.pdf or .pdf.doc (even deliberately, for format tracking purposes). Furthermore, what if users want to save as newname.tmp.doc and are not even aware that .tmp is a registered extension? So they'll end up with useless newname.tmp just because .tmp happens to be some obscure but "known" extension? Grrr...

This is also required to be consistent with the twin scenario of "different, unknown extension"; user won't understand why some "extensions" are recognized and others not:

> -> You save it as |newfilename.newUnknownExtension| with save as type set to
> "extension files": it will be saved as
> |newfilename.newUnknownExtension.extension|.

b)(New File name, new unknown "ext") newname.foo + *.doc (Save as type) correctly results in newname.foo.doc (OK)

c) furthermore, how would this behave if the original filename legitimately already has "double extension", e.g. oldname.pdf.doc? Certainly we can't just remove .doc extension because there's another string in the filename that happens to match a known extension.

3) It's very rare that windows applications allow converting the file type by just changing the extension in the "File name" (!) input box of "Save As..." dialogue. The only app I'm aware of is IrfanView, but then they change the "Save as type" input immediately when you type the new extension, and they also *convert* the target file into the new format. All other apps, users need to deliberately pick another extension (or "*.* All files) from the list of "Save as type" if they want to convert the file and use new extension.

But I actually wonder if you just described the behavior wrong, because my windows file picker from other applications doesn't behave that way:

With extensions hidden, open "oldname.doc" and from Word, Save As:
File name: newname.xls
Save As type: *.doc Word document
Result file: newname.xls.doc (ok; default windows behaviour; beware: .doc extension not showing in explorer or in subsequent "Save as...", but it's there internally!)

So that's the correct behaviour wanted here (treat strings that happen to look like known or unknown "extensions" as part of new filename when "Save as type: *.originalExt" is set):

attachment:   oldname.doc
Save as...
shown as:     oldname
File name:    newname.pdf (happens to be known extension; or:) newname.foo (unknown "extension"??)
Save As type: *.doc
Result file:  newname.pdf.doc (per Save As type; or:) newname.foo.doc (per Save as type)
(Because Save As type *.doc is explicitly set, do not change the file type/extension of target file).

> or as |newfilename.newunknownextension| with save as type
> set to "all files": [will be saved as] |newfilename.newunknownextension|
> respectively.

Right, so this is where users can change their extensions when they really want to (and I've seen this in other corners of TB, too; not offered in other apps like Word):

attachment:   oldname.doc
Save as...
shown as:     oldname
File name:    newname.pdf (happens to be known extension; or:) newname.foo (unknown "extension"??)
Save As type: *.* All files (important!)
Result file:  newname.pdf (or:) newname.foo (OK)
(Well, if the user so pleases... useful for things like newname.patch which might not be a registered extension. Because user deliberately set Save As type to *.* All files, as a courtesy for advanced users, we accept changing the file type/extension of target file).

Note that in Word, you can set *.* in File Name input, but not in the Save As Type input which will always be set to one of the extensions offered by Word; iow, you can't save directly with an unknown extension nor any extension that Word doesn't know.

> -> You save it as |newfilename| with save as type set to "all files": it
> will be saved as |newfilename|.

attachment:   oldname.doc
Save as...
shown as:     oldname
File name:    newname (without extension)
Save As type: *.* All files (important!)
Result file:  newname (without extension; target file no longer associated with any app; is that wanted?).

Hmmm, why would users on windows want to save a file without extension (making it much harder to access)? Intuitively, I'd expect TB to rember the default extension here if user doesn't specify any extension. But perhaps it's not all that important because arguably(!) only advanced users might change "Save as type" to "*.* All files".
TL;DR version of comment 72:

If Suyash is correct about the behaviour description of current patch, attachment 8376700 [details] [diff] [review], described in comment 61, the following scenario fails (due to major UX problems):

> -> You save it as |newfilename.newKnownextension| with save as type set to
> "extension files" [...]: the file will be saved as
> |newfilename.newKnownextension|

attachment:   oldname.doc
Save as...
shown as:     oldname
File name:    newname.pdf (different, known extension)
Save As type: *.doc files
Result file:  newname.pdf (wrong! different, known extension; but file content not converted)

violates ux-wysiwyg: explicit "Save as type" setting (*.doc files) should be respected
violates ux-consistency: all other apps in OS respect "Save as type" setting
ux-error-prevention:
a) user is likely to experience failure when trying to open file with new extension but still old format internally (e.g. opening newname.pdf will fail because it's still a Word document internally).
b) for new file name, user might inadvertently use "new extension" without knowing, resulting in failure of a):
File name:    newname.tmp (user understands this as a tag part of new filename, not aware of tmp extension)
Save As type: *.doc files
Result file:  newname.tmp (but user never intended to change the .doc extension to .tmp)
Sincerely and honestly, comments 72 and 73 don't make sense to me.
Why do you think this is a violation? :) This is a common Windows behavior. You can try this on "notepad" itself.
I specifically chose notepad as it is a default windows application so you can at least accept its behavior if you can't accept my patch :)

Please try this: 
Open notepad
Save as: filename.pdf with "save as type" still showing "text document"
See the saved file. It is filename.pdf (with no .txt appended)
That's what TB will do after this patch.

Open notepad
Save as: filename with "save as type" set to "all files"
See the saved file. It is filename.txt (with default .txt still appended)
That's what TB will do after this patch.

Hope that justifies this new behavior.
Thanks.
Moreover, if you really want to save some filename.ext attachment as "newfilename.newext" or "newfilename" itself without any extension. This works on almost every windows application and will do the same here too: save it this way using quotes "newfilename.newext" with anything in the "save as type" field. Your attachment will be saved in the way you want it. 

Now, before this behavior is questioned :) I repeat, this is a standard windows behavior and every native windows application behaves in this way.
(In reply to Suyash Agarwal (:sshagarwal) from comment #74)
> Sincerely and honestly, comments 72 and 73 don't make sense to me.
> Why do you think this is a violation? :) This is a common Windows behavior.
> You can try this on "notepad" itself.
> I specifically chose notepad as it is a default windows application so you
> can at least accept its behavior if you can't accept my patch :)

Got me! :) Indeed, Suyash is right about those applications that come with windows (notepad, mspaint etc.). I'm also right about the different behaviour in MS Word / Office apps.
Didn't test other apps so far.

So both competing behaviours exist in standard windows applications (tested on XP):

a) Apps that respect "Save as type" even when new file name ends in a different, but known extension (like MS Word, which will generally preserve the .doc extension)

b) Apps that ignore "Save as type" and take a different but known extension as a change of extension (like MS Notepad and MS paint).

I'm surprised about behaviour of b) and I don't think it's good design, but well, if that's how it is, I suppose TB can get away with it, too. So I withdraw the strong objection character of my comment 73 and instead just submit that for consideration by the UX powers that be.

> Open notepad
> Save as: filename with "save as type" set to "all files"
> See the saved file. It is filename.txt (with default .txt still appended)
> That's what TB will do after this patch.

Good to know, and good behaviour, not sure why you described the TB behaviour differently in comment 61:

> -> You save it as |newfilename| with save as type set to "all files": it
> will be saved as |newfilename|.

So yeah, I'm OK with the current patch behaviour from my side with some reservations/thoughts for consideration per comment 73. :)
(In reply to Thomas D. from comment #76)
> b) Apps that ignore "Save as type" and take a different but known extension
> as a change of extension (like MS Notepad and MS paint).
> 
> I'm surprised about behaviour of b) and I don't think it's good design, but
> well, if that's how it is, I suppose TB can get away with it, too. So I
> withdraw the strong objection character of my comment 73 and instead just
> submit that for consideration by the UX powers that be.

Fwiw, I think it's simply a bug in Windows, what about this scenario:

hide known extensions set in explorer
original file: oldname.pdf.txt (that's a legitimate file name, isn't it?)
open with notepad
Save as...
Name shown: oldname.pdf
File name : oldname.pdf (so we're not changing the name at all)
Save as type: *.txt (Text files)
OK
Result file: oldname.pdf (extension and association lost although user never changed anything)

-> Even though we didn't touch the file name at all, Notepad still loses the original .txt extension and saves this as as a new file with different extension, oldname.pdf.

I suspect that this is an edge case which just hasn't been covered since the transition from 8.3 to long file names was made.
Comment on attachment 8376700 [details] [diff] [review]
Patch v4

Review of attachment 8376700 [details] [diff] [review]:
-----------------------------------------------------------------

LGTM, with the plus changed (like Neil wrote)
Attachment #8376700 - Flags: review?(mkmelin+mozilla) → review+
Made the suggested changes.
Restating patch functionality:

You have an attachment |filename.extension|
-> Save it as |newfilename| with "save as type" set to "<extension> files":
   the file will be saved as |newfilename.extension|

-> Save it as |newfilename.newKnownextension| with "save as type" set to <extension> files" or as |newfilename.newunknownextension| with "save as type" set to "all files": the file will be saved as |newfilename.newKnownextension| or |newfilename.newunknownextension| respectively.

-> Save it as |newfilename.newUnknownExtension| with "save as type" set to "<extension> files": it will be saved as |newfilename.newUnknownExtension.extension|.

I hope this is the expected behavior. If not, please let me know.

Thanks.
Assignee: nobody → syshagarwal
Attachment #8376700 - Attachment is obsolete: true
Status: NEW → ASSIGNED
Attachment #8376700 - Flags: ui-review?(bwinton)
Attachment #8380570 - Flags: ui-review?(bwinton)
Attachment #8380570 - Flags: review+
Comment on attachment 8380570 [details] [diff] [review]
Patch almost ready for check-in, pending UI review

So, I don't have a Windows XP box handy, but this looks like it does the right thing based on code inspection, so ui-r=me.
Attachment #8380570 - Flags: ui-review?(bwinton) → ui-review+
Keywords: checkin-needed
https://hg.mozilla.org/comm-central/rev/eef76db70585
Status: ASSIGNED → RESOLVED
Closed: 12 years ago5 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
Target Milestone: --- → Thunderbird 31.0
You need to log in before you can comment on or make changes to this bug.