288308 - Firefox gets confused when requesting '.lnk' files

Status: RESOLVED WORKSFORME

(Core Graveyard :: File Handling, defect)

Description

[tommyjb]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6) Gecko/20050225 Firefox/1.0.1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6) Gecko/20050225 Firefox/1.0.1

If I set up a local HTTP server, and request some file ending in '.lnk', Firefox
gives me an error that the file cannot be found.  Note that the server doesn't
give me an error -- the server sends the file and Firefox receives it.  Firefox
shows the error message in a *message box*.

Reproducible: Always

Steps to Reproduce:
1. Set up an HTTP server, which can give access to a file ending in '.lnk'.
2. Request that file in Firefox.

Actual Results:  
Taking the file name to be 'foo.lnk', Firefox pops up a message box which reads,
"The file /foo.lnk cannot be found.  Please check the location and try again."

Expected Results:  
Firefox should've let the user open that file.

Comment 1

[Anne (:annevk)]

And this is specific to '.lnk' extensions? All others work fine?

Comment 2

[tommyjb]

(In reply to comment #1)
> And this is specific to '.lnk' extensions? All others work fine?

Yes - I can only reproduce this with files ending in '.lnk'.  All others I've
tried work fine.

(Note that I just changed the title -- I wrote 'sending' when I meant 'receiving'.)

Comment 3

[William Bumgarner [:zsinj]]

Tom - Do you have an example .lnk file that you can provide a link to?

Also, I would suggest that you update your version of Firefox. You can get 1.2.0
off of the main download page or a nightly build from
http://www.mozilla.org/developer/ (reccomended for reporting purposes).

Thank you.

Comment 4

[Matthias Versen [:Matti]]

>Set up an HTTP server, which can give access to a file ending in '.lnk'.
Which server on which platform ?
Do you have an example URL ?

This is wfm with http://www.mversen.de/test.lnk and a current Mozilla CVS trunk
and FF1.0.2 on win2k3

Comment 5

[Matthias Versen [:Matti]]

ok, I see this with a changed content-type :
http://www.mversen.de/mozilla/rar/mozilla.lnk

I bet that this is caused by a security check.

Comment 6

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

I'd like to blame windows for this...

Comment 7

[tommyjb]

Sorry for the late reply on this.

I downloaded 1.0.2 and the problem persists with it.

It seems that this problem occurs with any file whose name ends in '.lnk' --
even a zero-byte file.

The server I'm using is one I'm in the process of developing.  It's running on
WinXP.  The server is sending a Content-Type of 'application/octet-stream' for
Windows link files.

I believe that this is enough info; please reply if you need more.

Comment 8

[William Bumgarner [:zsinj]]

Using the testcase in comment 5, this is WFM with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060726 Minefield/3.0a1

Please download the most recent test build at the link provided in comment 3.

Comment 9

[tommyjb]

Still doesn't WFM, with either of the following:

1. Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060726 Minefield/3.0a1

2. Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1b1) Gecko/20060726 BonEcho/2.0b1

Comment 10

[tommyjb]

Attachment: Requesting the resource linked to in comment 5, with latest Minefield

Comment 11

[tommyjb]

Attachment: Requesting a 'lnk' file through a local server, with latest Minefield

Comment 12

[Ryan Jones-Ward [:sciguyryan]]

Reading the comments in bug #194357 it seems that this is a dupe of that bug. If you think not please change this back too new. (The fix for bug #194357 should fix the error message)

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

Comment 13

[Mostafa Hosseini]

Another good reproducible case is: http://bugzilla.mozilla.org/attachment.cgi?id=250644
from bug 366087 which is probably a dupe but has this good test case.

Comment 14

[tommyjb]

I cannot reproduce this problem with the latest trunk nightly (20100905 on Windows 7) using the test cases in Comment 5 and Comment 13.