Closed Bug 317290 Opened 19 years ago Closed 17 years ago

Saving a web page with a forward slash character (/) in its name does not work

Categories

(Firefox :: File Handling, defect)

2.0 Branch
PowerPC
macOS
defect
Not set
normal

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: support, Unassigned)

References

()

Details

(Keywords: qawanted)

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8) Gecko/20051111 Firefox/1.5
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8) Gecko/20051111 Firefox/1.5

Saving a file with a forward slash in its name fails.

Reproducible: Always

Steps to Reproduce:
1. Open the browser to any web page
2. Choose Save Page As....
3. Enter a forward slash somewhere in the filename.
4. Click Save.

Actual Results:  
No file is saved. No error message is posted. The command is essentially ignored.

Expected Results:  
The file should have saved. I believe that the OS internally will convert filename on disk that contain slashes to a more appropriate character, namely the hyphen (-).

It's possible a bug like this has been posted, but it's hard to find it because there are so many showing up in search with keywords filename slash save. The rationale for using slashes is simply that I'm trying to save the file with the date in its name.
If you go to about:config, and set javascript.options.showInConsole to true, are there any error messages in the JavaScript console after reproducing this bug?
Yes there is:

Error: uncaught exception: [Exception... "Component returned failure code: 0x80520012 (NS_ERROR_FILE_NOT_FOUND) [nsIPrefBranch.setComplexValue]"  nsresult: "0x80520012 (NS_ERROR_FILE_NOT_FOUND)"  location: "JS frame :: chrome://global/content/contentAreaUtils.js :: getTargetFile :: line 534"  data: no]
This was reported in bug 349014.   That bug was closed with a WONTFIX status and the comment that, in v2, the '/' will be explicitly disallowed (beep).  The problem is undoubtedly related to the fact that '/' is a directory separator in the underlying unix based filesystem.   However every bundled OS X application can deal with '/' in the filename just fine.   I am sure there must be a simple API to 'protect' the problematic characters before saving the file.   Please change the code to save the file properly rather than the lazy hack (which probably required more coding and worse performance) of generating an error when the user enters a '/'.
So is this a DUPE / WONTFIX?
Version: unspecified → 1.5.0.x Branch
That bug was inappropriately closed. The bug is still present. Filenames can have a / in their names and if they are so named, they don't get saved. I guess as long as this bug remains open, there is no need to open another.
The bug is still present in which version of Firefox?
2.0.0.4. How do I change the branch? Must it be resubmitted?
Keywords: qawanted
Version: 1.5.0.x Branch → 2.0 Branch
Component: General → File Handling
QA Contact: general → file.handling
Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.9a6pre) Gecko/20070619 Minefield/3.0a6pre

This works for me in a current trunk build -- the forward slash is replaced with an underscore. I guess some patch landed that replaces illegal chars. in filenames with underscores, but I cannot find it.

->WORKSFORME
Status: UNCONFIRMED → RESOLVED
Closed: 17 years ago
Resolution: --- → WORKSFORME
I have Firefox 2.0.0.8 (Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.8) Gecko/20071008 Firefox/2.0.0.8).    The behavior is still as in version 1.5 (i.e. files are silently not saved).   When will the fix reported by Adam show up in a release?   I sort of hope never.  It would be better to either disallow it (e.g. beep when user enters a '/' as was supposedly going to be the fix in version 2.x) or better yet to follow the os x convention of transparently converting the '/' to a ':' (ie appears to user in finder and in app as a '/', but is saved to the file system as a ':' in the name).
The 'trunk version' adam refers to in comment 8 is the version that is heading towards firefox 3. So the behaviour he describes will be when Fx3 is released.
You need to log in before you can comment on or make changes to this bug.