All users were logged out of Bugzilla on October 13th, 2018

Remove ISO-8859-1 as a Gecko-canonical encoding

RESOLVED FIXED in mozilla56

Status

()

--
trivial
RESOLVED FIXED
4 years ago
a year ago

People

(Reporter: hsivonen, Assigned: hsivonen)

Tracking

unspecified
mozilla56
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [fixed by encoding_rs])

(Assignee)

Description

4 years ago
Bug 1070992 left the ISO-8859-1 Gecko-canonical name and the encoder around. AFAICT, we aren't actually relying on the encoder behavior being different from windows-1252 anywhere in m-c. We do have plenty of references to ISO-8859-1 that would need updating if ISO-8859-1 stopped being a Gecko-canonical name.

We should try to remove ISO-8859-1 as a Gecko-canonical encoding. However, not doing it just yet, because it would rot my queue of other uconv removals.

Comment 1

4 years ago
HTTP and IDL's ByteString (used by XMLHttpRequest, Fetch) rely on the behavior that iso-8859-1 has. Perhaps we implemented that as a simple conversion function though...
We don't use the intl stuff for ByteString.  It wouldn't have the right behavior anyway, I expect, and would make sane error-reporting difficult even if we managed to get the right behavior out of it.
(Assignee)

Comment 3

4 years ago
I'm pretty sure our networking code for HTTP headers ends up using the XPCOM string conversions that drop the high byte from char16_t and zero-extend char.
(Assignee)

Updated

3 years ago
Depends on: 1261841
(Assignee)

Comment 4

a year ago
Fixed by bug 1261841.
Assignee: nobody → hsivonen
Status: NEW → RESOLVED
Last Resolved: a year ago
Resolution: --- → FIXED
Whiteboard: [fixed by encoding_rs]
Target Milestone: --- → mozilla56
You need to log in before you can comment on or make changes to this bug.