Closed Bug 266008 Opened 20 years ago Closed 6 months ago

MacOSX "Netscape document" won't display properly after drag and drop

Categories

(Firefox :: Shell Integration, defect, P3)

Product:
Firefox
Component:
Shell Integration
Platform:
PowerPC
macOS
Type:
defect

Tracking

()

Status:
RESOLVED WONTFIX

People

(Reporter: william.allen.simpson, Unassigned)

References

Details

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; rv:1.7.3) Gecko/20041001 Firefox/0.10.1
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; rv:1.7.3) Gecko/20041001 Firefox/0.10.1

Just started testing firefoxPR on MacOS 10.3.5. This is a major problem 
in MacOS user expectations, and will impede acceptance and migration.

Netscape 4.x Documents won't drag and drop onto Firefox in the Dock. 

Netscape 4.x Documents will drag and drop onto Safari and launch it. 

Safari Documents will drag and drop onto both Netscape and Firefox 
in the Dock, and successfully launch either of them.


Reproducible: Always
Steps to Reproduce:
1.
2.
3.

Actual Results:  
see details above.

Expected Results:  
Firefox needs to accept the correct handlers for its predecessor(s).   
If I remember correctly, that's MOSS creator and TEXT type.  

Hopefully, Firefox should accept any TEXT type, and even ???? (unknown), 
which is what it currently creates (due to Bug 234942).
WFM using 20041026 Firefox/1.0RC1 on Mac OS 10.3.5.
Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.3) Gecko/20041026
Firefox/1.0RC1

Don't know what he's smoking.  Still doesn't work.

I have Firefox, Netscape 7.2, and Safari all loaded up in the Dock. 

I have thousands of 4.x files that do not end in .html, such as "Republic of
God", of kind "Netscape document".  MacOS X shows the Netscape page icon. 
MacOSclassic snitch shows type "TEXT" and creator "MOSS". 

Dragging and dropping any of these files onto the Safari icon will launch
Safari, which successfully displays the html page.

Dragging and dropping any of these files onto the Netscape 7.2 icon will launch
Netscape, which asks for the program to display the text (less than ideal).

But nothing happens with FirefoxFC1.  Absolutely NOTHING!

This should be blocking-aviary1.0mac. 
Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.5) Gecko/20041107
Firefox/1.0

same problem continues in release....

I have downloaded camino 2004082512 (v0.8.1), which works correctly.  This shows
that the problem is a coding error in firefox!  Two other branches work. 

Could somebody give me some idea where this code might be in the trees?
If the HTML document doesn't have an extension (i.e. legacy doc or
user-(re)named), Firefox won't open it via drag-drop to the Dock icon (and tries
to download with MIME type "application/text" when dragged into the browser window).

This is because Firefox 1.0 is missing entries in its Info.plist for documents
with file type TEXT.  It's also missing a whole host of entries for both file
types and extensions, at least in comparison to the Info.plist in Camino.

In addition to what Firefox defines, Camino is defining CFBundleOSTypes (as
Viewer) for TEXT, utxt, GIFf, JPEG, PNGf, ilht and CFBundleTypeExtensions (as
Viewer) for txt, text, jpeg, jpg, png, gif, webloc, url.

I can't find any similar bug, so confirming and changing summary from "netscape
documents won't drag and drop onto firefox on MacOS X" to "can't drag and drop
files - Missing CFBundleOSTypes and CFBundleTypeExtensions in Info.plist"  This
should be a really simple fix, no "coding" involved (I could do it myself if I
knew how to create a patch), so requesting blocking-aviary1.0mac (if that flag
is still relevant for prioritizing post-1.0 Mac fixes?).
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: blocking-aviary1.0mac?
Summary: netscape documents won't drag and drop onto firefox on MacOS X → can't drag and drop files - Missing CFBundleOSTypes and CFBundleTypeExtensions in Info.plist
not useful for Firefox bugs, sorry.

Mano, care to whip up a patch for this baby now that someone's run down the
problem?  Feedback from Javier/sfraser might be good as to what we should do in
this case, and whether there's a reason we don't accept some of these types.

Sticking on the 1.1 radar provisionally, since that's the Aquafication release
and we really need to fix these bugs for Macolytes.
Flags: blocking-aviary1.0mac?
Target Milestone: --- → Firefox1.1
Already working on this.
Assignee: bugs → bugs.mano
Depends on: 233712
Sorry, don't know how I missed that other bug when I searched for duplicates. :(
 Another bug I'm triaging right now points out that .shtm/.shtml are also
missing from Firefox's Info.plist (and Camino's as well.)
shtm/shtml are server-side filetypes and shouldn't/don't work in Mozilla :)
But saved versions of such pages are viewable "HTML" and should be openable via
drag-drop on the app icon.  Camino actually has .shtml defined (just not .shtm;
I mis-spoke earlier), and if I've used LXR correctly, so does SeaMonkey....

If you drag a saved .shtm file into a Firefox window, it currently displays the
saved page, rendered, so I see no reason not to enable drag-drop via the icon,
which is the more common/natural way of drag-drop opening.

And I'd think more users will be trying to open .shtm/.shtml pages they've saved
from the web than will have, and will try to open, "raw" .shtm files their home
servers haven't processed :)
should be fixed by bug 233712, please verify with tommorow's trunk build, thanks.
[mailed response hasn't shown up yet]

Nope, not fixed in
 Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8a6)
 Gecko/20041208 Firefox/1.0+

But the behaviour has changed for some files.

Now, drag-and-drop onto the Dock for netscape 4.x files (they appear
as kind "Netscape document", presumably MOSS/TEXT) has about the same
effect as dropping onto an open window, so we're moving in the right
direction, but still no joy.  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!

And it still doesn't work via drag-and-drop with very common files
saved recently by firefox itself (they appear as kind "document").
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, 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?

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 reply to comment #11)

> Now, drag-and-drop onto the Dock for netscape 4.x files (they appear
> as kind "Netscape document", presumably MOSS/TEXT) has about the same
> effect as dropping onto an open window, so we're moving in the right
> direction

IMO, the fact that we can now drag files with type "TEXT" (and without an
extension) on the dock icon means this bug is fixed.  The new .plist looks a
little funky (some strange .icns references in the image category and in the
URLTypes category), but the part involving enabling dropping extensionless
documents with type "TEXT" is correct.

The rest of the issue really is a separate bug--Moz apps refusing to even render
the file as raw html, which is what they do when coming into contact with such a
file on the 'net, see http://www.mindspring.com/~sardisson/moz/Mahfouz

I don't know why local text files without extensions are being given a MIME type
of "application/text".

Camino 0.8.2 and 20041210 NB both "download" the local extensionless, Netscape
4.x-saved HTML file, just without the dialogue box presented by Firefox.

Unless the Suite does something different, the
lack-of-display/attempting-to-save and related issues are really a Core (Gecko)
bug about handling local extensionless files on the Mac.  wsimpson, search
Bugzilla for a bug about this in the "Core" product or file a new one if you
can't find an existing one (sorry, don't have time now to search myself); feel
free to cc me on the existing/new bug since I'd like to see it fixed as well.

In summation, I think we can call *this* bug, as described in comment 0, Fixed
based on Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8a6)
Gecko/20041208 Firefox/1.0+.  The rest of the file-handling issues are really a
Core/Gecko problem and need a separate bug.
Oops, forgot the details on the screwy strings in the image files section (the
URLTypes matches Camino's, so I guess it's OK):

		<dict>
			<key>CFBundleTypeExtensions</key>
			<array>
				<string>jpeg</string>
				<string>jpg</string>
				<string>png</string>
				<string>gif</string>
			</array>
			<key>CFBundleTypeIconFile</key>
			<string>fileBookmark.icns</string>
			<key>CFBundleTypeName</key>
			<string>document.icns</string>
			<key>CFBundleTypeOSTypes</key>


The last four lines instead should be:

			<key>CFBundleTypeIconFile</key>
			<string>document.icns</string>
			<key>CFBundleTypeName</key>
			<string>Image Document</string>
			<key>CFBundleTypeOSTypes</key>

(Looks like a copy-paste ended up in the wrong place <g>)
(In reply to comment #12)

Err, my bad. I will attach a typo-fix later today.
<i>I think we can call *this* bug, as described in comment 0, Fixed</i>

I disagree.  While my original described drag-and-drop of Netscape 4.x onto the 
Dock (and quite specifically Netscape 4.x), the whole point is that they 
actually RENDER!  Now, we have the drag-and-drop, we don't have the display.  

It was somebody else that changed the summary description from "netscape
documents won't drag and drop onto firefox on MacOS X" to "Missing CFBundle...."

Note, the referenced Bug 233712 actually wants each missing type described in 
a separate bug, so leaving my original summary would have been compatible. 

Admittedly, identifying the CFBundle as part of the problem was a good step
forward, as I had no idea how to fix it, and haven't contributed code since 1999
in any case.

However, based on your request, I've added Bug 274195, which is more explicitly
generalized to the MacOSX "document" type and describes the display problem. 

In summary: progress, but no joy.
Blocks: 274195
OK, this is now a dupe of bug 233712. I have confirmed bug 274195.

I will attach a typo-fix-patch on bug 233712.

*** This bug has been marked as a duplicate of 233712 ***
Status: NEW → RESOLVED
Closed: 20 years ago
No longer depends on: 233712
Resolution: --- → DUPLICATE
It's getting annoying that folks merely change the summary line and declare 
it a duplicate....

No, Bug 233712 only fixed the first part of the problem.  While changing the 
.plist somewhere has improved this bug, and firefox will launch, these files 
still do not display.  As described in previous comments, a dialog box appears.

No, this is about MacOSX kind "Netcape document" as stated in the original 
summary.  I've restored the summary with quotes, to be clearer.  

We now have a series of related bug reports -- adding Bug 274195 MacOSX 
"document" and Bug 274601 MacOSX "Firefox document".  I'm sorry that I didn't 
do that in the first place.... 

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....

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".

And people wonder why I still run 4.x under classic to get my work done.  
(heavy sigh)
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
Summary: can't drag and drop files - Missing CFBundleOSTypes and CFBundleTypeExtensions in Info.plist → MacOSX "Netscape document" won't display properly after drag and drop
Assignee: bugs.mano → bugs
Status: REOPENED → NEW
Target Milestone: Firefox1.1 → ---
Assignee: bugs → nobody
QA Whiteboard: qa-not-actionable

In the process of migrating remaining bugs to the new severity system, the severity for this bug cannot be automatically determined. Please retriage this bug using the new severity system.

Severity: major → --
Severity: -- → S3
Priority: -- → P3
Status: NEW → RESOLVED
Closed: 20 years ago → 6 months ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.