firefox does not save an attachments starting with dot

Bug #1023012 reported by Jan Groenewald on 2012-07-10
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Mozilla Firefox
Fix Released
Medium
firefox (Ubuntu)
Undecided
Unassigned

Bug Description

When I download & save a file and I change the name to start with a dot,
it 0) prompts me to replace the existing dot file, if it exists, 1) removes the
existing dot file, and 2) silently removes the dot and saves it with the name.

Example, someone mailed me a .bash_completion to replace an existing one,
and it removed the existing but saved /home/me/bash_completion.

I consider it a bug to not save dot-files if I ask for it, or to not give a proper
error message if it refuses. If upstream disagrees, it is at least a bug to
remove the existing dot-file if it refuses to save over it.

HFS doesn't permit a file to have a '.' character in the initial position.

This should be removed for the user attempting to save a file. I happen to know about OS9 drivers so it only took me 30 seconds to figure out why the 'Save' button wasn't lit up, but it's not terribly obvious for the typical user. It would be good to filter this (and any other illegal characters) for the user.

Oops - spazzed...

tested on Firefox 2.0b1

Steps to Reproduce:
1: Load URL with . as initial character of last part (see URL field)
2: Attempt to Save Page As...

Actual Results:
Save button not lit up. Removing the . allows the Save button to light.

Expected Results:
Filter the illegal character for the user

Which OS? On 10.4, the standard dialog doesn't prevent you from saving a file whose name begins with a dot. You'll be warned, complete with poor wording and punctuation, after clicking Save:

| Names that begin with a dot “.” are reserved for the
| system. If you decide to go ahead and use a name
| which begins with a dot the file will be hidden.
| (Cancel) (Use “.”)

Cancel is the default (responding to Return and Escape), Use is focused (responding to Space).

It's probably still a good idea to not suggest names beginning with a dot anyway.

Stripping leading dots from the suggested filename should probably be cross-platform.

(In reply to comment #2)
> Which OS?

10.3

So on 10.3 they won't work, on 10.4 and other unixes they'll be hidden - anybody know what happens on Windows? I don't mind if somebody makes this cross-platform; I just don't have a strong feeling one way or the other.

(In reply to comment #4)
> See also bug 290720.

Security bug? (access denied)

Yes, bug 290720 is a security bug.

Created attachment 261821
remove leading dot before saving (landed on trunk and branches, bug 304345)

Got r=mano over IRC. I'll fix the other part of this, which is to remove leading dots in the prompt, separately.

Comment on attachment 261821
remove leading dot before saving (landed on trunk and branches, bug 304345)

I think it would be good to get this fix on the branches, as well.

Comment on attachment 261821
remove leading dot before saving (landed on trunk and branches, bug 304345)

approved for 1.8.0.12 and 1.8.1.4, a=dveditz

I know IanN likes our filename generation code ;-)

Landed that patch on the branches.

Adding the fixed1.8.0.12 and fixed1.8.1.4 to reflect the fact that the patches in this bug landed, but it doesn't actually fix the described bug so leaving open on trunk for a better fix.

Created attachment 290983
(Bv1-SM) Port to SeaMonkey <contentAreaUtils.js> [Checkin: Comment 16]

[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9b2pre) Gecko/2007120103 SeaMonkey/2.0a1pre] (nightly) (W2Ksp4)

Successfully tested with <http://www.leginfo.ca.gov/.const/.article_13A> + Ctrl+S,
by temporarily commenting out |if (!aDefaultExtension) ...|.

Created attachment 290989
(Cv1-SM-18) Port to SeaMonkey branch [Check-in: Comment 24]

Same as Bv1-SM, but /xpfe instead of /suite.

"approval1.8.1.12=?":
Actually, I'm looking for SeaMonkey Council approval ... but there's no flag for that :-/

Bv1-SM:

Checking in suite/common/contentAreaUtils.js;
/cvsroot/mozilla/suite/common/contentAreaUtils.js,v <-- contentAreaUtils.js
new revision: 1.151; previous revision: 1.150
done

(In reply to comment #13)
> [...], but it doesn't actually fix the described bug so leaving
> open on trunk for a better fix.

What are the remaining bug and wanted behavior ?
Would moving |if (!aDefaultExtension) ...| after the regexs fix this bug ?
(The first regex was added there in bug 290381...)

Does that mean I can't just go straight in and download a .htaccess file provided on some site to some collection of web pages I (or a user) am creating for my personal homepage? Actually, I'd consider _that_ a bug.

(In reply to comment #18)
> Does that mean I can't just go straight in and download a .htaccess file

It depends on what your "that" refers to:
*The current patch ? It seems not to modify such filenames ("without extension"): see comment 14.
*The whole bug ? I don't know yet: see comment 17.

Robert, I imagine you'll have to add the dot yourself. I don't think that's too much to ask.

It's broken behavior, and there are all kinds of sample dot-files with settings for Linux/Unis programs around that people now have to fix up and novices will not realize that, esp. as the documentation on the websites for what to do with them won't mention that as they are offering the file with the dot after all.

IMHO this is a bad regression in behavior, and unless there is a huge security problem with saving dotfiles, I don't think it's a solution to anything but some obscure, probably old filesystem for a single platform, like mentioned in comment 0 - an initial dot is a standard thing to have on unix-based OSes, like OS X or Linux.

(In reply to comment #21)
> IMHO this is a bad regression in behavior, and unless there is a huge security
> problem with saving dotfiles

Perhaps not a "huge security problem", but bug 304345 was the original motivation for fixing this bug.

Comment on attachment 290989
(Cv1-SM-18) Port to SeaMonkey branch [Check-in: Comment 24]

OK, the argument derived from the other bug that I could be convinced with is actually that those downloaded files end up hidden, which makes a bad user experience if the user doesn't know what he's doing ;-)
approval-seamonkey1.1.8=me due to that, please add the fixed-seamonkey1.1.8 keyword when it's landed. Probably we even should relnote that.

Cv1-SM-18:

Checking in xpfe/communicator/resources/content/contentAreaUtils.js;
/cvsroot/mozilla/xpfe/communicator/resources/content/contentAreaUtils.js,v <-- contentAreaUtils.js
new revision: 1.134.2.6; previous revision: 1.134.2.5
done

If I recall correctly, I left this open because the original request was to strip the leading dot before prompting, instead of before saving, but we only implemented the latter. If what we're doing now is properly removing the dot in the suggested filename for the filepicker then this can be resolved.

*** Bug 512676 has been marked as a duplicate of this bug. ***

What is the status of this bug? I just tried several times to save a file called ".pwclientrc", only to wonder why I couldn't find it. After a few minutes, I noticed that the file was saved as "pwclientrc". The problem is that the save-as dialog box specifically said ".pwclientrc" (with the leading dot).

The current behavior is, IMHO, seriously broken. If we want to solve the problem in bug 290720 (which I can't view, so I don't know what the problem actually is), we should at least change the filename in the dialog box. If I change it back to add the leading dot, then Seamonkey should save it with the dot.

Thank you for reporting this bug. Could you specify which version of firefox and ubuntu are you using? I cannot reproduce this bug in ubuntu 12.04 with firefox 14.0. If I try to save a text file from firefox and rename it so as to start with a dot, the file is correctly saved with the expected initial dot. When I try again and overwrite the file, I see no removal of the initial dot.

Changed in firefox (Ubuntu):
status: New → Incomplete

Hi

On 21 July 2012 13:32, Antonio Roquentin <email address hidden> wrote:

> Thank you for reporting this bug. Could you specify which version of
> firefox and ubuntu are you using? I cannot reproduce this bug in ubuntu
> 12.04 with firefox 14.0. If I try to save a text file from firefox and
> rename it so as to start with a dot, the file is correctly saved with
> the expected initial dot. When I try again and overwrite the file, I see
> no removal of the initial dot.
>

It is Ubuntu 12.04, 64bit, all packages up to date,
 ii firefox 14.0.1+build1- Safe and easy web browser from Mozilla

When I click on a gmail attachment, application.doc, choose "download",
and change the filename to save to ".application.doc" it ignores the dot
and saves "application.doc" instead.

Regards,
Jan

It seems like you are experiencing this bug

https://bugzilla.mozilla.org/show_bug.cgi?id=346994

I can now confirm that "Save link as" does not allow saving such files. However, "Save page as" allows me to rename the file so that it starts with a dot.

Changed in firefox (Ubuntu):
status: Incomplete → Confirmed
Changed in firefox:
importance: Unknown → Medium
status: Unknown → Confirmed

Perhaps upstream will not want to change this behaviour.
That is fine.

Then firefox should at least tell the user what it is doing!

And it should certainly not remove existing files if it is not going
to overwrite them.

When I saved an email attachment .bash_completion,
1) it removed my existing .bash_completion (yes, it prompted me to replace
and I accepted)
2) it saved bash_completion (without the dot)
3) it clearly misinformed me about above.

Created attachment 8428934
leading_period.patch

nsHelperAppDlg.js checks with the user to remove a leading period file, removes it and then saves the file without the period.

Patch to check here and only remove the file if the final name matches.

What's the current policy on this as well? According to this bug, all leading periods should be removed when saving, but none of the paths in toolkit/content/contentAreaUtills.js seem to do so? So it can save leading period files that way.

Comment on attachment 8428934
leading_period.patch

Thanks for the patch Awad - any chance you can file a separate bug for this? It's generally a bad idea to track multiple separate patches in the same bug, particularly one as old as this one. Please needinfo me on the new bug and I can help get this reviewed/landed.

Comment on attachment 8428934
leading_period.patch

Yep, no problem, wasn't quite sure what to do with this. Added a new bug 1022061.

Changed in firefox:
status: Confirmed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.