Closed
Bug 1071470
Opened 10 years ago
Closed 7 years ago
Remove ISO-8859-1 as a Gecko-canonical encoding
Categories
(Core :: Internationalization, defect)
Core
Internationalization
Tracking
()
RESOLVED
FIXED
mozilla56
People
(Reporter: hsivonen, Assigned: hsivonen)
References
Details
(Whiteboard: [fixed by encoding_rs])
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•10 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...
Comment 2•10 years ago
|
||
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•10 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•8 years ago
|
Depends on: encoding_rs
Assignee | ||
Comment 4•7 years ago
|
||
Fixed by bug 1261841.
Assignee: nobody → hsivonen
Status: NEW → RESOLVED
Closed: 7 years 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.
Description
•