Commit 568d69eb authored by Michal Klocek's avatar Michal Klocek
Browse files

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: default avatarJüri Valdmann <juri.valdmann@qt.io>
parent 5c9dd72f
Showing with 4 additions and 6 deletions
Supports Markdown
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment