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.
*** This bug has been marked as a duplicate of 41985 ***
Status: UNCONFIRMED → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → DUPLICATE
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.
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 → ---
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.
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
Neither me nor fabian can find a duplicate of this so were going ahead and marking NEW.
Status: UNCONFIRMED → NEW
Ever confirmed: true
*** Bug 93121 has been marked as a duplicate of this bug. ***
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
+testscase: file URL will test this for now, all plats
-> 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. ***
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.
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.
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.
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...
Created attachment 253745 [details] [diff] [review] Patch v1.2 patch v1.2 * Addresses Biesi's comments.
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?)
Created attachment 253858 [details] [diff] [review] Patch v1.3 Patch v1.3 * Seems to work perfectly well without the |SetFollowLinks| call :)
Comment on attachment 253858 [details] [diff] [review] Patch v1.3 would be great if you could create a unit test before checking this in
(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)?
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
Component: File Handling → File Handling
Product: Core → Firefox
Target Milestone: Future → ---
Version: Trunk → unspecified
You need to log in before you can comment on or make changes to this bug.