44267 - Drag an alias to a deleted item ---> inappropriate dialog

Status: RESOLVED WONTFIX

(Core :: DOM: Copy & Paste and Drag & Drop, defect, P5)

Description

[Eli Goldberg]

* TITLE/SUMMARY
Seamonkey shows inappropriate dialog upon dragging an aliases to a deleted item

* STEPS TO REPRODUCE
0) Launch Seamonkey
1) Duplicate an unlocked item on your desktop (e.g. a dragged bookmark)
2) Drag the original to the trash, and empty the trash.
3) Drag the alias to your browser window.

* RESULT
 - What happened

The "Unknown File Type" dialog appears, giving the user the ability to save the 
alias, pick another application, etc.

 - What was expected 

Mozilla should return a suitable error dialog, similar to that given by IE or NS 
4.x.

* REGRESSION

 - Occurs On
        Mac OS Seamonkey (6.29.2000 optimized build)		

 - Doesn't Occur On
        Win32 Seamonkey (6.29.2000 optimized build [NT 4, Service Pack 5]) --- 
drag/drop nonfunctional




* CONFIGURATIONS TESTED

- [Mac] Power Mac G4 (450 Mhz), 256 MB RAM (VM off), 1024x768 (Thousands of 
Colors), Mac OS 9.0

- [Win32] Vectra VL (266 MHz P2), 96 MB RAM, 800x600 (True Color), NT 4.0 SP5.

- [Linux] Vectra VL (266 MHz P2), 96 MB RAM. Red Hat Linux 6.0 (GNOME).

Comment 1

[Eli Goldberg]

QA Assigning to self. Swagging Warren as bug recipient.

Comment 2

[Warren Harris]

I see another problem here too: If you make an alias/shortcut to something, and 
then try to open the shortcut, you get an unknown content type dialog too, even 
if the original still exists. (It's doubly weird since the "unknown" 
content type dialog says the file is text/html.) So...

1. We need to follow aliases when determining the content type. (Dougt should 
probably do this.)

2. We need to special case the file download code so that if the source type is 
already a local file, we don't ask to save it. This can be done by accessing the 
localFile attribute on nsIChannel. (Bill Law should do this)

Comment 3

[Doug Turner (:dougt)]

taking a look.

Comment 4

[Doug Turner (:dougt)]

Okay, on windows I have fix the problem where things were not being resolved 
properly.  I will getting a code review and check this in when I land other 
changes to nsILocalFile.

This fixes the problem when you have a shortcut in a directory listing.  It does 
not solve the case for Web Shortcuts (when you drag a webpage from the browser 
to the explorer).  nsIFile can give you the contents of this file, but someone 
is going to have to parse it - and it is not nsIFile.  

I will take a look at the mac problems when I get a build.

Comment 5

[Doug Turner (:dougt)]

fixed the windows shortcut code.

Comment 6

[Doug Turner (:dougt)]

moving out milestones.

Comment 7

[Doug Turner (:dougt)]

Assigning to bill law.  I believe my part is done.

Comment 8

[Bill Law]

So what remains is to not offer to save local files?

Comment 9

[Matthew T (active 1999-2002)]

No, it's a bit more complicated than that. We now appear to behave considerably 
worse than we did when Eli filed the bug. (Tested with build 2001041704, Mac OS 
9.1.)

Part 1:
*   Go to <http://mozilla.org/>.
*   Choose `File' > `Save', and save the Web page to your desktop.
*   Drag the icon from the Desktop into a Navigator window.
What should happen:
*   The saved file loads.
What actually happen:
*   You get a dialog saying that the file is of type application/text, which
    Mozilla doesn't know how to deal with, and asking you if you want to
    download the file to disk. (Ummm ... no thanks.)
*   An file with an obnoxious name such as `kahqojni.1st' appears on your
    Desktop. (When you click `Cancel' in the dialog, the file disappears.)
For this reason alone, I'm upping this bug to major severity -- it doesn't make 
any sense to the user that Mozilla can't open HTML files which it created 
itself.

Part 2:
*   Drag the proxy icon from a Navigator window to your desktop.
*   Note that a `mozilla.org' generic Internet shortcut is created (thankyou,
    Pinkerton:-).
*   Drag the Internet shortcut back into a Navigator window.
What should happen:
*   The URL stored in the Internet shortcut loads.
What actually happens:
*   Nothing.

Part 3a:
*   Select the Internet shortcut, and choose `Make Alias' from the `File' menu.
*   Drag the alias into a Navigator window.
What should happen:
*   The URL stored in the Internet shortcut which the alias refers to loads.
What actually happens:
*   Nothing. (This is probably a duplicate of part 2.)

Part 3b:
*   Select the HTML file which you saved earlier, and choose `Make Alias' from
    the `File' menu.
*   Drag the alias into a Navigator window.
What should happen:
*   The file which the alias refers to loads.
What actually happens:
*   As for Part 1 (though the cause may be different).

Part 4:
*   Drag the Internet shortcut to the Trash.
*   Drag the alias to the Internet shortcut into a Navigator window.
What should happen:
*   You get an error alert, generated by Mac OS, which reads: `The alias
    "mozilla.org" could not be opened, because the original item is in the
    Trash.' (For reference purposes, try the same thing in BBEdit.)
What actually happens:
*   Nothing.

Part 5:
*   Empty the Trash.
*   Drag the alias into a Navigator window.
What should happen:
*   You get an error alert, generated by Mac OS, which reads: `The alias
    "mozilla.org" could not be opened, because the original item could not be
    found.'
What actually happens:
*   Nothing.

If you want this to be split up into a chain of bugs, each depending on the one 
before, let me know. However, I'm going to be a Bugzilla heretic and suggest 
that it might be more productive if these problems were attacked sequentially 
in this bug (or a single fresh bug); that way we can easily see if a fix for 
one part fixes one or more of the later parts.

Comment 10

[Mike Pinkerton (not reading bugmail)]

please split these into separate bugs. the garbage filename is already another 
bug (search for 'garbage' in the summary).

Comment 11

[Matthew T (active 1999-2002)]

Ok, this bug now covers only Parts 4 and 5, since the fix for them will be 
identical or almost identical. This bug (and the other bugs I described) can't 
be dealt with, or even reproduced, until bug 76728 is fixed.

Comment 12

[Viswanath Ramachandran]

nav triage: sending to pchen for some TLC. 

Comment 13

[Paul Chen]

nav triage team:

Marking nsbeta1- and adding help wanted

Comment 14

[benc]

mass move, v2.
qa to me.

Comment 15

[benc]

If you know that multiple problems can be fixed in one place (because they are
different versions of the same problem, 1 bug. If not, break it up and note the
new bugs here...)

Comment 16

[Asa Dotzler [:asa]]

->default assignee

Comment 17

[neeti]

xpapps

Comment 18

[Peter Trudelle]

->jag

Comment 19

[jag (Peter Annema)]

-> future

Comment 20

[Simon Paquet [:sipaq]]

This bug is targeted at a Mac classic platform/OS, which is no longer supported
by mozilla.org. Please re-target it to another platform/OS if this bug applies
there as well or resolve this bug.

I will resolve this bug as WONTFIX in four weeks if no action has been taken.
To filter this and similar messages out, please filter for "mac_cla_reorg".

Comment 21

[Stefan [:stefanh]]

I think it's the alias problem (3-5) that's left here.

Comment 22

[Jens Stutte [:jstutte]]

Bulk-downgrade of unassigned, >=3 years untouched DOM/Storage bug's priority.

If you have reason to believe this is wrong, please write a comment and ni :jstutte.

Comment 23

[Hsin-Yi Tsai (she/her)[:hsinyi]]

(In reply to Simon Paquet [:sipaq] from comment #20)

This bug is targeted at a Mac classic platform/OS, which is no longer
supported
by mozilla.org. Please re-target it to another platform/OS if this bug
applies
there as well or resolve this bug.

I will resolve this bug as WONTFIX in four weeks if no action has been taken.
To filter this and similar messages out, please filter for "mac_cla_reorg".

Symptons have changed a bit. WONTFIX still sounds right in today's triage meeting.