69114 - Opening Internet Shortcuts (.url files) doesn't work (using File | Open or file protocol)

Status: VERIFIED FIXED

(SeaMonkey :: UI Design, defect)

Description

[Gavin Jackson]

From Bugzilla Helper:
User-Agent: Mozilla/4.7 [en] (WinNT; U)
BuildID:    2001021508

Opening internet shortcuts dont work.

Reproducible: Always
Steps to Reproduce:
1.Go to Yahoo in IE
2.Right click and select Create Shortcut
3.Open the resulting shortcut file in Mozilla.

Actual Results:  It displays the text of the .url file.

Expected Results:  It should interpret the .url file and go to the address in 
the shortcut.

Opening the shortcuts in NS4 works.

Comment 1

[timeless]

xpapps

Comment 2

[Peter 'vt100' Schwindt]

Can be reproduced by me. Maybe there are some settings missing, which the
installer (.exe) might do.

Build ID: 2001021508
OS: Win2k

Comment 3

[Gavin Jackson]

Did you create the shortcut in IE? This seems only to happen with IE shortcuts.

Comment 4

[Peter 'vt100' Schwindt]

Yes, that were IE shortcuts (.url) - but it wasn't a but for me while using
Mozilla 0.6

Comment 5

[sairuh (rarely reading bugmail)]

methinks this is bug 41985.

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

Comment 6

[Gavin Jackson]

How can this be a dup of 41985? 41985 is about the title of the shortcut. This 
one is about opening IE shortcuts.
and for Peter, what are you saying in your last post?

Comment 7

[Chris McAfee]

ben, need ie help here.

Comment 8

[Peter 'vt100' Schwindt]

Oops, I noticed that there are _two_ Subfolders called "Imported IE Favorites"
in the bookmarks folder. One with those "<title>.url" booksmarks and one with
only the title. Those with .url won't work. The other one does. Maybe there's a
problem with importing bookmarks from elder Mozilla installs.

Bug 41985 is about the same, but this one here is about the problems resulting
from 41985...

Comment 9

[Koike Kazuhiko]

Mozilla can't open a shortcut created by NC4.7.

Comment 10

[ajbu]

Looks like a duplicate of bug 58403 (or at least highly related..)

Comment 11

[otto]

With Mozilla 0.9, this is now happening from the "Imported IE Favorites"
bookmark menu.

Comment 12

[Ferdinand]

*** Bug 87594 has been marked as a duplicate of this bug. ***

Comment 13

[basic]

This seems to be fixed somehow

Comment 14

[Denis Vlasenko]

In 0.9.2 it still shows contents of .URL for me instead of following it:
[InternetShortcut]
URL=http://www.ibiblio.org/pub/packages/samba/docs/htmldocs/Samba-HOWTO-
Collection.html
Modified=3016B0457621C10194

Comment 15

[Jesse Ruderman]

See also bug 89220, ie favorites in non-standard location are not functional.

Comment 16

[Luke Deller]

This ".url" internet shortcut file format seems to be built into Windows rather
than just IE:
When I right-click on the desktop and choose "New -> Shortcut", and type in a
URL instead of a file for the location, then a ".url" file is created.

Microsoft seems to expect the system's default browser to be able to handle such
internet shortcuts, because they break when I set Mozilla to be my default
browser (ie double-clicking on a shortcut does nothing).  [I'm using Win2K.]

Comment 17

[Gabriel Radic]

The "Internet Shortcut" format is the way URLs are saved in Windows.
If you drag an URL icon OR a link from either Mozilla, IE or any IEoid (e.g.
Outlook Express), an "Internet Shortcut" file will be created. Mozilla creates
these files correctly, so I guess the problem isn't here.

There are three ways of opening "Internet Shortcuts" in Mozilla on Windows.

1. Double-click the shortcut when Mozilla is the default browser.
   This will open the correct URL in Mozilla BUT gives an error message as if the 
   file does not exist. I repeat, Mozilla does open correctly the page AND you
   get an error message sayng [The file "URL..." cannot be found. etc.] What's
   weird is that the message says that the _name_of_the_file_ not found is the
   actual _URL_ not the real file name. E.g. [The file "http://www.yahoo.com"
   cannot be found. etc.] when the shortcut file name is Yahoo.

1b.I have to mention that exactly the same happens when I open a URL by typing it
   in the RUN dialog. Go to the Windows Start menu and choose Run, type
   "http://www.yahoo.com" and hit enter. I guess the problem has the same source.


2. Drag the Internet Shortcut file in a Mozilla browser window.
   This works without any problems.

3. From a bookmark to a folder containing Internet Shortcuts
   E.g. Add a bokkmark to your Favorites folder containing the IE favorites.
   Mozilla will show the bookmark as a folder and I can browse the favorites
   folder nicely. But when I click on an internet shortcut file I will get it's
   text content instead of Mozilla openning the URL. See the behavior described
   in the comment http://bugzilla.mozilla.org/show_bug.cgi?id=69114#c14

I hope this is clearer now. Maybe these should be splitted in two separate bugs,
one for the first case and another for the third.

Comment 18

[Josue Aron]

*** Bug 139937 has been marked as a duplicate of this bug. ***

Comment 19

[Erik Hanson]

As recently as 0.9.9 having .url files in your bookmarks worked perfectly, I had
my entire IE Favorites set up as a bookmark with the location set as
'file:///H|/INI/FAVORITES/Links/Reference' and it worked fine. 1.0rc1+ seem to
have broken this quirk, which is unfortunate, as it was a great read-only
solution to the whole Favorites/.url problem..

Comment 20

[WD]

*** Bug 157093 has been marked as a duplicate of this bug. ***

Comment 21

[Steven Neil Groginsky]

Can't find any better place to put this comment.  I have Mozilla Internet
Shortcut filetype and Internet Shortcut filetype (IE) on my 98se system. 
Mozilla shortcut runs Mozilla -u.  Internet shortcut runs rundll and hooks into
an explorer extension in the registry.  Old shortcuts probably created with IE
run IE.

Comment 22

[Daniel Wang]

*** Bug 163389 has been marked as a duplicate of this bug. ***

Comment 23

[Elmar Ludwig]

*** Bug 168451 has been marked as a duplicate of this bug. ***

Comment 24

[Sebastian Lisken]

As I descripe in Bug 168451, there is another way to reproduce this bug. Drag a
shortcut file onto a shortcut to the Mozilla.exe file, such as the one put into
the start menu during installation. Or, equivalently, add the .url file to the
command line when starting Mozilla, but without any other options. I want the
drag-and-drop to work, so suggesting options won't do.
By the way, while some .URL files will get their contents listed in a Mozilla
windows, others cause Mozilla to open a "Save As" dialog. These include the ones
written by Netscape 4.7 or Mozilla itself, which have an extra NUL in them (that
NUL is the topic of Bug 103468).

Comment 25

[Stefan Bauer]

Just checked with Mozilla/5.0 (Windows; U; Windows NT 5.0; de-AT; rv:1.1)
Gecko/20020826 MultiZilla/v1.1.21

I notice this behaviour:
1. try to open an local URL-File with File/Open File
2a. if the target is local (i.e. URL=file:///D:/index.html) the page opens as
expexted
2b. if the target is on the web (i.e.
URL=http://www.mozilla.org/mozorg.html) I get an error message "der
angegebene Dateiname ist ungültig" (given file name is not valid).

Double clicking on url-file in Explorer works as expected.

Looks like a problem in open-file-dialog

Stefan

Comment 26

[Mike Calmus]

This doesn't work with Mozilla 1.2a on MacOS X either. Instead of displaying the
text of the file, though, Mozilaa asks whether to save it to disk or open it
with a specific application.

Comment 27

[Andrew Hagen]

There have been recent check-ins in this area.

Worksforme, Build ID 2002120708, pre 1.3 alpha. 

Reporter, please download and install the latest-trunk build of Mozilla and try
it again. It should now work.

Comment 28

[Forest]

(Build ID 2002120908, pre-1.3 alpha, Windows 2000 sp3)

As of this Mozilla build, I can use File->Open to select a .url file, and
Mozilla will now open the corresponding URL *some* of the time.  However:


If the URL contains a query string, Mozilla produces an error popup window,
saying "The above file name is invalid."  For example of failure, try a Windows
shortcut to this URL:  
http://yro.slashdot.org/article.pl?sid=02/10/14/1942257&mode=thread&tid=103


If I type the Windows shortcut file's path (or file:/// URL) into the address
bar, Mozilla still shows me the shortcut file's contents instead of navigating
to the URL it contains.  For example, I have a shortcut file called
"DMCA-Comments.url"  in the root of my D: drive.  Putting
file:///D:/DMCA-Comments.url into the address bar causes Mozilla to display the
following:
[DEFAULT]
BASEURL=http://yro.slashdot.org/article.pl?sid=02/10/14/1942257&mode=thread&tid=103
[InternetShortcut]
URL=http://yro.slashdot.org/article.pl?sid=02/10/14/1942257&mode=thread&tid=103
Modified=F01F0FBFCB73C201DE


I can bookmark the Windows shortcuts directory on my local file system, and that
bookmark will show up as a folder full of .url file bookmarks in the Mozilla
Bookmarks menu.  Selecting one of those bookmarks will display the .url file's
contents, rather than navigating to the appropriate URL.

Comment 29

[Andrew Hagen]

Good comment. Yeah, I see that too. Changing summary to reflect that the problem
occurs when we try to open a file of file type .url with the File | Open
facility or with the file protocol.

We just have to adjust our handling of this file type.

Comment 30

[Frankie]

*** Bug 192345 has been marked as a duplicate of this bug. ***

Comment 31

[Matthias Versen [:Matti]]

*** Bug 208557 has been marked as a duplicate of this bug. ***

Comment 32

[Gale Andrews]

This bug is a nuisance in another way too, as many applications have a built in 
button to access their home web page. With Mozilla set to default browser these 
buttons will not open the page (usually a custom" error is generated by the app 
something like "cannot open web page"). 

Comment 33

[Grey Nicholson (they/them)]

Filext gives .url files' MIME type as wwwserver/redirection if this is any help.
Note: also applies to Firebird 0.7

Comment 34

[Christian :Biesinger (don't email me, ping me on IRC)]

taking (can probably be implemented as a stream converter)

Comment 35

[Christian :Biesinger (don't email me, ping me on IRC)]

Attachment: patch

I dropped the streamconverter idea, mainly because I have no way to get at the
content type of the channel until I try loading it.

Comment 36

[Darin Fisher]

hmm.. interesting.  can the .url reading code be factored out somehow?  it seems
wrong to have to duplicate this code.

Comment 37

[Christian :Biesinger (don't email me, ping me on IRC)]

Comment on attachment 135652 [details] [diff] [review]
patch

ok, will do that

Comment 38

[Christian :Biesinger (don't email me, ping me on IRC)]

(see netscape.public.mozilla.xpcom or .netlib for some discussion about how to
implement this)

Comment 39

[Christian :Biesinger (don't email me, ping me on IRC)]

Attachment: patch v2

Comment 40

[Christian :Biesinger (don't email me, ping me on IRC)]

Comment on attachment 136077 [details] [diff] [review]
patch v2

this can be done better...

Comment 41

[Christian :Biesinger (don't email me, ping me on IRC)]

Attachment: patch v3

move check if file ends with .url into ReadURLFile, and call ReadURLFile on all
OSes.

this way, adding support for another os's url files only requires changing
ReadURLFile.

Comment 42

[Darin Fisher]

nit:

i think the interface should use nsIFile instead of nsILocalFile.  i don't think
you need to limit to local files (as if there were actually support for
something else).  it helps to be consistent with the methods already existing on
nsIFileProtocolHandler, which work with nsIFile.

more later...

Comment 43

[José Jeria]

*** Bug 232956 has been marked as a duplicate of this bug. ***

Comment 44

[Asa Dotzler [:asa]]

*** Bug 211730 has been marked as a duplicate of this bug. ***

Comment 45

[Darin Fisher]

Comment on attachment 136357 [details] [diff] [review]
patch v3

change nsIFile on ReadURLFile to nsILocalFile, and maybe use
NS_CopyNativeToUnicode instead of calling GetPath after calling GetNativePath. 
i'm guessing that you are getting the native path first as an optimization
since it involves no buffer copy.  that makese sense to me, but i'd recommend
documenting that fact.

you might also want to #ifdef out the code that calls ReadURLFile as an
optimization on platforms where ReadURLFile does nothing.

Comment 46

[Christian :Biesinger (don't email me, ping me on IRC)]

(In reply to comment #45)
> you might also want to #ifdef out the code that calls ReadURLFile as an
> optimization on platforms where ReadURLFile does nothing.

I considered that; but I wanted to keep the places that need changing when
adding support for this on another platform localized. (note: I intend to add
support for .desktop links sometime soon)

Comment 47

[Christian :Biesinger (don't email me, ping me on IRC)]

Attachment: patch v4

I noticed that the last patch (v3) was missing some files... I'll attach the
patch for them separately

Comment 48

[Christian :Biesinger (don't email me, ping me on IRC)]

Attachment: use this in some other files

Comment 49

[Christian :Biesinger (don't email me, ping me on IRC)]

(In reply to comment #45)
> and maybe use
> NS_CopyNativeToUnicode instead of calling GetPath after calling GetNativePath. 

Oops, forgot to make that change. I'll make that change; if you want I can
attach a new patch for that.

Comment 50

[Jungshik Shin]

cbie, the file in question has changed recently (around the place you're
patching). You'd better update your tree. Besides, the file has branched for
firefox so that you need to fix it, too.

Comment 51

[Christian :Biesinger (don't email me, ping me on IRC)]

(In reply to comment #50)
> cbie, the file in question has changed recently

which one?

> Besides, the file has branched for
> firefox so that you need to fix it, too.

no, I don't need to. I don't think this causes any bustage.

Comment 52

[Jungshik Shin]

(In reply to comment #51)
> (In reply to comment #50)
> > cbie, the file in question has changed recently
> 
> which one?

I didn't realize there are two files in the patch. It's
xpfe/components/bookmarks/src/nsBookmarksService.cpp

 
> > Besides, the file has branched for
> > firefox so that you need to fix it, too.
> 
> no, I don't need to. I don't think this causes any bustage.

 You don't have to, but why do you want to fix only one while leaving the other
alone when the patch involved can be just mechanically applied to the latter? 

 

Comment 53

[Christian :Biesinger (don't email me, ping me on IRC)]

(In reply to comment #52)
>  You don't have to, but why do you want to fix only one while leaving the other
> alone when the patch involved can be just mechanically applied to the latter? 

because it is so much more effort and not worth it. I'd have to check out a
firebird^Wfox tree, build it, apply my patch, and test it, and I'm not willing
to do that.

I'll attach a patch merged to trunk in a second

Comment 54

[Christian :Biesinger (don't email me, ping me on IRC)]

Attachment: patch for callers, v2

Comment 55

[Darin Fisher]

Comment on attachment 143792 [details] [diff] [review]
patch v4

>Index: public/nsIFileProtocolHandler.idl

> interface nsIFile;
>+interface nsILocalFile;

so this forward decl is no longer needed.


>+    /**
>+     * Takes a local file and tries to interpret it as an internet shortcut
>+     * (e.g. .url files on windows).
>+     * Throws NS_ERROR_NOT_AVAILABLE if the OS does not support such files.
>+     * Also throws an error if this file is no url file.
>+     * @param file The local file to read
>+     * @return The URI the file refers to
>+     */
>+    nsIURI readURLFile(in nsIFile file);

nit: use @throws

r=darin

Comment 56

[Darin Fisher]

(In reply to comment #49)
> (In reply to comment #45)
> > and maybe use
> > NS_CopyNativeToUnicode instead of calling GetPath after calling GetNativePath. 
> 
> Oops, forgot to make that change. I'll make that change; if you want I can
> attach a new patch for that.

no worries... your code is fine.

Comment 57

[Darin Fisher]

Comment on attachment 143888 [details] [diff] [review]
patch for callers, v2

>Index: xpfe/components/bookmarks/src/nsBookmarksService.cpp

>-            // As far as I can tell, IUniformResourceLocator::GetURL()
>-            // returns the URL in pure ASCII. However, it could be UTF-8 (I'm
>-            // almost sure that it's not in any legacy encoding) so that I'm
>-            // assuming it's in UTF-8.
>-            // http://msdn.microsoft.com/library/default.asp?url=/workshop/misc/shortcuts/reference/iuniformresourcelocator.asp
>+	    // ResolveShortcut gives us a UTF8 string (uri->GetSpec)

wow.. if this old comment is true, then it means that we need to do some
extra work to convert from the result of GetURL to the format required
for file:// URLs in Mozilla.  remember that file:// URLs in Mozilla use
the platform "native" charset (compatible with NS_NewNativeLocalFile).
the file:// URL string is always %-escaped in Mozilla, so that it can be
passed as a UTF-8 string.

Comment 58

[Darin Fisher]

Comment on attachment 143888 [details] [diff] [review]
patch for callers, v2

request r= again if you are satisfied that this patch doesn't have the problem
i mentioned.

Comment 59

[Jesiah S]

*** Bug 237039 has been marked as a duplicate of this bug. ***

Comment 60

[Alan]

Look, just right click a shortcut to a web page. Then choose "send to" 
firebird.exe and you will see the problem.

Comment 61

[Christian :Biesinger (don't email me, ping me on IRC)]

Comment on attachment 143888 [details] [diff] [review]
patch for callers, v2

that comment seems to be wrong. testing indicates that I do get back a uri in
the system charset (latin1).

when I use characters outside of latin1 here, I get question marks in the url.

Comment 62

[Christian :Biesinger (don't email me, ping me on IRC)]

(those were links to file: uris. I created them with internet explorer)

Comment 63

[Darin Fisher]

Comment on attachment 143888 [details] [diff] [review]
patch for callers, v2

>Index: xpfe/components/bookmarks/src/nsBookmarksService.cpp

>+            nsCAutoString resolvedURL;
>+            ResolveShortcut(currFile, resolvedURL);
>+	    // ResolveShortcut gives us a UTF8 string (uri->GetSpec)
>             rv = CreateBookmarkInContainer(name.get(),

nit: fix indentation on the comment


>Index: widget/src/windows/nsClipboard.cpp

>+    char* filepath = NS_REINTERPRET_CAST(char*, *outData);

maybe this should be |const char*| instead?


r=darin

Comment 64

[Christian :Biesinger (don't email me, ping me on IRC)]

Comment on attachment 143888 [details] [diff] [review]
patch for callers, v2

I'll make those changes

Comment 65

[Christian :Biesinger (don't email me, ping me on IRC)]

Comment on attachment 143792 [details] [diff] [review]
patch v4

I'll change nsIFileProtocolHandler's uuid before checking in

Comment 66

[Brodie]

Christian:
@@ -3884,26 +3858,20 @@ nsBookmarksService::ParseFavoritesFolder
  if (!extension.Equals(NS_LITERAL_CSTRING("url"),
    nsCaseInsensitiveCStringComparator()))

This could be modified to use Roc's recent string changes and call
LowerCaseEqualsLiteral instead.
http://lxr.mozilla.org/seamonkey/source/xpcom/string/public/nsTAString.h#245

Comment 67

[Boris Zbarsky [:bzbarsky]]

Nits for the IDL:

1) You should say _what_ error it throws if the file is not a url file
2) The phrasing should be "this file is not a url file" (or ".url file", whatever
   you decide on there).

More later tonight.

Comment 68

[Brodie]

+    // Getting the native path here for two reasons:
+    // o) To avoid a buffer copy
+    // o) To avoid a dependency on intl code for unicode comparison (when
+    //    checking whether filename ends in .url)
+    nsCAutoString nativepath;
+    nsresult rv = aFile->GetNativePath(nativepath);
+    if (NS_FAILED(rv))
+        return rv;
+    if (!StringEndsWith(nativepath, NS_LITERAL_CSTRING(".url"),
nsCaseInsensitiveCStringComparator()))
+        return NS_ERROR_NOT_AVAILABLE;
+
+    nsAutoString path;
+    rv = aFile->GetPath(path);
+    if (NS_FAILED(rv))
+        return rv;

You can actually use the unicode path here and use the new
LowerCaseEqualsLiteral method of the string class to compare against the last 4
characters case insensitive. LowerCaseEqualsLiteral is not dependent on intl. e.g.

    nsAutoString path;
    rv = aFile->GetPath(path);
    if (NS_FAILED(rv))
        return rv;
    if (path.Length() < 4)
        return NS_ERROR_NOT_AVAILABLE;
    if (!Substring(path, path.Length() - 4, 4).LowerCaseEqualsLiteral(".url"))
        return NS_ERROR_NOT_AVAILABLE;

Comment 69

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 143792 [details] [diff] [review]
patch v4

sr=bzbarsky, but I didn't verify general correctness of the win32 mumbo-jumbo
(I don't know enough about win32 to do that).

That said, please do document that you're assuming lpTemp is UTF-8.  The
bookmarks service had a link to an msdn page that you may want to keep linking
to here...

Comment 70

[Boris Zbarsky [:bzbarsky]]

> That said, please do document that you're assuming lpTemp is UTF-8.

Never mind.  Just read comment 61.

Comment 71

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 143888 [details] [diff] [review]
patch for callers, v2

>Index: xpfe/components/bookmarks/src/nsBookmarksService.cpp

The changes to this are fine.  File a bug on firefox to change their fork
accordingly?

>Index: widget/src/windows/nsClipboard.cpp

>+    if ( IsInternetShortcut(filepath) ) {
>+      nsCAutoString url;
>+      ResolveShortcut ( file, url );
>+      if ( !url.IsEmpty() ) {
...
>+        *outData = ToNewUnicode(url);
>+        *outDataLen = url.Length() * sizeof(PRUnichar);

I think you want UTF8ToNewUnicode(url) and you want to
nsCRT::strlen((PRUnichar*)outData).  What you're doing just zero-pads "url",
which is not desirable as far as I know.

sr=bzbarsky with those issues addressed.

Comment 72

[Christian :Biesinger (don't email me, ping me on IRC)]

jshin filed the firefox bug already (bug 248538)

Comment 73

[Christian :Biesinger (don't email me, ping me on IRC)]

Attachment: full patch, updated to trunk

Comment 74

[Christian :Biesinger (don't email me, ping me on IRC)]

Checking in netwerk/protocol/file/public/nsIFileProtocolHandler.idl;
/cvsroot/mozilla/netwerk/protocol/file/public/nsIFileProtocolHandler.idl,v  <--
 nsIFileProtocolHandler.idl
new revision: 1.12; previous revision: 1.11
done
Checking in netwerk/protocol/file/src/nsFileProtocolHandler.cpp;
/cvsroot/mozilla/netwerk/protocol/file/src/nsFileProtocolHandler.cpp,v  <-- 
nsFileProtocolHandler.cpp
new revision: 1.57; previous revision: 1.56
done
Checking in widget/src/windows/nsClipboard.cpp;
/cvsroot/mozilla/widget/src/windows/nsClipboard.cpp,v  <--  nsClipboard.cpp
new revision: 1.90; previous revision: 1.89
done
Checking in xpfe/components/bookmarks/src/nsBookmarksService.cpp;
/cvsroot/mozilla/xpfe/components/bookmarks/src/nsBookmarksService.cpp,v  <-- 
nsBookmarksService.cpp
new revision: 1.320; previous revision: 1.319
done

Comment 75

[Christian :Biesinger (don't email me, ping me on IRC)]

Attachment: bustage fixes

these additional bustage fixes were necessary

nsClipboard.cpp is not strictly a bustage fix, but fixes drag&drop for .url
files (and I think for other stuff too)

Comment 76

[Robert Parenton]

*** Bug 253050 has been marked as a duplicate of this bug. ***

Comment 77

[Jungshik Shin]

It seems like some changes made since July regressed this bug. With my trunk
build(mozilla suite), I tried to open an internet shortcut only to get an alert
that  "http://.... the above file name is invalid". firefox 1.0 and firefox
trunk build have the same probelm
 

Comment 78

[Jungshik Shin]

Typing the file:///..../...url in the url bar works (although the url bar has
'file:///..../..url' instead of the page url), but File | Open doesn't.

Comment 79

[Jörg Hartmann]

Please reopen, at least in Firefox 1.0.2 German this can still be reproduced.

Comment 80

[Boris Zbarsky [:bzbarsky]]

Jörg Hartmann, this bug was fixed in July 2004.  Firefox 1.0.2 uses a Gecko from
April 2004.  Please do test current trunk builds before commenting on bugs that
are targeted at trunk milestones (note the "Target Milestone" field of this bug).

Comment 81

[Matthias Versen [:Matti]]

*** Bug 289159 has been marked as a duplicate of this bug. ***

Comment 82

[Dave Burton]

(In reply to comment #80)
> Jörg Hartmann, this bug was fixed in July 2004.  Firefox 1.0.2 uses a Gecko from
> April 2004.  Please do test current trunk builds before commenting on bugs that
> are targeted at trunk milestones (note the "Target Milestone" field of this bug).

This bug is still present in FireFox 1.0.5.

Do this:  go to file:///C:/Documents%20and%20Settings/Administrator/Favorites/
(or wherever your IE6 Favorites folder is), and display the Favorites folder in
FireFox.  Click on a sub-folder, and it correctly shows you the contents.  But
click on a .url file, and it shows the contents of the .url file instead of
opening that page.  Right-click on the .url file, and there are eight choices,
including:

1) Open link in New Window -- shows the contents of the .url file (in a new window)
2) Open link in New Tab -- shows the contents of the .url file (in a new tab)
3) Save link as -- saves a copy of the .url file
4) Copy link location -- copies the path of the .url file to the clipboard
5) Properties -- displays the path of the .url file
6) Open link target in IE -- opens the target web site in a new FireFox tab (not
 in IE).

#2 should do what #6 does.

I tried to use "reopen bug" since the bug is NOT fixed, but Bugzilla wouldn't
let me.

-Dave Burton
dave154 at burtonsys.com

Comment 83

[Jungshik Shin]

(In reply to comment #82)
> (In reply to comment #80)
> > J�rg Hartmann, this bug was fixed in July 2004.  Firefox 1.0.2 uses a Gecko from
> > April 2004.  Please do test current trunk builds before commenting on bugs that
> > are targeted at trunk milestones (note the "Target Milestone" field of this
bug).
> 
> This bug is still present in FireFox 1.0.5.

Yes, it is. See comment #80, please. All the versions of Firefox 1.0.x use a
Gecko from April 2004. Got it? 

Comment 84

[Dave Burton]

(In reply to comment #83)
> (In reply to comment #82)
> > (In reply to comment #80)
> > > J�rg Hartmann, this bug was fixed in July 2004.  Firefox 1.0.2 uses
a Gecko from
> > > April 2004.  Please do test current trunk builds before commenting on bugs
that
> > > are targeted at trunk milestones (note the "Target Milestone" field of this
> bug).
> > 
> > This bug is still present in FireFox 1.0.5.
> 
> Yes, it is. See comment #80, please. All the versions of Firefox 1.0.x use a
> Gecko from April 2004. Got it? 


Oh, sorry, I didn't know that.

Also, (6) "Open Link Target in IE" (which actually opens .url files in FireFox,
for me) is from IEview, not base FireFox.  http://ieview.mozdev.org/

Thanks,
-Dave

Comment 85

[Michael Moy]

*** Bug 289500 has been marked as a duplicate of this bug. ***

Comment 86

[:Hb]

Verifying for file protocol, for File Open a separate bug 251651 was filed (and buried).

Comment 87

[konakanchi.priyanka.18]

[Tracking Requested - why for this release]:

Comment 88

[konakanchi.priyanka.18]

why to track it