Closed
Bug 46435
Opened 24 years ago
Closed 24 years ago
saved .hqx files are owned by mozilla
Categories
(SeaMonkey :: UI Design, defect, P3)
Tracking
(Not tracked)
RESOLVED
FIXED
mozilla0.8
People
(Reporter: warrensomebody, Assigned: paulkchen)
References
()
Details
(Keywords: arch, helpwanted, Whiteboard: nsbeta1+)
Attachments
(4 files)
2.89 KB,
patch
|
Details | Diff | Splinter Review | |
1001 bytes,
patch
|
Details | Diff | Splinter Review | |
2.89 KB,
patch
|
Details | Diff | Splinter Review | |
3.41 KB,
patch
|
Details | Diff | Splinter Review |
If you download a .hqx file, it's creator ends up being mozilla instead of stuffit.
This is indicitave of a MUCH larger bug - Mozilla can't handle Mac OS creator/file types at all. Any file you download will be saved with the creator "MOSS" and file type "????" - defeating the whole purpose of creator/file types.
This is file download related bug Mac-specific. Nominating and passing over to Paul.
Assignee: law → pchen
Keywords: nsbeta1
Keywords: arch,
helpwanted
Comment 3•24 years ago
|
||
Sounds like it would be fixed by an exception list in the nsLocalFileMac type/ creator setting. Cc conrad
Isn't this a dupe of 55891, which got checked into the trunk on 11-14 by ccarlen?
Comment 5•24 years ago
|
||
No, it's not a dup. This problem was just changed by the checkin for bug 55891. Before most files got saved with with creator 'MOSS' and type '????'. The fix to bug 55891 made the creator be that of the current process and the type be looked up from IC. Simon's right. This needs to be improved with some exception list. I think the type should always be looked up from IC as it is now and the creator should usually be looked up from IC except certain types. We just need to decide what those types are.
Comment 6•24 years ago
|
||
Almost anything that's in IC I think we don't want to give a MOSS creator type, with the exception of 'TEXT' files. So use IC creators for everything except 'TEXT', and file types that are in our BNDL resource.
Comment 7•24 years ago
|
||
Basing it on what's in the BNDL sounds good. pchen, you can give this to me if you want.
Comment 8•24 years ago
|
||
Ultimately Moz should respect Internet Config for creators and types. I guess there might be specific exceptions like creator: MOZZ type: TEXT but then: * that has nothing to do with this bug - Moz should just use the IC setting for hq files * even if we were thinking about that case - shouldn't we respect the user's desires in all cases? e.g. what should type: "HTML" be - should it not be creator == whatever Internet Config says it is? If the user's preferred browser isn't mozilla, why should moz own TEXT or HTML files? That's what moz's "should I be preferred broswer" prefs are for... I think only TEXT is a special case.
Updated•24 years ago
|
Component: Browser-General → XP Apps
nav triage team: Marking nsbeta1+, mozilla0.8
Whiteboard: nsbeta1+
Target Milestone: --- → mozilla0.8
Comment 10•24 years ago
|
||
We're past time to cut these low priority bugs from mozilla0.8. Please update these bugs today.
Assignee | ||
Comment 11•24 years ago
|
||
Assignee | ||
Comment 12•24 years ago
|
||
Assignee | ||
Comment 13•24 years ago
|
||
So the fix involves a) setting mac file creator along with file type in what used to be SetOSTypeFromExtension(), which has now been renamed to SetOSTypeAndCreatorFromExtension(), b) creating a new method ExtensionIsOnExceptionList() which returns PR_TRUE when a file extension is on the exception list, and c) calling ExtensionIsOnExceptionList() from within SetOSTypeAndCreatorFromExtension()
Comment 14•24 years ago
|
||
Comments: the exception list is based on file extension (which may not be present). Why not base it on the file type which you've just found out, rather than the extension? Basing it on file type has the advandate that (at some later stage) we could grovel in the BNDL resource for 'owned file types'. And it's cheaper to compare 4-char codes than strings. Not your code bug... extPtr = const_cast<char *>(extension); // really, we won't touch it why not declare 'extPtr' as a const char* to begin with?
Assignee | ||
Comment 15•24 years ago
|
||
Assignee | ||
Comment 16•24 years ago
|
||
Comment 17•24 years ago
|
||
sr=sfraser on the patch
Assignee | ||
Comment 18•24 years ago
|
||
Since I promised storage closet time with him and hyatt, r=pinkerton. Oh yeah, he thinks the code is okay, too.
Assignee | ||
Comment 19•24 years ago
|
||
Stick a fork in it, checked into tree
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Updated•20 years ago
|
Product: Core → Mozilla Application Suite
You need to log in
before you can comment on or make changes to this bug.
Description
•