489344 - port uriloader to x86_64 Mac OS X

Status: RESOLVED FIXED

(Core :: General, defect)

Description

[Josh Aas]

We need to port uriloader to 64-bit Mac OS X.

Comment 1

[Josh Aas]

Attachment: fix v1.0

- stop using APIs that don't exist in 64-bit
- drop some unnecessary internet config methods that use deprecated APIs
- don't use apple file decoders in 64-bit since we're disabling them in bug 489280

Comment 2

[Steven Michaud [:smichaud] (Retired)]

Comment on attachment 373844 [details] [diff] [review]
fix v1.0

This basically looks fine to me.  I haven't tried to compile it.

> - drop some unnecessary internet config methods that use deprecated
>   APIs

I've confirmed that neither
nsIInternetConfigService::getFileMappingFlags() nor
nsIInternetConfigService::getDownloadFolder() are used anywhere in the
tree.  I can't imagine why any third party would use
getFileMappingFlags().  But I wonder if extensions might be using
getDownloadFolder().  If so we might need to port it.

> - don't use apple file decoders in 64-bit since we're disabling them
>   in bug 489280

Do we know what (if anything) currently uses the APPLICATION_APPLEFILE
and MULTIPART_APPLEDOUBLE mime types?  I imagine the latter might
still be used by some Mac-specific mail clients.  But Apple Mail on OS
X 10.5.6 doesn't -- I just tried sending myself a test message (with
one attachment), and it used multipart/mixed.

Comment 3

[Josh Aas]

Comment on attachment 373844 [details] [diff] [review]
fix v1.0

Extensions shouldn't be using GetDownloadFolder, they should get that through the directory service like Firefox does or write their own native routines. That method is noscript anyway, so they aren't using it from js.

As for the Apple file encoding, I'm not saying we should or shouldn't port it but we should not hold up the 64-bit port while we do that. I'll be filing a bug and we can port it later if we want to.

Comment 4

[Josh Aas]

pushed to mozilla-central

http://hg.mozilla.org/mozilla-central/rev/9f7ea11dab12