87594 - Mishandling of .URL files w/ file: relative urls

Status: NEW

(Firefox :: File Handling, defect)

Description

[Denis Vlasenko]

When clicked from dir view of Mozilla, this TEST.URL
------------------
[InternetShortcut]
URL=file:HTML/www.w3.org_TR_REC-CSS1.htm
Modified=308C197983EDC0017F
------------------
does not open .htm file. It shows .url file itself.
Same happens when one drops .url onto Mozilla from Win Explorer via "Send To".
When you drag-n-drop .url into already opened Mozilla, nothing happens.

Comment 1

[Ferdinand]

*** This bug has been marked as a duplicate of 69114 ***

Comment 2

[Ferdinand]

note that .url files should look like this:
[DEFAULT]
BASEURL=http://www.mozilla.org/

[InternetShortcut]
URL=http://www.mozilla.org/
Modified=C02E97D278FDC0018D

which will will work with drag/drop so this is partially invalid,
however when using File->Open File... to view it the .url file's contents are
shown (which is bug 69114 )

Comment 3

[Ferdinand]

forgot to mention the file 'protocol' requires 3 trailing slashes
so
[InternetShortcut]
URL=file:///HTML/www.w3.org_TR_REC-CSS1.htm
Modified=308C197983EDC0017F

should work (if you have a directory called HTML containing specified file in
the root directory of current partition, i dont think relative locations work)

Comment 4

[timeless]

that's clearly not the way the file system is layed out.

this is windows. file:HTML/ would imply relative to some random directory, 
(it's very much wrong but...)

file:///C|/Documents and Settings/Me/Desktop/HTML/www.w3.org_TR_REC-CSS1.htm 
would be a more valid entry.

I think the duplicate resolution is bogus and would prefer to ask the reporter 
how he created the .url file

Comment 5

[Denis Vlasenko]

Maybe it is not a totally valid .url file

[InternetShortcut]
URL=file:HTML/www.w3.org_TR_REC-CSS1.htm
Modified=308C197983EDC0017F

But I use it with MSIE 5 and it works fine.
MSIE interprets it like file HTML/www.w3.org_TR_REC-CSS1.htm
relative to the directory containing .url file
I can copy/move/targz/... such .urls along with subdirs and nothing
breaks up. Absolute filename wouldn't work.

Comment 6

[Asa Dotzler [:asa]]

->necko

Comment 7

[Keyser Sose]

That is no wear near anything in the spec. Marking INVALID we uphold to the spec
and i dont see any reason to change it.

Comment 8

[timeless]

um, let's play at least vaguely nicely.

google search turns up the following (listed in no particular order) -- all 
urls are google cache.
http://www.google.com/search?q=cache:I7BtqnEbqzk:www.openoffice.org/www-interfa
ce-announce/msg00217.html+file:+protocol+relative+path&hl=en
File URLs: Can be absolute or relative. Absolute URLs always must begin with a 
prepending "file:" protocol scheme, relative URLs can begin with a protocol 
scheme but are never prepended with a protocol scheme on output. The protocol 
scheme if case insensitive but is alwyas lower case on output.
-first note that there's a misspelling- don't worry everyone does that :(

Unfortunately that spec like thing is rather confusing, it talks about UTF16 
and UTF8 encoding, we will have to contact the author [if we care].

http://www.google.com/search?q=cache:UST6qFDLbAw:www.microsoft.com/devonly/tech
/amov1doc/amsdk008.htm+file:+protocol+relative+path&hl=en

Following are two examples of explicit references. The first example uses the 
http protocol to access the file. The second uses a network path and
filename. 
"http:\\amovie\samples\web\RoadRun.avi" 
"file:\\amovie\samples\web\RoadRun.avi" 
<whoops. the first example isn't valid. so much for using that company's pages 
as a definitive reference.>
Here is an example of a relative reference. 
"\samples\web\RoadRun.avi" 
<um, that's nice, but there's no protocol spec>

http://www.google.com/search?q=cache:qn6F0yOMrOs:msdn.microsoft.com/library/psd
k/dasdk/pg_a1reb.htm+file:+protocol+relative+path&hl=en
This page is too abstract for me.
path 
      Specifies the sequence of directories leading to the target. If resource 
is omitted, the target is the last directory in path. 

A relative URL locates a resource using an absolute URL as a starting point. In 
effect, the "complete URL" of the target is specified by concatenating
the absolute and relative URLs. A relative URL typically consists only of the 
path, and optionally, the resource, but no scheme or server.

<no scheme. so "./foo.html" might be a relative file url.>

http://www.google.com/search?q=cache:rCNjMlJUIC4:catsic.ucsc.edu/FITC/Instructi
ons/url.html+file:+protocol+relative+path&hl=en
<implies relative urls have no scheme, which sounds familiar>

http://www.google.com/search?q=cache:ftP6enX-mwU:community.roxen.com/developers
/idocs/rfc/rfc1808.html+file:+protocol+relative+path&hl=en
appears to be a specification for relative urls

http://www.google.com/search?q=cache:vF8BOS2PSkY:www.mvps.org/htmlhelpcenter/fa
q.htm+file:+protocol+relative+path&hl=en
talks about broken relative paths :)

conclusion, we should probably support that url format anyways because ms is 
using it. or we could write an RFC with some other format for relative-file 
urls.

Reporter: if you care (you seem to) it'd be great if you could search msdn for 
an some documentation about .url or ie's handling of relative paths.

Comment 9

[timeless]

confirming because it's clear we don't support whatever whacky scheme ms is 
using.

Comment 10

[Doug Turner (:dougt)]

pink, did you write the InternetShortcut handling code?

Comment 11

[Mike Pinkerton (not reading bugmail)]

i did write that code, with some help from win32 nerds. I didn't read the whole 
discussion, but that url doesn't look valid. Did they change the shortcut file 
format on us?

reporter, what OS are you using? what version of IE?

Comment 12

[Doug Turner (:dougt)]

moving out.

Comment 13

[Denis Vlasenko]

NT 4.0, IE 5.0
(NT 4.00.1381 SP 5, IE 5.00.2314.1003 if you need to know exactly :-)

My .URLs are constructed by hand. I wanted an .URL file which says
(for example): "MySQL/manual_Introduction.html
_relative_to_the_dir_where_this_.URL_is_". It turns out IE will handle
this file exactly as I want:
--MySQLdoc.URL-------------------------
[InternetShortcut]
URL=file:MySQL/manual_Introduction.html
---------------------------------------
However, Mozilla do not open it.
If that is not valid .URL, pls tell me how to make an .URL file
with relative path right. I need it. I like it. It's an amazing
alternative to Windows .LNK files!

I wish the best for Mozilla team. I want it to beat MSIE everywhere!!!

Comment 14

[Denis Vlasenko]

http://community.roxen.com/developers/idocs/rfc/rfc1808.html
If I grok RFC1808, an .URL file with relative path might look like
---
[InternetShortcut]
URL=MySQL/manual_Introduction.html
---
'coz 'base URL' is 'file:///dir/dir/file.url' - a path to .URL file itself
presuming it is retrieved from your local filesystem.
(This is my understanding of RFC1808. Am I right?)
However, that does not work with Mozilla. IE doesn't grok it too.

Comment 15

[Denis Vlasenko]

What about handling .URL files:
---
[InternetShortcut]
URL=(some string)
---
the same way as:
---
<html><body><a href="(some string)">Go there</a></body></html>
---
This will handle relative paths. We can have a notion of base url
for an .URL file just the same as for a .HTML file.
.URL files can be clicked in local dir view
(base url - file:///dir/dir/file.url),
in FTP dir listings (base url - ftp://host/dir/dir/file.url),
in HTTP dir listings (base url - http://host/dir/dir/file.url).
Looks like this will conform to RFC1808.

Comment 16

[Andreas Otte]

You could always remove the scheme portion of the URL to make it a relative URL.
 Relative URLs with prependeing schemes are long deprecated and it was deceided
to not support them in mozilla anymore, see beug 22251 or bug 40670 for some
discussions about this ...  

Comment 17

[Scott Tran (Wildcard)]

Doing a bit of testing with .URL in format
[InternetShortcut]
URL=someHtmlFile

I discovered that the URL doesn't allow relative paths and only works when a
full path is entered which means something like
URL=file///foo.html 
will NOT work, instead the full path like 
URL=file///C:/foo.html
Timeless suggested using
<html><meta http-equiv="refresh" content="0; url=bleh/foo.html"></html>
in an HTML file in foo.html was located in bleh subdirectory, Notice the /
instead of \ this works in Mozilla and IE...

Comment 18

[benc]

It sounds like there are two things going on here.

Confusion about non-absolute file URLs: actually most of these google documents 
seem to restate what is described in RFC 1630 and later. You should be using the 
location of the .URL file as the BASE. If there is nothing wrong with what MS 
did here (b/c I couldn't easily see it from reading), then this bug is INVALID.

Open / Display of .URL files: something other than displaying the text contents 
of the file itself. There seem to be many other bugs that tangentially talk 
about .URL handling. Perhaps there is a dupe, or this discussion should become a 
new bug. If you contribute to this feature, please remember to make this work 
across platforms!

Comment 19

[benc]

For now, I'm not going to test this.

Comment 20

[Doug Turner (:dougt)]

we need to look at how we handle .URL files on windows.

Comment 21

[Andrew Hagen]

Is this still a problem?

Comment 22

[Ioana (away)]

WFM on Mozilla/5.0 (Windows NT 5.1; rv:26.0) Gecko/20100101 Firefox/26.0.

Firefox and IE shortcuts are opened fine in Firefox 26 when double-clicking them, drag&drop and when using the Open File option.

Does anyone still reproduce this issue?