169858 2017-03-19 06:19:03 -0700 Encoding: TextDecoder does not strip BOM 2020-09-02 20:06:55 -0700 1 1 1 Unclassified WebKit DOM Safari Technology Preview Unspecified Unspecified RESOLVED DUPLICATE 216108 P2 Normal --- 1 annevk webkit-unassigned achristensen ap cdumez oldest_to_newest 1289360 0 annevk 2017-03-19 06:19:03 -0700 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). 1289393 1 ap 2017-03-19 13:45:16 -0700 This seems like it may be performance sensitive. What's the rationale? 1289443 2 annevk 2017-03-20 00:58:09 -0700 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. 1685119 3 achristensen 2020-09-02 20:06:55 -0700 *** This bug has been marked as a duplicate of bug 216108 ***