Closed Bug 279070 Opened 20 years ago Closed 19 years ago

File - save page as overwrites lnk targets

Categories

(Firefox :: Shell Integration, defect)

x86
Windows XP
defect
Not set
normal

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.
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.
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.
The corresponding source file is: mozilla\widget\src\windows\nsFilePicker.cpp
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).
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!!!
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.
> 
> 
..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...
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 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-
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.
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
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.
(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.
(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
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.

Attachment

General

Created:
Updated:
Size: