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

NEW
Unassigned

Status

()

18 years ago
2 years ago

People

(Reporter: val, Unassigned)

Tracking

(Blocks: 1 bug, {helpwanted, testcase})

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 3 obsolete attachments)

(Reporter)

Description

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

18 years ago

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

Comment 2

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

18 years ago
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.
Status: RESOLVED → UNCONFIRMED
Resolution: DUPLICATE → ---
(Reporter)

Comment 4

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

18 years ago
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.
Assignee: asa → dougt
Component: Browser-General → Networking: File
QA Contact: doronr → tever
Summary: Shortcut on desktop to HTML document not being interpreted properly... → Path of Shortcut [.lnk] is used as basehref instead of the HTML document's directory

Comment 6

18 years ago
Neither me nor fabian can find a duplicate of this so were going ahead and
marking NEW.
Status: UNCONFIRMED → NEW
Ever confirmed: true

Updated

18 years ago
Keywords: helpwanted

Updated

18 years ago
Target Milestone: --- → Future
*** Bug 93121 has been marked as a duplicate of this bug. ***

Comment 8

18 years ago
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.
QA Contact: tever → benc

Comment 9

18 years ago
+testscase: file URL will test this for now, all plats
Keywords: testcase

Comment 10

18 years ago
-> file handling 
Assignee: dougt → law
Component: Networking: File → File Handling
QA Contact: benc → sairuh
*** Bug 93121 has been marked as a duplicate of this bug. ***
QA Contact: sairuh → petersen

Updated

16 years ago
Depends on: 194357

Comment 12

12 years ago
Bug# 359867, is it due to same reason ?
Marking this bug as blocking #359867 because they seem related. If anyone thinks otherwise please remove it! Thanks.
Blocks: 359867
Assignee: law → sciguyryan+bugzilla
Status: NEW → ASSIGNED
Created attachment 253320 [details] [diff] [review]
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.
Attachment #253320 - Flags: superreview?(cbiesinger)
Attachment #253320 - Flags: review?(cbiesinger)
Created attachment 253329 [details] [diff] [review]
Patch v1.1

Same as the patch above but this one tests for |defined(XP_WIN)| as is the standard for the file.
Attachment #253320 - Attachment is obsolete: true
Attachment #253329 - Flags: review?(cbiesinger)
Attachment #253320 - Flags: superreview?(cbiesinger)
Attachment #253320 - Flags: review?(cbiesinger)
Attachment #253329 - Flags: superreview?(cbiesinger)
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...
Attachment #253329 - Flags: superreview?(cbiesinger)
Attachment #253329 - Flags: superreview-
Attachment #253329 - Flags: review?(cbiesinger)
Attachment #253329 - Flags: review-
Created attachment 253745 [details] [diff] [review]
Patch v1.2

patch v1.2

* Addresses Biesi's comments.
Attachment #253329 - Attachment is obsolete: true
Attachment #253745 - Flags: superreview?(cbiesinger)
Attachment #253745 - Flags: review?(cbiesinger)
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?)
Attachment #253745 - Flags: superreview?(cbiesinger)
Attachment #253745 - Flags: superreview-
Attachment #253745 - Flags: review?(cbiesinger)
Attachment #253745 - Flags: review-
Created attachment 253858 [details] [diff] [review]
Patch v1.3

Patch v1.3

* Seems to work perfectly well without the |SetFollowLinks| call :)
Attachment #253745 - Attachment is obsolete: true
Attachment #253858 - Flags: superreview?(cbiesinger)
Attachment #253858 - Flags: review?(cbiesinger)
Comment on attachment 253858 [details] [diff] [review]
Patch v1.3

would be great if you could create a unit test before checking this in
Attachment #253858 - Flags: superreview?(cbiesinger)
Attachment #253858 - Flags: superreview+
Attachment #253858 - Flags: review?(cbiesinger)
Attachment #253858 - Flags: review+
(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)?
QA Contact: chrispetersen → file-handling
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

Updated

3 years ago
Component: File Handling → File Handling
Product: Core → Firefox
Target Milestone: Future → ---
Version: Trunk → unspecified
Assignee: sciguyryan → nobody
Status: ASSIGNED → NEW
You need to log in before you can comment on or make changes to this bug.