Bug 169858
| Summary: | Encoding: TextDecoder does not strip BOM | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Anne van Kesteren <annevk> |
| Component: | DOM | Assignee: | Nobody <webkit-unassigned> |
| Status: | RESOLVED DUPLICATE | ||
| Severity: | Normal | CC: | achristensen, ap, cdumez |
| Priority: | P2 | ||
| Version: | Safari Technology Preview | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
Anne van Kesteren
See https://github.com/w3c/web-platform-tests/pull/5172. Test at https://w3c-test.org/submissions/5172/encoding/textdecoder-copy.any.html and https://w3c-test.org/submissions/5172/encoding/textdecoder-copy.any.worker.html for now (until that PR lands).
| Attachments | ||
|---|---|---|
| Add attachment proposed patch, testcase, etc. |
Alexey Proskuryakov
This seems like it may be performance sensitive. What's the rationale?
Anne van Kesteren
This has been the behavior since the API was introduced. We did introduce a flag ignoreBOM that makes it not stripped.
There's many UTF-8 entry points in the platform that strip a leading BOM, so offering that functionality seems very reasonable and since you know about whether or not it needs to happen when TextDecoder is constructed, it should not necessarily be performance-sensitive I think, but you might want to branch during decode for convenience, which shouldn't be too costly.
Alex Christensen
*** This bug has been marked as a duplicate of bug 216108 ***