Open Bug 96831 Opened 23 years ago Updated 2 years ago

[RFE Mac Only] - Moz should give the option to handle creator/type by its own when saving HTML files

Categories

(Firefox :: File Handling, enhancement)

PowerPC
All
enhancement

Tracking

()

People

(Reporter: benjamin, Unassigned)

Details

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Macintosh; U; PPC; en-US; rv:0.9.3+) Gecko/20010824
BuildID:    2001082404

Everytime I save HTML file  from Moz the document type is set to  MSIE /TEXT...
Would be nice to have Moz document typing MOZZ/TEXT.

Reproducible: Always
Reporter, Mozilla obeys the file mapping preferences you have set for .html files in your 
systemwide Internet Preferences (control panel). If you change it there to what you 
desire, that's how Mozilla will save them.

Marking INVALID.
Status: UNCONFIRMED → RESOLVED
Closed: 23 years ago
Resolution: --- → INVALID
In this case Moz should give the option to bypass "File Exchange" as in NS4.7 and 
handles creator/type by its own when saving html/text files... When I save 
document from NS / IE / Moz 95% of the time if I double click on it I want to 
reopen it in the creator...

-> enhancement
-> Summary
-> Cc greg@tcp.com

Greg: If it makes sense please reopen it. Thank!
Severity: normal → enhancement
Summary: Moz should set the right document creator/type when using "Save as...". → [RFE Mac Only] - Moz should give the option to handle creator/type by its own when saving HTML files
I agree, Benjamin. Mozilla should use the systemwide Internet Preferences for
file mappings, but must give some facility for locally overriding those settings
in its' own preferences. Reopening.

That being said, it's not entirely clear to me what the logic is for this in
Mozilla at present. For instance, my Internet Preferences have .hqx files set up
to be *owned* by BinHex 5.0 (TEXT/BnHq), but post-processed by StuffIt Expander.
Deciding to experiment, I changed *Mozilla's* settings so that .hqx files are
*handled* by BinHex (Mozilla offers no file *ownership* settings). Lo and
behold, even after making this change, Mozilla still insists on post-processing
.hqx files with BinHex; returning to Mozilla's file-handling preferences for
.hqx ensures the setting for BinHex post-processing remains in place, though
apparently un-honored.

It must be decided by the Mozilla architects how to handle systemwide Internet
Preferences file mappings versus its' own file mappings. It's not acceptable to
allow users to change the Mozilla settings if they're simply going to be
subsequently ignored. This isn't about Mac users being picky, as I've seen
discussed in the newsgroups; rather it's about proper UI design, which is
apparently a lost art in today's Windows/Unix world of mediocrity.
Status: RESOLVED → UNCONFIRMED
Resolution: INVALID → ---
I should note that I have previously asked for some explanation of the logic behind 
Mozilla's file-typing mechanism on Mac on the newsgroups, but met only silence in 
response.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Wish us some feedback Greg.

But I think it's important to make distinction between file "from the web" to HD 
(.hxd/.sit/.pdf/.mov) and file from "Mozilla" via the "save as & co" function to 
HD. As I said when I save HTML files from Moz generally I want to reopen in 
Mozilla which isn't the case when I save Quicktime movies who obviously I prefer 
to open in QuickTime player. Actually it's like: when I save emails from Moz they 
reopen in Outlook when I doubleclick on it! duh!
->file handling
Assignee: asa → law
Component: Browser-General → File Handling
QA Contact: doronr → sairuh
Setting target milestone.  We need to fix some higher priority things in this 
area first.
Target Milestone: --- → mozilla1.0.1
QA Contact: sairuh → petersen
retargeting
Target Milestone: mozilla1.0.1 → Future
.
Assignee: law → file-handling
Doesn't moz generally set the creator to 'MOZZ'?  The problem is that IC knows
nothing about that creator...
Assignee: file-handling → nobody
QA Contact: chrispetersen → file-handling
Product: Core → Firefox
Target Milestone: Future → ---
Version: Trunk → unspecified
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.