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

Description Anne van Kesteren 2017-03-19 06:19:03 PDT

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).

Comment 1 Alexey Proskuryakov 2017-03-19 13:45:16 PDT

This seems like it may be performance sensitive. What's the rationale?

Comment 2 Anne van Kesteren 2017-03-20 00:58:09 PDT

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.

Comment 3 Alex Christensen 2020-09-02 20:06:55 PDT


*** This bug has been marked as a duplicate of bug 216108 ***