66313 - Path of Shortcut [.lnk] is used as basehref instead of the HTML document's directory

Status: NEW

(Firefox :: File Handling, defect)

Description

[Val Sharp]

From Bugzilla Helper:
User-Agent: Mozilla/4.6 [en-gb]C-CCK-MCD NetscapeOnline.co.uk  (Win98; I)
BuildID:    2001012020

I have a 'shortcut' on my desktop -
target: "D:\WINDOWS\Profiles\Val\My Documents\W3Cspecs\HTML4.01\cover.html"
start in: "D:\WINDOWS\Profiles\Val\My Documents\W3Cspecs\Html4.01"

When I load this shortcut into Mozilla, it loads 'cover.html' OK, but the 
location in the address bar is:
file:///D:/WINDOWS/Profiles/Val/Desktop/HTML4.01.lnk

Of course, none of the links in 'cover.html' will now work, because Mozilla 
continues looking in 'file:///D:/WINDOWS/Profiles/Val/Desktop' for them.

e.g. file:///D:/WINDOWS/Profiles/Val/Desktop/index/elements.html, instead of 
file:///D:/WINDOWS/Profiles/Val/My 
Documents/W3Cspecs/HTML4.01/index/elements.html

Reproducible: Always

Expected Results:  When loading a document via a shortcut, the location address 
should become the 'target' address.

Comment 1

[Keyser Sose]

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

Comment 2

[Val Sharp]

At first glance it doesn't appear to be a duplicate.

Bug#41985 appears to refer to creating a shortcut from the Browser, not loading 
an already existing shortcut into the Browser.

(That my shortcut is on the desktop is also irrelevant - the same thing happens 
wherever the shortcut is.)

Ready to be corrected if this really is a duplicate.

Comment 3

[timeless]

arg. next time you'd be best advised to follow the guidelines.

Open is very ambiguous, i'll give you a list of ways to open something, and you 
can tell me if i even listed the one you used. Either way, please include 
exactly how you 'open'ed this file.

1. drag object [shortcut] to browser window
2. double click object [shortcut]
3. drag object [shortcut] to file [mozilla.exe]
4. type location of shortcut in location bar.
5. file>open page, double click on object [shortcut]
6. file>open location, enter url for shortcut in dialog.

I'm betting on 1. Steps to reproduce are very important and they should not be 
ambiguous.

Comment 4

[Val Sharp]

Apologies for skimping on 'Steps to reproduce'.

You win your bet on #1.

1. Drag object [shortcut] to browser window - reproduces this bug as described 
above.

2. Double click object [shortcut] - Mozilla's not my default browser.

3. Drag object [shortcut] to file [mozilla.exe] (or to Shortcut to Mozilla.exe) 
- causes 'Downloading' dialog i.e. "This file has mime type 
application/octet-stream and cannot be viewed using Mozilla ... etc..." (is this 
a  different bug?)

4. Typing location (or path) of shortcut in location bar - reproduces this bug.
   
5. File>open file, double click on object [shortcut] (or enter path of shortcut 
in dialog) - works fine.
   
(BTW & just out of interest, a url for the shortcut, entered in 'open file' 
dialog, is interpreted as a filename, and is prefixed by the current directory 
path - this is, of course, then flagged as an invalid file name. Netscape4.x & 
Opera don't like this much either, but IE manages to convert the url into the 
correct path for the object.)

6. File>open (web) location, enter url for shortcut in dialog - reproduces this 
bug. However, selecting object via 'choose file' in dialog works fine.

Plus:
7. Clicking on a link to the shortcut from within an HTML document reproduces 
this bug.

Comment 5

[timeless]

i'm not confirming this bug although i'm sure it's a bug, it's possible it's a 
dupe.

over to networking: file, when we receive a shortcut we need to resolve it 
completely.

Comment 6

[Keyser Sose]

Neither me nor fabian can find a duplicate of this so were going ahead and
marking NEW.

Comment 7

[Doug Turner (:dougt)]

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

Comment 8

[benc]

QA to me.

The Mac version of this bug was sent to parser.

Who should own this? I think we should display the location of the alias, but 
add href to show the original file.

-OR- 

We should say: this is an alias, do you want us to open the original?

This is probably a design problem that HTML doesn't address well.

Comment 9

[benc]

+testscase: file URL will test this for now, all plats

Comment 10

[benc]

-> file handling 

Comment 11

[Doug Turner (:dougt)]

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

Comment 12

[Biju]

Bug# 359867, is it due to same reason ?

Comment 13

[Ryan Jones-Ward [:sciguyryan]]

Marking this bug as blocking #359867 because they seem related. If anyone thinks otherwise please remove it! Thanks.

Comment 14

[Ryan Jones-Ward [:sciguyryan]]

Attachment: Patch for lnk file handling (v1)

Patch for lnk file handling (v1)

* This patch adds lnk file handling too |nsFileProtocolHandler::NewChannel|. This does not yet address the redirect issue.

It was suggested that this be in two patches. This deals with the processing and the other will deal with the redirection issue.

Comment 15

[Ryan Jones-Ward [:sciguyryan]]

Attachment: Patch v1.1

Same as the patch above but this one tests for |defined(XP_WIN)| as is the standard for the file.

Comment 16

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

Comment on attachment 253329 [details] [diff] [review]
Patch v1.1

you should ifdef the entire isSymlink block, not just the SetFollowLinks (which only has an effect on windows anyway). I don't think following symlinks on unix is correct.

also:-                    return rv;
+                  return rv;

the indentation here was correct...

Comment 17

[Ryan Jones-Ward [:sciguyryan]]

Attachment: Patch v1.2

patch v1.2

* Addresses Biesi's comments.

Comment 18

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

Comment on attachment 253745 [details] [diff] [review]
Patch v1.2

OK, per nsIFileURL, you must not modify the result of nsIFileURL::GetFile. so, please don't :) (Clone() the file if it is a symlink. unless GetTarget works even without setting followLinks?)

Comment 19

[Ryan Jones-Ward [:sciguyryan]]

Attachment: Patch v1.3

Patch v1.3

* Seems to work perfectly well without the |SetFollowLinks| call :)

Comment 20

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

Comment on attachment 253858 [details] [diff] [review]
Patch v1.3

would be great if you could create a unit test before checking this in

Comment 21

[Ryan Jones-Ward [:sciguyryan]]

(In reply to comment #20)
> (From update of attachment 253858 [details] [diff] [review])
> would be great if you could create a unit test before checking this in
> 

I'll work out a way of doing this as we discussed on IRC. If we can create a method to modify the properties of a lnk file where would be the best place to add the method(s)?

Comment 22

[Stanimir Stamenkov]

WFM:

Firefox 46.0.1, Build ID: 20160502172042
	Mozilla/5.0 (Windows NT 10.0; WOW64; rv:46.0) Gecko/20100101 Firefox/46.0

Firefox DevEd 48.0a2, Build ID: 20160521004015
	Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:48.0) Gecko/20100101 Firefox/48.0

SeaMonkey 2.43, Build ID: 20160517165439
	Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:46.0) Gecko/20100101 SeaMonkey/2.43