If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

file handling APIs fail to deal with non-ascii extensions

RESOLVED DUPLICATE of bug 80787

Status

Core Graveyard
File Handling
RESOLVED DUPLICATE of bug 80787
14 years ago
a year ago

People

(Reporter: Biesinger, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

http://lxr.mozilla.org/seamonkey/source/netwerk/mime/public/nsIMIMEInfo.idl#64
http://lxr.mozilla.org/seamonkey/source/uriloader/exthandler/nsIExternalHelperAppService.idl

all of those use |string| for extensions. better would be AString or wstring, so
that the APIs support non-ascii characters.
Quite frankly, do these come up?

What charset do we assume the extension from nsIURL is in?
>Quite frankly, do these come up?

if a server sends them... I haven't seen any yet, but they aren't prohibited.
also if an application decides to use them, but I haven't seen such an
application either

>What charset do we assume the extension from nsIURL is in?

ASCII, it seems. at least we pass it through |string| parameters. On the other
hand, we don't unescape it.
Blocks: 162116
(In reply to comment #1)
> Quite frankly, do these come up?

apparently, at one time you were convinced of that ;)

*** This bug has been marked as a duplicate of 80787 ***
No longer blocks: 162116
Status: NEW → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → DUPLICATE
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.