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

RESOLVED FIXED

Status

()

RESOLVED FIXED
13 years ago
2 years ago

People

(Reporter: bill+mozilla-bugzilla, Unassigned)

Tracking

({fixed-seamonkey1.1.8, fixed1.8.0.12, fixed1.8.1.4})

Trunk
fixed-seamonkey1.1.8, fixed1.8.0.12, fixed1.8.1.4
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(3 attachments, 1 obsolete attachment)

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

Comment 2

13 years ago
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

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

Comment 4

13 years ago
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)

Comment 7

13 years ago
Yes, bug 290720 is a security bug.
Created attachment 261821 [details] [diff] [review]
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.
Assignee: nobody → gavin.sharp
Status: NEW → ASSIGNED
Attachment #261821 - Flags: review+
OS: Mac OS X → All
Hardware: Macintosh → All
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.
Attachment #261821 - Flags: approval1.8.1.4?
Attachment #261821 - Flags: approval1.8.0.12?
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
Attachment #261821 - Flags: approval1.8.1.4?
Attachment #261821 - Flags: approval1.8.1.4+
Attachment #261821 - Flags: approval1.8.0.12?
Attachment #261821 - Flags: approval1.8.0.12+
I know IanN likes our filename generation code ;-)
Whiteboard: [checkin needed (1.8/1.8.0 branch)]
Landed that patch on the branches.
Whiteboard: [checkin needed (1.8/1.8.0 branch)]
Attachment #261821 - Attachment description: remove leading dot before saving → remove leading dot before saving (landed on trunk and 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.
Keywords: fixed1.8.0.12, fixed1.8.1.4
Assignee: gavin.sharp → nobody
Status: ASSIGNED → NEW
Created attachment 290983 [details] [diff] [review]
(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) ...|.
Attachment #290983 - Flags: superreview?(neil)
Attachment #290983 - Flags: review?(neil)
Blocks: 405653

Updated

11 years ago
Attachment #290983 - Flags: superreview?(neil)
Attachment #290983 - Flags: superreview+
Attachment #290983 - Flags: review?(neil)
Attachment #290983 - Flags: review+
Attachment #290983 - Attachment description: Port to SeaMonkey <contentAreaUtils.js> → (Bv1-SM) Port to SeaMonkey <contentAreaUtils.js>
Keywords: checkin-needed
Whiteboard: [c-n: Bv1-SM]
Created attachment 290989 [details] [diff] [review]
(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 :-/
Attachment #290989 - Flags: approval1.8.1.12?
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
Keywords: checkin-needed
Whiteboard: [c-n: Bv1-SM]
Attachment #290983 - Attachment description: (Bv1-SM) Port to SeaMonkey <contentAreaUtils.js> → (Bv1-SM) Port to SeaMonkey <contentAreaUtils.js> [checked in]
Attachment #290983 - Attachment description: (Bv1-SM) Port to SeaMonkey <contentAreaUtils.js> [checked in] → (Bv1-SM) Port to SeaMonkey <contentAreaUtils.js> [Checkin: Comment 16]
Attachment #261821 - Attachment description: remove leading dot before saving (landed on trunk and branches) → remove leading dot before saving (landed on trunk and branches, bug 304345)
(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

11 years ago
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.

Comment 20

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

Comment 21

11 years ago
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 23

11 years ago
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.
Attachment #290989 - Flags: approval1.8.1.12?
Keywords: checkin-needed
Whiteboard: [c-n: Cv1-SM-18, comment 23]
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
Keywords: checkin-needed → fixed-seamonkey1.1.8
Whiteboard: [c-n: Cv1-SM-18, comment 23]
Attachment #290989 - Attachment description: (Cv1-SM-18) Port to SeaMonkey branch → (Cv1-SM-18) Port to SeaMonkey branch [Check-in: Comment 24]
Whiteboard: [See comment 17]
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.
Whiteboard: [See comment 17]

Updated

9 years ago
Duplicate of this bug: 512676

Comment 27

8 years ago
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.
Blocks: 753267

Comment 28

5 years ago
Created attachment 8428934 [details] [diff] [review]
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.
Attachment #8428934 - Flags: feedback?(gavin.sharp)
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.
Attachment #8428934 - Flags: feedback?(gavin.sharp) → feedback+

Comment 30

5 years ago
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.
Attachment #8428934 - Attachment is obsolete: true

Comment 31

2 years ago
Since the original issue was fixed and patches landed, I'm updating the state of this bug accordingly.
Status: NEW → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.