274195 - MacOSX "document" won't display properly after drag and drop onto Dock

Status: RESOLVED DUPLICATE of bug 266008

(Core :: Networking: File, defect)

Description

[william.allen.simpson]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8a6) Gecko/20041208 Firefox/1.0+
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8a6) Gecko/20041208 Firefox/1.0+

This is a follow-on to Bug 266008, as requested.

For Netscape 4.x files (they appear as kind "Netscape document", presumably 
MOSS/TEXT), drag-and-drop onto the Dock has about the same effect as dropping 
onto an open window.  A dialog box asks:

 You have chosen to open
 2004 1014b Outages
 which is a: application/text
 from /Users/wastrel/networks

 What should Firefox do with this file?

I don't want to open them with some other application, that's why
they are dropped on THIS application!

Safari, on the other hand, opens them and displays them correctly. 
So, it can be done!

Very common files saved recently by firefox itself (they appear as kind
"document") won't drag-and-drop onto the Dock.  These _do_ work when dropped 
onto an open window:
 "disappearing dollar"
 "U.S. refuses to release Iranian brothers"

Worse, "whois mi-democrats.com" saved recently by firefox itself (as kind 
"document") won't drag-and-drop onto the Dock, and when dragged to an open 
window asks:

 You have chosen to open
 whois mi-democrats.com
 which is a: MS-DOS Executable
 from /Users/wastrel/networks

 What should Firefox do with this file?

After using the Finder to change the type to "Firefox document", the above
documents will still fail to drag-and-drop onto the Dock, but will launch
firefox when double-clicked, and even "whois mi-democrats.com" will render.  

Now that's really bizarre!  

I conclude that the problem is not in the rendering software, but in the 
OS-specific interface.

Reproducible: Always
Steps to Reproduce:
1.install firefox in Dock
2.drag older netscape 4.x documents to Dock
3.drag newly saved Firefox documents to Dock


Actual Results:  
See details.

Expected Results:  
Folks, you need to accept all kinds of files, and determine the action from the 
file content. Firefox is using the wrong kind of tests. Any "text" or "document" 
file full of HTML should display as HTML. Stop depending on suffixes! Common 
network suffixes like .com are not silly executables, especially on a Mac! 

In short, you need to be at least as intelligent as Safari and BBEdit.

Comment 1

[Asaf Romano (gone)]

You mean MacOS, not OS X (OS X files do have extensions).

confirmed.

Comment 2

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

The reason I recommended a new bug for this is because this non-display of
extensionless, local HTML or text, etc., files issue affects Camino as
well--presumably all Moz apps, unless I misunderstand where the break between
"core" vs. "app-specific" functionality is--so it should be a new "Core" bug
(rather than transmuting the old bug's description yet again).

So reassigning this to "Core"; if I've misunderstood where the functionality
that determines Moz should display, rather than attempt to save, a local
extenstionless HTML or text doc is located, please reassign back to Firefox and
I'll file a separate bug for Camino.  And please fix the subcomponent if it is
indeed a Core bug and I've mis-selected the subcomponent.

Comment 3

[HARUNAGA Hirotoshi]

I think this is a dup of Bug 154057.

Comment 4

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

I tend to agree that it's a dupe of bug 154057, but I realized I missed
something along the way (specifically 1a) and want to think about things a bit
more :-)

1a. "New" documents saved by Firefox, Camino, etc., (either saved by
user-defined filename or by editing the default filename after save to have no
extension) do load and render when dragged onto document windows.  They won't
load via drag-drop on the app/dock icon, because they have no extension and no
type code (these are the two methods an OS X app uses to determine if it can
read a file).

1b. Add an appropriate extension to a file in 1a and all works properly.

1c. Add a type code TEXT (the type code for HTML and text files) to a file in 1a
and Camino "downloads" the file, Firefox throws up the download
dialogue--whether the file is dragged to a window or the app/dock icon.

2.  "Legacy" html file (save by, e.g. Netscape 4) have no extensions and type
code TEXT.  They behave exactly as 1c.


I. To solve the drag-drop via dock/app icon of extensionless, type code-less
files, Firefox, Mozilla, Camino, etc., need to set a type code for all files
they save (in fact the AHIG recommends setting *all* relevant
"metadata"--extension, type, and also creator if relevant.  Moz apps currently
only set extension, but allow user to remove it before saving, and of course
can't control user action after saving).  This should fix "whois
mi-democrats.com", too, because type code overrides extension, IIRC.  This
requires separate bugs for at least Camino and Mozilla/Firefox, I think.  

II. To solve the issue of legacy documents (those with type code but no
extension)--and with new documents once I. is implemented, the Core code needs
to display/render files of type TEXT (just like NS 4.x used to) rather than
attempt to download them.  This requires one bug--this one/bug 154057--to fix
for all Moz browsers, I think.

(I haven't checked for Open... dialogue box issues, but presumably once both I.
and II. are fixed, all file opening issues for valid kinds of documents will be
fixed for all valid methods of opening files.)

Does all of this make sense?  Have I missed anything or am I wrong anywhere?

Comment 5

[william.allen.simpson]

It's getting annoying that folks merely change the summary line and declare 
it a duplicate....

No, this is about MacOSX kind "document".  I've added quotes in the summary.

I've added a specific Bug 274601, since folks cannot seem to distinguish 
"document" from "Firefox document" without clarity.  I'm sorry that I didn't 
do that in the first place....

I will also restore the summary line in Bug 266008, which referenced MacOSX 
"Netscape document"s.  Now maybe folks will focus on completing the fixes.

No, this is not only about "old MacOS".  As noted in the original, and in 
several of my other reports, firefox saves its files as kind "document", 
when they don't have an extension.  Now!  Today!

There's already a Bug 234942 about firefox failing to save the proper kind.  
But, we'll need to handle "document" forever.  I have Netscape 4.x, 7.x, and 
now Firefox "documents".  Thousands!

None of them have extensions.  Nobody in their right mind relies on 
extensions.  No security programmer EVER relies on extensions.  Such 
nonsense results in worms named "Work.doc                       .scr".  

And had you ever bothered to google this email address (or the 160K+ google 
references in my name), you'd find I was a founder and original author of 
many IETF security protocols, papers, and standards.  And that every copy of 
BSD-based systems has had an acknowledgement for "William Allen Simpson" for 
somewhere between 15 and 20 years.  Really, I'm not wet behind the ears....

No, bug 154057 is about handling of MacOS "ttxt" and useless dialog boxes 
there.  Related, and I'm sure similar fixes will be needed. 

Heck, there are bug reports running back to 2000 about the failure on MacOS 
to render HTML files as HTML.  And they never seem to get fixed.  Windows 
adherents mark them "worksforme".

Comment 6

[Boris Zbarsky [:bzbarsky]]

We don't do our own parsing of type codes, nor should we. We ask the operating
system "what sort of file is this?", and in your case it apparently reports a
bogus type... This should be fixable by fixing your operating system settings
appropriately.

And yes, this is a dup; probably of an invalid bug, given that this is just an
OS misconfiguration.

Comment 7

[Darin Fisher]

-> default owner

Comment 8

[Frankie]

There are three bugs here with basically the same premise: bug 266008, bug 274195, and bug 274601. At minimum, two of them should be closed.

The original concern is that saved web pages from Netscape 4 ignore the Mac metadata (TEXT/MOSS) and open based on file suffix instead. At this point, I hope legacy issues regarding Netscape 4 (as well as type/creator codes) can be RESOLVED as either INVALID or WONTFIX.

However, there is a related issue which may be valid. If I use FF's "Save Page As" command, the resulting files will not drag and drop properly onto the FF dock icon. For example:
1: save this bug (either "whole page" or "html only") under its default file name
2: drag the resulting "show_bug.cgi" file onto FF
3: It treats the file as unknown and refuses to open it (unless you hold the Command key to "force open").

show_bug.cgi displays if you drag it into an open FF window, or use right click -> Open With... -> Other -> browse to Firefox.

Note that Firefox not appearing in the "Open With..." list of applications is the same issue as the file not dropping onto the dock. The "Save Page As" command should create files that are marked as openable in FF, but it doesn't.

Surprisingly, a few quick searches do not reveal open instances of this issue. Perhaps the entire topic has already been marked WONTFIX?

Comment 9

[Patrick McManus [:mcmanus]]

comment 6