CLOSED FIXED 45240
[Qt] utf8 encoding of console() messages
https://bugs.webkit.org/show_bug.cgi?id=45240
Summary [Qt] utf8 encoding of console() messages
Robert Hogan
Reported 2010-09-05 05:16:45 PDT
http/tests/security/xssAuditor/embed-tag-null-char.html http/tests/security/xssAuditor/object-embed-tag-null-char.html both fail because ChromeClientQt::addMessageToConsole() is casting String to QString rather than String::utf8().data().
Attachments
Patch (3.00 KB, patch)
2010-09-05 05:24 PDT, Robert Hogan
no flags
Patch (3.33 KB, patch)
2010-09-05 10:38 PDT, Robert Hogan
kling: review+
Robert Hogan
Comment 1 2010-09-05 05:24:05 PDT
Antonio Gomes
Comment 2 2010-09-05 06:10:43 PDT
Comment on attachment 66596 [details] Patch What about bug 35263 ?
Robert Hogan
Comment 3 2010-09-05 07:12:17 PDT
(In reply to comment #2) > (From update of attachment 66596 [details]) > What about bug 35263 ? That ref in the Skipped list is misleading - bugs are unrelated. I think it was me who added that misleading reference!
WebKit Commit Bot
Comment 4 2010-09-05 07:28:46 PDT
Comment on attachment 66596 [details] Patch Clearing flags on attachment: 66596 Committed r66801: <http://trac.webkit.org/changeset/66801>
WebKit Commit Bot
Comment 5 2010-09-05 07:28:51 PDT
All reviewed patches have been landed. Closing bug.
WebKit Review Bot
Comment 6 2010-09-05 08:00:57 PDT
http://trac.webkit.org/changeset/66801 might have broken Qt Linux Release
Antonio Gomes
Comment 7 2010-09-05 10:19:38 PDT
it was rolled out. reopenning
Robert Hogan
Comment 8 2010-09-05 10:38:39 PDT
Robert Hogan
Comment 9 2010-09-05 10:41:32 PDT
(In reply to comment #7) > it was rolled out. reopenning I think I understand the problem now. However the solution involves creating a QString, casting to a QByteArray, then char*, then String, then back to QString, then a QByteArray, then const *char - at which point something finally gets printed out!
Andreas Kling
Comment 10 2010-09-05 16:42:17 PDT
Comment on attachment 66599 [details] Patch > + return StringImpl::create(buffer.toUtf8().constData(), buffer.toUtf8().length()); This will cause the UTF-8 conversion to be done twice. r=me, but please fix that before landing.
Robert Hogan
Comment 11 2010-09-06 11:43:18 PDT
(In reply to comment #10) > (From update of attachment 66599 [details]) > > + return StringImpl::create(buffer.toUtf8().constData(), buffer.toUtf8().length()); > > This will cause the UTF-8 conversion to be done twice. > > r=me, but please fix that before landing. heh, right enough. i think i get it now!
Robert Hogan
Comment 12 2010-09-06 12:11:33 PDT
WebKit Review Bot
Comment 13 2010-09-06 12:17:21 PDT
http://trac.webkit.org/changeset/66843 might have broken Qt Linux Release minimal, Qt Linux ARMv5 Release, and Qt Linux ARMv7 Release
Robert Hogan
Comment 14 2010-09-06 12:46:55 PDT
(In reply to comment #10) > (From update of attachment 66599 [details]) > > + return StringImpl::create(buffer.toUtf8().constData(), buffer.toUtf8().length()); > > This will cause the UTF-8 conversion to be done twice. > > r=me, but please fix that before landing. I thought I had followed your advice but made the change during a compile and mistakenly thought it had been caught - but it hadn't. I don't see a way of fixing this without using toUtf8().constData().
Antonio Gomes
Comment 15 2010-09-06 14:10:30 PDT
(In reply to comment #14) > (In reply to comment #10) > > (From update of attachment 66599 [details] [details]) > > > + return StringImpl::create(buffer.toUtf8().constData(), buffer.toUtf8().length()); > > > > This will cause the UTF-8 conversion to be done twice. > > > > r=me, but please fix that before landing. > > I thought I had followed your advice but made the change during a compile and mistakenly thought it had been caught - but it hadn't. > > I don't see a way of fixing this without using toUtf8().constData(). maybe he was referring you called buffer.toUtf8() twice?
Note You need to log in before you can comment on or make changes to this bug.