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

VERIFIED FIXED in mozilla1.8alpha3

Status

VERIFIED FIXED
18 years ago
4 years ago

People

(Reporter: gjackson227, Assigned: Biesinger)

Tracking

Trunk
mozilla1.8alpha3
x86
Windows NT
Dependency tree / graph

SeaMonkey Tracking Flags

(tracking-b2g:backlog, seamonkey2.29?)

Details

Attachments

(2 attachments, 6 obsolete attachments)

(Reporter)

Description

18 years ago
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

18 years ago
xpapps
Assignee: asa → vishy
Component: Browser-General → XP Apps
QA Contact: doronr → sairuh
Can be reproduced by me. Maybe there are some settings missing, which the
installer (.exe) might do.

Build ID: 2001021508
OS: Win2k
(Reporter)

Comment 3

18 years ago
Did you create the shortcut in IE? This seems only to happen with IE shortcuts.
Yes, that were IE shortcuts (.url) - but it wasn't a but for me while using
Mozilla 0.6
methinks this is bug 41985.

*** This bug has been marked as a duplicate of 41985 ***
Status: UNCONFIRMED → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → DUPLICATE
(Reporter)

Comment 6

18 years ago
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?
Status: RESOLVED → UNCONFIRMED
Resolution: DUPLICATE → ---

Comment 7

18 years ago
ben, need ie help here.
Assignee: vishy → ben
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

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

Status: UNCONFIRMED → NEW
Ever confirmed: true

Comment 10

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

Comment 11

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

Comment 12

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

Comment 13

17 years ago
This seems to be fixed somehow

Comment 14

17 years ago
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

17 years ago
See also bug 89220, ie favorites in non-standard location are not functional.
Status: NEW → ASSIGNED
Target Milestone: --- → Future

Comment 16

17 years ago
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

17 years ago
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.

Updated

17 years ago
Summary: Opening Internet Shortcuts dont work → Opening Internet Shortcuts (.url files) doesn't work

Comment 18

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

Comment 19

17 years ago
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

16 years ago
*** Bug 157093 has been marked as a duplicate of this bug. ***
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

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

Comment 23

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

Comment 24

16 years ago
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

16 years ago
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

16 years ago
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

16 years ago
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

16 years ago
(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.

QA Contact: sairuh → pmac

Comment 29

16 years ago
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.
Keywords: mozilla1.3
Summary: Opening Internet Shortcuts (.url files) doesn't work → Opening Internet Shortcuts (.url files) doesn't work (using File | Open or file protocol)

Comment 30

16 years ago
*** Bug 192345 has been marked as a duplicate of this bug. ***
*** Bug 208557 has been marked as a duplicate of this bug. ***

Comment 32

15 years ago
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"). 
Filext gives .url files' MIME type as wwwserver/redirection if this is any help.
Note: also applies to Firebird 0.7

Updated

15 years ago
Blocks: 164421
taking (can probably be implemented as a stream converter)
Assignee: bugs → cbiesinger
Status: ASSIGNED → NEW
Target Milestone: Future → mozilla1.7alpha
Created attachment 135652 [details] [diff] [review]
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.
Attachment #135652 - Flags: review?(darin)
Status: NEW → ASSIGNED

Comment 36

15 years ago
hmm.. interesting.  can the .url reading code be factored out somehow?  it seems
wrong to have to duplicate this code.
Comment on attachment 135652 [details] [diff] [review]
patch

ok, will do that
Attachment #135652 - Attachment is obsolete: true
Attachment #135652 - Flags: review?(darin)
(see netscape.public.mozilla.xpcom or .netlib for some discussion about how to
implement this)
Attachment #136077 - Flags: review?(darin)
Comment on attachment 136077 [details] [diff] [review]
patch v2

this can be done better...
Attachment #136077 - Flags: review?(darin) → review-
Created attachment 136357 [details] [diff] [review]
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.
Attachment #136077 - Attachment is obsolete: true
Attachment #136357 - Flags: review?(darin)

Comment 42

15 years ago
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

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

Comment 44

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

Comment 45

15 years ago
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.
Attachment #136357 - Flags: review?(darin) → review-
(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)
Created attachment 143792 [details] [diff] [review]
patch v4

I noticed that the last patch (v3) was missing some files... I'll attach the
patch for them separately
Attachment #136357 - Attachment is obsolete: true
Created attachment 143801 [details] [diff] [review]
use this in some other files
Attachment #143792 - Flags: review?(darin)
Attachment #143801 - Flags: review?(darin)
(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

15 years ago
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.
(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

15 years ago
(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? 

 

(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
Attachment #143801 - Flags: review?(darin)
Created attachment 143888 [details] [diff] [review]
patch for callers, v2
Attachment #143801 - Attachment is obsolete: true
Attachment #143888 - Flags: review?(darin)

Comment 55

15 years ago
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
Attachment #143792 - Flags: review?(darin) → review+

Comment 56

15 years ago
(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

15 years ago
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

15 years ago
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.
Attachment #143888 - Flags: review?(darin)

Comment 59

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

Comment 60

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

Updated

15 years ago
Keywords: mozilla1.3
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.
Attachment #143888 - Flags: review?(darin)
(those were links to file: uris. I created them with internet explorer)

Comment 63

15 years ago
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
Attachment #143888 - Flags: review?(darin) → review+
Comment on attachment 143888 [details] [diff] [review]
patch for callers, v2

I'll make those changes
Attachment #143888 - Flags: superreview?(bryner)
Comment on attachment 143792 [details] [diff] [review]
patch v4

I'll change nsIFileProtocolHandler's uuid before checking in
Attachment #143792 - Flags: superreview?(bryner)

Comment 66

15 years ago
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
Attachment #143792 - Flags: superreview?(bryner) → superreview?(bzbarsky)
Attachment #143888 - Flags: superreview?(bryner) → superreview?(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

14 years ago
+    // 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 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...
Attachment #143792 - Flags: superreview?(bzbarsky) → superreview+
> That said, please do document that you're assuming lpTemp is UTF-8.

Never mind.  Just read comment 61.
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.
Attachment #143888 - Flags: superreview?(bzbarsky) → superreview+
jshin filed the firefox bug already (bug 248538)
Target Milestone: mozilla1.7alpha → mozilla1.8beta
Created attachment 153329 [details] [diff] [review]
full patch, updated to trunk
Attachment #143792 - Attachment is obsolete: true
Attachment #143888 - Attachment is obsolete: true
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
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago14 years ago
Resolution: --- → FIXED
Created attachment 153346 [details] [diff] [review]
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)
Target Milestone: mozilla1.8beta → mozilla1.8alpha3

Comment 76

14 years ago
*** Bug 253050 has been marked as a duplicate of this bug. ***
Product: Core → Mozilla Application Suite

Comment 77

14 years ago
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

14 years ago
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.

Updated

14 years ago
No longer blocks: 164421

Updated

14 years ago
Blocks: 158464

Comment 79

14 years ago
Please reopen, at least in Firefox 1.0.2 German this can still be reproduced.
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).
*** Bug 289159 has been marked as a duplicate of this bug. ***

Comment 82

13 years ago
(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

13 years ago
(In reply to comment #82)
> (In reply to comment #80)
> > J&#65533;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

13 years ago
(In reply to comment #83)
> (In reply to comment #82)
> > (In reply to comment #80)
> > > J&#65533;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

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

Comment 86

9 years ago
Verifying for file protocol, for File Open a separate bug 251651 was filed (and buried).
Status: RESOLVED → VERIFIED
[Tracking Requested - why for this release]:
tracking-b2g: --- → ?
why to track it
tracking-firefox34: --- → ?

Updated

4 years ago
tracking-firefox34: ? → ---
tracking-seamonkey2.29: --- → ?
tracking-seamonkey2.30: --- → ?
tracking-seamonkey2.31: --- → ?
tracking-seamonkey2.32: --- → ?
tracking-seamonkey2.33: --- → ?
tracking-seamonkey2.34: --- → ?

Updated

4 years ago
tracking-seamonkey2.30: ? → ---
tracking-seamonkey2.31: ? → ---
tracking-seamonkey2.32: ? → ---
tracking-seamonkey2.33: ? → ---
tracking-seamonkey2.34: ? → ---
You need to log in before you can comment on or make changes to this bug.