Closed Bug 75336 Opened 24 years ago Closed 23 years ago

Linux: mozilla <file>, <file> shouldn't need "file:" prefix

Categories

(SeaMonkey :: UI Design, defect, P4)

x86
Linux

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: mcafee, Assigned: law)

Details

(Whiteboard: DUPEME)

Linux. mozilla "/etc/passwd" renders the homepage (fails) mozilla "file:/etc/passwd" shows the passwd file, the right thing. Note that both "/etc/passwd" and "file:/etc/passwd" both work in the url bar. I think this is broken on the commandline, this will break all kinds of local scripts, etc. I found this trying to script tinderbox tests.
-->Networking:File
Assignee: neeti → dougt
Component: Networking → Networking: File
Invalid. The parameter is a URL not a file path.
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → INVALID
REOPEN: This shouldn't work. I'll check again.
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
ben, if you reopen a bug, could you give a descriptive reason why.
Status: REOPENED → RESOLVED
Closed: 24 years ago23 years ago
Resolution: --- → INVALID
QA Contact: tever → benc
REOPEN: I gave a reason. "It shouldn't work." file:/etc/password is not a valid file URL. If that is valid for some reason, I'd like to know why. Once that is clarified, this should probably go to XP apps b/c the real problem is they should take a path from the line command.
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
okay.
Assignee: dougt → pchen
Status: REOPENED → NEW
Component: Networking: File → XP Apps
QA Contact: benc → sairuh
/etc/passwd works in the url bar because it's changed to "file:///etc/passwd", at any rate, marking p4, minor, and mozilla1.1 because to do this right requires a bit a of work. First off, what should happen ifI type "mozilla ../index.html"? It doesn't currently work. I'm hoping adding the ability to support full pathnames should be easy.
Severity: normal → minor
Priority: -- → P4
Target Milestone: --- → mozilla1.1
-> default assignee
Assignee: pchen → trudelle
Target Milestone: mozilla1.1 → ---
->law. invalid? wontfix? future?
Assignee: trudelle → law
Whiteboard: DUPEME
This has been fixed for months. I've been using it daily. I think Benjamin is saying that file:/etc/passwd (as opposed to file:///etc/passwd) is technically incorrect and shouldn't be supported. First, that would be a different bug, not this one; second, it had nothing to do with the fixing of this bug (file:/etc/passwd has worked for at least 6-8 months in mozilla); and third, that format always worked in NS4 and a lot of people use it, so if we stop supporting it we'll annoy a lot of people. But in any case, it has nothing to do with this bug, and I suggest re-closing this one as fixed.
good enough for me
Status: NEW → RESOLVED
Closed: 23 years ago23 years ago
Resolution: --- → FIXED
Should I file a separate bug then on the fact that Mozilla demands a file:// url whereas normal sane apps will accept a filename?Ÿ
If you have a reproducible case for that, you should reopen this bug. Nobody has given one or even mentioned that such a case existed. I run mozilla -edit /tmp/foo.html and mozilla /home/akkana/foo.html all the time (I also type things like /tmp/foo.html into the urlbar), so I know those cases work. Unless you're talking about relative pathnames (e.g. if I'm in my home directory I can't say "mozilla foo.html" or "mozilla ./foo.html" and have it open a file in that directory); I think there's already a bug on that (sorry, don't have the number offhand) but no one has come up with a heuristic that distinguishes that case from the case "mozilla foo.com".
I agree with Akkana, find a case that doesn't work and reopen if needed. It looks like mozilla now understands the mozilla <filename> format now. I tested with 0.9.6 and it was still broken, but the trunk build works for me. Verifying.
Status: RESOLVED → VERIFIED
Yup. I guess I missed it being fixed. :) I agree that relative pathnames are a different kettle of fish entirely.
Product: Core → Mozilla Application Suite
You need to log in before you can comment on or make changes to this bug.