diff options
author | Michal Klocek <michal.klocek@qt.io> | 2019-04-26 17:54:17 +0200 |
---|---|---|
committer | Michal Klocek <michal.klocek@qt.io> | 2019-05-03 09:27:00 +0000 |
commit | 568d69eb5c1799dd8706df1ed3a1c85a778c6799 (patch) | |
tree | dfd0c1d58ae61575394963ec77de5cf30b7dea39 /src/core/api/qwebengineregisterprotocolhandlerrequest.cpp | |
parent | 5c9dd72f8270370917031a4459541352977dcc8e (diff) | |
download | qtwebengine-568d69eb5c1799dd8706df1ed3a1c85a778c6799.tar.gz |
Do not blacklist webChannelWithBadString
This commit is about documenting some weird new behavior.
Since Chormium 72 our webChannelWithBadString fails. This is
fascinating issue and can be tracked down to commit in Chromium
https://chromium-review.googlesource.com/c/1282993
which "fixes" well-forming of JSON.strigify. This function
is used by webchannel.js to send data through webchannel
transport. In c++ land we get now for invalid utf16 replacement
in form of '\\u' + i.toString(16).padStart(4, '0').
This sadly does not trigger any longer REPLACE_INVALID_UTF8 in
WebChannelTransport::NativeQtSendMessage. Moreover
this goes even "worse" since QMetaObjectPublisher
will create invalid utf16 form raw "\ud800" string -> '\ud800'.
This is not an error per se, since test creates invalid utf16
character in javascript and it ends as invalid utf8 character in c++.
Btw enable test on qemu.
Change-Id: I36f2df417d7b9f3f2113792f08025821737d8d01
Reviewed-by: Jüri Valdmann <juri.valdmann@qt.io>
Diffstat (limited to 'src/core/api/qwebengineregisterprotocolhandlerrequest.cpp')
0 files changed, 0 insertions, 0 deletions