Bug 25466

Summary:

WebKitGtk+ 1.1.6 prints weird error messages in Liferea

Product:

WebKit

Reporter:

Adrian Bunk <bunk>

Component:

WebKitGTK

Assignee:

Nobody <webkit-unassigned>

Status:

RESOLVED FIXED

Severity:

Normal

CC:

busg, pochu27, xan.lopez

Priority:

Keywords:

Gtk

Version:

528+ (Nightly build)

Hardware:

OS:

Linux

Attachments:

Description	Flags
error on line 81 at column 12: expected '>'	none
error on line 58 at column 3: Extra content at the end of the document	none
error on line 66 at column 38: expected '>'	none
Calculate the size of the string correctly	zecke: review+

Adrian Bunk

Reported 2009-04-29 12:42:04 PDT

I'll attach examples.

Attachments
error on line 81 at column 12: expected '>' (deleted) 2009-04-29 12:43 PDT, Adrian Bunk	no flags	Details
error on line 58 at column 3: Extra content at the end of the document (deleted) 2009-04-29 12:45 PDT, Adrian Bunk	no flags	Details
error on line 66 at column 38: expected '>' (deleted) 2009-04-29 12:47 PDT, Adrian Bunk	no flags	Details
Calculate the size of the string correctly (1.52 KB, patch) 2009-05-02 05:44 PDT, Gustavo Noronha (kov)	zecke: review+	Details Formatted Diff Diff
View All Add attachment proposed patch, testcase, etc.

Adrian Bunk

Comment 1 2009-04-29 12:43:47 PDT

Created attachment 29890 [details] error on line 81 at column 12: expected '>' it complains about the "h" in the </html> tag

Adrian Bunk

Comment 2 2009-04-29 12:45:58 PDT

Created attachment 29891 [details] error on line 58 at column 3: Extra content at the end of the document the "extra content" is the </body></html>

Adrian Bunk

Comment 3 2009-04-29 12:47:20 PDT

Created attachment 29892 [details] error on line 66 at column 38: expected '>' that's in the middle of the href of <a href="liferea-refresh-comments://lxccyfn-227638"><span>Refresh</span></a>

Adrian Bunk

Comment 4 2009-04-29 13:20:56 PDT

the call to webkit_web_view_load_string() is in https://liferea.svn.sourceforge.net/svnroot/liferea/trunk/liferea/src/webkit/webkit.c Call to webkit_web_view_load_string(): Breakpoint 1, webkit_web_view_load_string (webView=0x182e0b0, content=0x1a89380 "<?xml version=\"1.0\" encoding=\"utf-8\"?><!DOCTYPE html PUBLIC \"-//W3C//DTD XHTML 1.0 Transitional//EN\"\n\"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd\">\n<html xmlns=\"http://www.w3.org/1999/xhtm"..., mimeType=0x46237a "application/xhtml+xml", encoding=0x461614 "UTF-8", baseUri=0x46109f "file://") at WebKit/gtk/webkit/webkitwebview.cpp:2483 2483 {

Adrian Bunk

Comment 5 2009-04-29 13:29:17 PDT

For one optically visible problem (the last of my 3 examples) I have confirmed that the problem is not present with 1.1.5.

Gustavo Noronha (kov)

Comment 6 2009-05-01 20:40:50 PDT

I found the problem, apparently. The problem is that the error code patch refactored the loading of string into a shared function, which mistakenly calls g_utf8_strlen on the string that is to be loaded, so any string with !ascii UTF-8 characters will have some content stripped from the end when creating the SharedBuffer: RefPtr<SharedBuffer> sharedBuffer = SharedBuffer::create(content, g_utf8_strlen(content, -1)); I'm cooking a patch.

Gustavo Noronha (kov)

Comment 7 2009-05-02 05:44:30 PDT

Created attachment 29956 [details] Calculate the size of the string correctly WebKit/gtk/ChangeLog | 13 +++++++++++++ WebKit/gtk/webkit/webkitwebframe.cpp | 2 +- 2 files changed, 14 insertions(+), 1 deletions(-)

Holger Freyther

Comment 8 2009-05-02 12:31:47 PDT

Comment on attachment 29956 [details] Calculate the size of the string correctly > - RefPtr<SharedBuffer> sharedBuffer = SharedBuffer::create(content, g_utf8_strlen(content, -1)); > + RefPtr<SharedBuffer> sharedBuffer = SharedBuffer::create(content, strlen(content)); Yes it makes sense, maybe you also want to add a unit test and compare the html with the one we set?

Gustavo Noronha (kov)

Comment 9 2009-05-02 12:36:55 PDT

(In reply to comment #8) > (From update of attachment 29956 [details] [review]) > > > - RefPtr<SharedBuffer> sharedBuffer = SharedBuffer::create(content, g_utf8_strlen(content, -1)); > > + RefPtr<SharedBuffer> sharedBuffer = SharedBuffer::create(content, strlen(content)); > > > Yes it makes sense, maybe you also want to add a unit test and compare the html > with the one we set? We have no proper way of getting the source code backing a frame, 'till Jan's DataSource patch is landed. I will add a test when we land that =). >

Gustavo Noronha (kov)

Comment 10 2009-05-02 12:40:09 PDT

Landed as r43146. I'll open a bug report to remind me of the unit test.

Note You need to log in before you can comment on or make changes to this bug.