Bug 45240

Summary: [Qt] utf8 encoding of console() messages
Product: WebKit Reporter: Robert Hogan <robert>
Component: WebKit APIAssignee: Robert Hogan <robert>
Status: CLOSED FIXED    
Severity: Normal CC: abarth, commit-queue, eric, tonikitoo, webkit.review.bot
Priority: P2 Keywords: Qt, QtTriaged
Version: 528+ (Nightly build)   
Hardware: PC   
OS: OS X 10.5   
Bug Depends on: 45242, 45314    
Bug Blocks:    
Attachments:
Description Flags
Patch
none
Patch kling: review+

Description Robert Hogan 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().
Comment 1 Robert Hogan 2010-09-05 05:24:05 PDT
Created attachment 66596 [details]
Patch
Comment 2 Antonio Gomes 2010-09-05 06:10:43 PDT
Comment on attachment 66596 [details]
Patch

What about bug 35263 ?
Comment 3 Robert Hogan 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!
Comment 4 WebKit Commit Bot 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>
Comment 5 WebKit Commit Bot 2010-09-05 07:28:51 PDT
All reviewed patches have been landed.  Closing bug.
Comment 6 WebKit Review Bot 2010-09-05 08:00:57 PDT
http://trac.webkit.org/changeset/66801 might have broken Qt Linux Release
Comment 7 Antonio Gomes 2010-09-05 10:19:38 PDT
it was rolled out. reopenning
Comment 8 Robert Hogan 2010-09-05 10:38:39 PDT
Created attachment 66599 [details]
Patch
Comment 9 Robert Hogan 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!
Comment 10 Andreas Kling 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.
Comment 11 Robert Hogan 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!
Comment 12 Robert Hogan 2010-09-06 12:11:33 PDT
Committed r66843: <http://trac.webkit.org/changeset/66843>
Comment 13 WebKit Review Bot 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
Comment 14 Robert Hogan 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().
Comment 15 Antonio Gomes 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?