file: MacOS applications display data fork

VERIFIED WORKSFORME

Status

P3
normal
VERIFIED WORKSFORME
19 years ago
3 years ago

People

(Reporter: deej, Assigned: gagan)

Tracking

({arch, testcase})

Trunk
Future
PowerPC
All
arch, testcase

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

19 years ago
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Macintosh; N; PPC; en-US; m17) Gecko/20000807
BuildID:    2000080712

Open a URL of the form: file:///... etc (eg: file:///Macintosh%20HD/) displays a
list of the files on the file-system, however it does not see the resource fork
of any files, only the data fork. This is not so much a problem for data files
(eg: .gif, .html, .doc even), but for applications, etc which have resource
forks. Anything which is an application, which is almost all resource fork, is
reported as more-or-less empty by Mozilla. The expected result of clicking a
file which is an application would be that the application would launch, rather
than the browser attempting to load the data fork into the browser (invariably
binary junk).

Reproducible: Always
Steps to Reproduce:
1.Open URL of file:///Hard%20Disk%20Name/
2.Browse to an "application" file
3.Click to open it

Actual Results:  Depending on the file, either the browser loads an empty page,
or it displays binary junk.

Expected Results:  I would have expected the application to launch.

Clicking an executable on Windows by browsing the filesystem with file:/// URLs
launches that executable.

Comment 1

19 years ago
I don't know if while browsing the file system with the browser and selecting a
binary is supposed to result in executing it. A quick test of Moz M18 build
2000080808 for both MacOS and Win32 gave me the same result, binary junk to the
window or a prompt to save/download the file. This also appears to be the same
behavior for NS 4.x on MacOS and Win32. However if there is a helper app
associated with a particular file/creator-type or extension (ie. .pdf or .sit)
then that file is executed by that helper program. IE for both Windows and Mac
will execute binaries, but I don't believe NS or Moz ever has. I may be mistaken.

Comment 2

19 years ago
setting bug to new and sending to networking.
Assignee: asa → gagan
Status: UNCONFIRMED → NEW
Component: Browser-General → Networking
Ever confirmed: true
QA Contact: doronr → tever
(Assignee)

Updated

19 years ago
Target Milestone: --- → Future

Comment 3

18 years ago
mass move, v2.
qa to me.
QA Contact: tever → benc

Updated

18 years ago
Component: Networking → Networking: File
OS: All

Comment 4

17 years ago
When we open a file URL in MacOS, are we checking the file creator and type 
data?

Comment 5

17 years ago
+arch, corrected summary.
Someone needs to decide how this should work.

MacOS X, Mozilla 0.9.4 tries to download the file to itself.

Based on the comments made about file types, it sounds like we are not using 
the MacOS desktop to determin a files "TYPE".
Keywords: arch, testcase
Summary: Cannot see Mac resource fork on the filesystem → file: MacOS applications display data fork

Comment 6

17 years ago
RESOLVED:WFM

hmm. This happens in Windows 98, Mozilla 0.9.4 too.

Okay, no more data fork, the "should we launch this app?" issue goes to bug 
102760.
Status: NEW → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → WORKSFORME

Updated

17 years ago
Keywords: verifyme

Comment 7

17 years ago
VERIFIED:

->file handling.

From what I can tell, all file: URLs in Mac are being sent through some
creator/filetype mapper to find the opening app, something I don't understand well.

As long as it doesn't display the data fork of the app, this bug is finished.
Status: RESOLVED → VERIFIED
Component: Networking: File → File Handling
Keywords: verifyme
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.