Previously failed textDecoder.decode call will cause failure of successive calls
Reported by
christia...@gmail.com,
Nov 29
|
||||||
Issue description
UserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.110 Safari/537.36
Steps to reproduce the problem:
const log = console.log
let string = 'Hello ♥ world! ♥'
let textEncoder = new TextEncoder()
let bytes = textEncoder.encode(string)
let textDecoder = new TextDecoder('utf-8', {fatal: true})
try {
// Comment away this line and the code below will work
log(textDecoder.decode(new DataView(bytes.buffer, 0, 19)))
} catch (e) {
log('After this failed the next try will also fail')
}
log(textDecoder.decode(new DataView(bytes.buffer, 0, 20)))
What is the expected behavior?
No errors and text correctly decoded; confirmed to work in latest Firefox.
What went wrong?
Uncaught TypeError: Failed to execute 'decode' on 'TextDecoder': The encoded data was not valid.
Did this work before? N/A
Chrome version: 70.0.3538.110 Channel: beta
OS Version: Debian unstable (sid) x86_64
Flash Version:
,
Dec 3
Thanks for filing the issue! Able to reproduce the issue on reported chrome version 70.0.3538.110 and on the latest canary 72.0.3626.0 using Mac 10.14.1, Ubuntu 14.04 and Windows 10. As the issue is seen from M60(60.0.3112.0) considering it as Non-Regression and marking it as Untriaged.
,
Dec 3
,
Dec 13
,
Dec 13
,
Dec 13
Thanks for the bug report! I've got a fix in progress
,
Dec 17
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/bcf7f66edeb9e5f3307e19bef072f74810767d25 commit bcf7f66edeb9e5f3307e19bef072f74810767d25 Author: Joshua Bell <jsbell@chromium.org> Date: Mon Dec 17 20:46:20 2018 TextDecoder: previous failure should not stick around When the {fatal:true} option is used, the decode() calls throw rather than generating U+FFFD on bad data. Subsequent decode() calls should work as the codec state should be flushed (unless {stream:true} was specified). Blink was not flushing the codec state, so subsequent calls would throw. Fix by flushing the codec state (instantiating a new codec), and align the implementation's code flow/state more closely with the spec. Also added a new WPT test case, based on the bug report. Bug: 910292 Change-Id: Ia47b902b69a4b469341e272ed42bb6b05248c1d8 Reviewed-on: https://chromium-review.googlesource.com/c/1376656 Reviewed-by: Adam Rice <ricea@chromium.org> Commit-Queue: Joshua Bell <jsbell@chromium.org> Cr-Commit-Position: refs/heads/master@{#617215} [modify] https://crrev.com/bcf7f66edeb9e5f3307e19bef072f74810767d25/third_party/blink/renderer/modules/encoding/text_decoder.cc [modify] https://crrev.com/bcf7f66edeb9e5f3307e19bef072f74810767d25/third_party/blink/renderer/modules/encoding/text_decoder.h [modify] https://crrev.com/bcf7f66edeb9e5f3307e19bef072f74810767d25/third_party/blink/web_tests/external/wpt/encoding/textdecoder-fatal.any.js
,
Dec 17
Fixed! Please give it a whirl in an upcoming Canary build. |
||||||
►
Sign in to add a comment |
||||||
Comment 1 by viswa.karala@chromium.org
, Nov 30