RESOLVED FIXED 25466
WebKitGtk+ 1.1.6 prints weird error messages in Liferea
https://bugs.webkit.org/show_bug.cgi?id=25466
Summary WebKitGtk+ 1.1.6 prints weird error messages in Liferea
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
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
error on line 66 at column 38: expected '>' (deleted)
2009-04-29 12:47 PDT, Adrian Bunk
no flags
Calculate the size of the string correctly (1.52 KB, patch)
2009-05-02 05:44 PDT, Gustavo Noronha (kov)
zecke: review+
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.