Closed
Bug 13920
Opened 25 years ago
Closed 25 years ago
location bar: /foo/bar should try file:/foo/bar
Categories
(Core :: Networking, defect, P3)
Tracking
()
VERIFIED
FIXED
M15
People
(Reporter: mcafee, Assigned: jud)
References
Details
(Whiteboard: help wanted)
Attachments
(5 files)
(deleted),
patch
|
Details | Diff | Splinter Review | |
(deleted),
patch
|
Details | Diff | Splinter Review | |
(deleted),
patch
|
Details | Diff | Splinter Review | |
(deleted),
patch
|
Details | Diff | Splinter Review | |
(deleted),
patch
|
Details | Diff | Splinter Review |
Linux, apprunner.
Type in an absolute file path into the URL bar,
it should get prefixed with "file:". Instead,
a "http:" prefix shows up.
There's some platform-specific stuff that needs to happen here.
Updated•25 years ago
|
Assignee: gagan → valeski
Status: ASSIGNED → NEW
Comment 2•25 years ago
|
||
I think Jud should get this since it seems related to the keyword/www.*.com
work he's doing. I think that if the string that the user typed into the
location bar fails to build a valid URL, we need to:
- try keywords (if they're enabled)
- if the string doesn't seem to start with a scheme (alphanumerics up to a
colon), try prepending http:, then try file: and perhaps ftp:
- if that still fails, try fixing up the host name (www.*.com, etc.)
Comment 3•25 years ago
|
||
I have a fix for this. It is located in nsWebShell.cpp. Currently
convertFileToURL does nothing when not XP_PC. I changed it for non XP_PC to
prepend the url with file:/// if it starts with a /. Can someone test this on
the mac to see how it behaves there?
The attached diff fixes also another problem in nsWebShell.cpp (see bug 15315).
Feel free to also test this.
Comment 4•25 years ago
|
||
Reporter | ||
Comment 5•25 years ago
|
||
We should make this change XP_UNIX and file
a Mac-specific bug so Mac people can look at
this problem. Other OS's are here too, so ?
might want to be conservative and not solve the
non-Windows problem just yet.
Comment 6•25 years ago
|
||
Agreed, but I think the real distinction here is if drive letters are used or
not. Is there a define for that?
Comment 7•25 years ago
|
||
Comment 8•25 years ago
|
||
Reporter | ||
Comment 9•25 years ago
|
||
A given file, let's take /etc/passwd, should resolve to
file:///etc/passwd (file://empty-hostname-for-local-FS/etc/passwd)
Adding shaver.
Reporter | ||
Comment 10•25 years ago
|
||
Attaching new patch so we get file:///etc/passwd on unix,
Jud what does this do on Win32? Can you review?
Reporter | ||
Comment 11•25 years ago
|
||
Comment 12•25 years ago
|
||
With the current version of nsStdURL.cpp it is not save to get always a / as
start of the urlpath (at least on windows with file urls). I guess that is the
reason the file prefix was with three / to ensure this. See bug 15069 for a
patch to fix that problem. After that fix I think it's save to use file:// as
prefix.
Comment 13•25 years ago
|
||
Comment 14•25 years ago
|
||
I dont think we should special case nsStdURLs parsing. This solution has to lie
outside the standard parsing routines.
Comment 15•25 years ago
|
||
*** Bug 17251 has been marked as a duplicate of this bug. ***
Comment 16•25 years ago
|
||
This whole process needs to be accommodated in the new webshell design. The
current mechanism only trys slapping on a prefix and detecting if it's a valid
URL (syntactically) before causing the load. What we need is the ability to
detect the load failure, and try a different URL (e.g. file://... or
keyword:...).
Note that this is also part of bug 2875 (keyword urls).
Comment 17•25 years ago
|
||
This is really an xp thing.
Also see bug 16897 for related issues.
OS: Solaris → other
Hardware: Sun → All
Summary: Unix URLbar: /foo/bar should -> file:/foo/bar → location bar: /foo/bar should try file:/foo/bar
Comment 18•25 years ago
|
||
Bulk move of all Necko (to be deleted component) bugs to new Networking
component.
Assignee | ||
Updated•25 years ago
|
Target Milestone: M14 → M15
Comment 19•25 years ago
|
||
No need to move to M15, this is fixed now
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•