firefox does not save an attachments starting with dot

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.

See also bug 290720.

(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.

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.