Closed Bug 863728 Opened 6 years ago Closed 6 years ago

Implement the replacement encoding

Categories

(Core :: Internationalization, defect)

defect
Not set

Tracking

()

RESOLVED FIXED
mozilla28

People

(Reporter: hsivonen, Assigned: hsivonen)

References

(Blocks 1 open bug)

Details

Attachments

(2 files, 3 obsolete files)

Blocks: encoding
Status: NEW → ASSIGNED
Attached patch Implement the encoding (obsolete) — Splinter Review
Attached patch Tests (obsolete) — Splinter Review
Attached patch Tests, v2Splinter Review
Attachment #827363 - Attachment is obsolete: true
Depends on: 805374
Depends on: 936439
Attachment #827361 - Attachment is obsolete: true
Attachment #827362 - Attachment is obsolete: true
Comment on attachment 832142 [details] [diff] [review]
The whole thing as one patch

Some notes:
 * The changes from GetUnicodeDecoder to GetUnicodeDecoderRaw are there to avoid trips through the old alias table.

 * The bulk of the nsHtml5StreamParser changes are about deferring the commitment to a user-overridden encoding so that the replacement encoding can take precedence over the menu. Otherwise, socially engineered XSS would still work.

 * The replacement encoding doesn't inherit into iframes if you use script to inject an iframe into a replacement encoding document. This is mainly to keep the concept "doesn't inherit" and "ignores the menu" the same.
Attachment #832142 - Flags: review?(VYV03354)
Oh, and there's no actual dependency on bug 936439, because asserting stuff isn't really feasible before bug 805374 lands.
No longer depends on: 936439
Blocks: 941562
Comment on attachment 832142 [details] [diff] [review]
The whole thing as one patch

Review of attachment 832142 [details] [diff] [review]:
-----------------------------------------------------------------

Probably you will have to update moz2javaCharset in dom/plugins/base/nsPluginInstanceOwner.cpp.

::: dom/encoding/test/test_TextDecoder.js
@@ +352,4 @@
>      {encoding: "utf-16le", labels: ["utf-16", "utf-16le"]},
>      {encoding: "utf-16be", labels: ["utf-16be"]},
>      {encoding: "x-user-defined", labels: ["x-user-defined"]},
> +    {error: "TypeError", labels: ["x-windows-949", "\u0130SO-8859-1", "csiso2022kr", "iso-2022-kr", "iso-2022-cn-ext", "iso-2022-cn-ext", "replacement"]},

Why "iso-2022-cn-ext" is included twice? (One should be "iso-2022-cn".)
Attachment #832142 - Flags: review?(VYV03354) → review+
(In reply to Masatoshi Kimura [:emk] from comment #11)
> Probably you will have to update moz2javaCharset in
> dom/plugins/base/nsPluginInstanceOwner.cpp.

Or delete the code, more likely: bug 942706.

> ::: dom/encoding/test/test_TextDecoder.js
> @@ +352,4 @@
> >      {encoding: "utf-16le", labels: ["utf-16", "utf-16le"]},
> >      {encoding: "utf-16be", labels: ["utf-16be"]},
> >      {encoding: "x-user-defined", labels: ["x-user-defined"]},
> > +    {error: "TypeError", labels: ["x-windows-949", "\u0130SO-8859-1", "csiso2022kr", "iso-2022-kr", "iso-2022-cn-ext", "iso-2022-cn-ext", "replacement"]},
> 
> Why "iso-2022-cn-ext" is included twice? (One should be "iso-2022-cn".)

Oops. Landed with that fixed:
https://hg.mozilla.org/integration/mozilla-inbound/rev/3336625f130b

Thank you.
https://hg.mozilla.org/mozilla-central/rev/3336625f130b
Status: ASSIGNED → RESOLVED
Closed: 6 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Target Milestone: --- → mozilla28
You need to log in before you can comment on or make changes to this bug.