346994 - Remove leading dot (period) (.) from suggested filename for saving (save file)

Status: RESOLVED FIXED

(Firefox :: File Handling, defect)

Description

[Bill McGonigle (not currently reading bugmail; please contact directly)]

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.

Comment 1

[Bill McGonigle (not currently reading bugmail; please contact directly)]

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

Comment 2

[Mark Mentovai]

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.

Comment 3

[Mark Mentovai]

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

Comment 4

[Jesse Ruderman]

See also bug 290720.

Comment 5

[Bill McGonigle (not currently reading bugmail; please contact directly)]

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

Comment 6

[Bill McGonigle (not currently reading bugmail; please contact directly)]

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

Security bug? (access denied)

Comment 7

[Jesse Ruderman]

Yes, bug 290720 is a security bug.

Comment 8

[:Gavin Sharp [email: [e-mail]]]

Attachment: 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 9

[:Gavin Sharp [email: [e-mail]]]

Comment on attachment 261821 [details] [diff] [review]
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 10

[Daniel Veditz [:dveditz]]

Comment on attachment 261821 [details] [diff] [review]
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

Comment 11

[[e-mail]]

I know IanN likes our filename generation code ;-)

Comment 12

[:Gavin Sharp [email: [e-mail]]]

Landed that patch on the branches.

Comment 13

[Daniel Veditz [:dveditz]]

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.

Comment 14

[Serge Gautherie (:sgautherie)]

Attachment: (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) ...|.

Comment 15

[Serge Gautherie (:sgautherie)]

Attachment: (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 :-/

Comment 16

[Reed Loden [:reed]]

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

Comment 17

[Serge Gautherie (:sgautherie)]

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

Comment 18

[Robert Kaiser]

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.

Comment 19

[Serge Gautherie (:sgautherie)]

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

Comment 20

[Jesse Ruderman]

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

Comment 21

[Robert Kaiser]

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.

Comment 22

[:Gavin Sharp [email: [e-mail]]]

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

[Robert Kaiser]

Comment on attachment 290989 [details] [diff] [review]
(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.

Comment 24

[Reed Loden [:reed]]

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

Comment 25

[:Gavin Sharp [email: [e-mail]]]

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.

Comment 27

[TT]

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.

Comment 28

[Awad Mackie]

Attachment: 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 29

[:Gavin Sharp [email: [e-mail]]]

Comment on attachment 8428934 [details] [diff] [review]
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 30

[Awad Mackie]

Comment on attachment 8428934 [details] [diff] [review]
leading_period.patch

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

Comment 31

[:Paolo Amadini]

Since the original issue was fixed and patches landed, I'm updating the state of this bug accordingly.