Closed
Bug 279070
Opened 20 years ago
Closed 19 years ago
File - save page as overwrites lnk targets
Categories
(Firefox :: Shell Integration, defect)
Tracking
()
VERIFIED
DUPLICATE
of bug 283730
People
(Reporter: jim, Assigned: bugs)
Details
Attachments
(1 obsolete file)
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0 I have users who have accidentally done a File - Save page as and overwritten a desktop shortcut (.lnk) file. Instead of overwriting the lnk file, the actual .exe file that the lnk file points to is overwritten. This leaves a desktop shortcut that tries to run an html file as an executable. Messy! Reproducible: Always Steps to Reproduce: 1. Select File - Save Page as 2. Browse to a desktop icon 3. Overwrite the file Actual Results: The desktop shortcut target .exe file is overwritten, instead of the shortcut lnk file. Expected Results: Should have overwritten the shortcut lnk file.
Comment 1•19 years ago
|
||
It does not matter whether you save a download or a page - it's the "save as" dialog. I could see from the 1.01 relase notes that they changed some .lnk issue with the save (MFSA 2005-21). An addition to Jim's steps to reproduce: The desktop icon in step 2 must be a shortcut to a folder, you can't reproduce this problem with a real folder.
Comment 2•19 years ago
|
||
I can confirm this, using FireFox 1.01 (not seen in 1.00) I have shortcut on the desktop named "Downloads" which is a shortcut to: "D:\Downloads". When downloading a file and double-clicking the shortcut in the save-as dialog, an popup appears asking if i wish to overwrite the shortcut. "Default" Save-as dialog behavior is to follow the shortcut, the same as when you doubleclick on a folder in the File Save-As dialog. This is a huge useability issue IMHO.
I confirm both that this bug solidly exists in 1.01 and not 1.00, and that it is VERY IMPORTANT to fix. Trying to navigate while saving webpages has suddenly become very hard with this bug. Shortcuts are shortcuts (.lnk) and should be followed, thanks...! Regards from Basel
I have not overwritten a link target yet, but I can confirm that I get the warning about overwriting a file as opposed to following a link. This is new in 1.0.1. 1.0 followed links correctly. And it happens with save page as, save link target as, save image as and save frame as.
Comment 5•19 years ago
|
||
The corresponding source file is: mozilla\widget\src\windows\nsFilePicker.cpp
Comment 6•19 years ago
|
||
The problem does seem to lie in the file mozilla\widget\src\windows\nsFilePicker.cpp. The code makes use of the standard Windows save as dialog box. However, in the Firefox 1.0.1-source, the flag OFN_NODEREFERENCELINKS seems to be incorrectly used. See the attached patch for a possible solution to the problem (removes the mentioned flag).
Comment 7•19 years ago
|
||
Does not exist in 1.0. Consistently reproducable in 1.0.1 and 1.0.2. This makes doing *any* kind of save close to impossible if there is a shortcut involved. This needs to be fixed!!!
Comment 8•19 years ago
|
||
I can second the remark of the previous poster, this isn't fixed in firefox 1.0.2 I think it's an easy fix and a must it has the potential of destroying the customer trust and it is definatly destroying a little bit of (trivial) data.
Yes, it is still not fixed, and you are right about the trust precisely. If someone is navigating by a link, it is not 'trivial' - and Firefox is the only application I know which won't follow links, much less destroys them. Hasn't the fix been suggested already? Thanks you guys, for making this right! (In reply to comment #8) > I can second the remark of the previous poster, this isn't fixed in firefox > 1.0.2 I think it's an easy fix and a must it has the potential of destroying the > customer trust and it is definatly destroying a little bit of (trivial) data. > >
Comment 10•19 years ago
|
||
..so? any ideas how to correct it? the patch doesn't work - or may be i dunno how to make it work; i simply click on it, do i have to do anything else(probably)? I can't understand why they still don't fix it in 1.0.2? FF offers very nice tool options for Web Developers however, a developer spends considerable time for image collectioning, but it's a PITA now with this .lnk overwriting...
Comment 11•19 years ago
|
||
The suggested patch fixes the source code, only, no binaries. Someone of the project officials (with sufficient privileges) still needs to merge it into the firefox source tree...
Comment 12•19 years ago
|
||
Comment on attachment 176739 [details] [diff] [review] Fixes the problem with overwritten .lnk files in the File Save As-dialog in Firefox 1.0.1 sr- This patch simply backs out the fix for bug 271732 (http://www.mozilla.org/security/announce/mfsa2005-21.html). That's not going to be acceptable, we need to fix both.
Attachment #176739 -
Attachment is obsolete: true
Attachment #176739 -
Flags: superreview-
Comment 13•19 years ago
|
||
If I understand correctly, this bug is about Firefox overwriting the destination file of a file shortcut, instead of overwriting the shortcut itself? That would be the opposite of bug 283730, no? For these two bugs to coexist, there needs to be a way to differentiate between file shortcuts and folder shortcuts, I assume.
Comment 14•19 years ago
|
||
Duping to the newer bug because it's in the right component/product with the right people CC'd, with the right set of blocking nominations. *** This bug has been marked as a duplicate of 283730 *** *** This bug has been marked as a duplicate of 283730 ***
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → DUPLICATE
Comment 15•19 years ago
|
||
This bug appears to have started as a duplicate of the 1.0 bug 271732, and morphed into the 1.0.1 regression bug 283730. Another good reason to close this one just to avoid the confusion.
Comment 16•19 years ago
|
||
(In reply to comment #13) > If I understand correctly, this bug is about Firefox overwriting the destination > file of a file shortcut, instead of overwriting the shortcut itself? That would > be the opposite of bug 283730, no? For these two bugs to coexist, there needs to > be a way to differentiate between file shortcuts and folder shortcuts, I assume. Gavin, let me make it much more clear - should help us all. Normally, shortcut links can be used to put a navigation in a folder - say to another folder. For example, I have links to knowledge base folders, from the My Documents where many programmes default. Normally double-clicking a shortcut link with the file save dialog goes to where the link points: the folder I wanted. With this bug, Firefox instead asks to over-write the shortcut link itself - with whatever one is trying to save. In other words, Firefox is treating the Windows shortcut link as a file - not a shortcut, and not a pseudo-directory if you like that view (when then link is pointed to a folder). Thanks to those who can for fixing it - and regards.
Comment 17•19 years ago
|
||
(In reply to comment #16) > Gavin, let me make it much more clear - should help us all. You're confusing this bug with bug 283730. As originally filed, this bug was about something else entirely. Take a look at comment 0. If we wanted to be real precise about things, it really should have been duped to bug 271732. Every single comment after comment 0 refers to bug 283730, so that's why this was duped there instead.
Status: RESOLVED → VERIFIED
Comment 18•19 years ago
|
||
Gavin, I looked at your references, thanks. Ref 0 is just another way of looking at this same bug, I think. FF 1.02 is trying to over-write links. This is hardly acceptable in a browser that intends to supplant IE. Separately, I can't quite understand how this is felt to be a part trying to fix a security hole that _depends_ on writing over links. What I hope is that people will do what we used to do 20 years ago when hooks and tuning masks for standard dialogs were invented, and use the right ones to recover the ability to use links in the normal way. This in fact will be a good step towards not over-writing links and allowing security holes, do you agree? Regards from Basel, Narration
You need to log in
before you can comment on or make changes to this bug.
Description
•