January 2009 - Dillo-dev - lists.mailman3.com

dillo CSS and charset

by furaisanjin＠gmail.com

Please ignore this one. I found that my cache.c was corrupted. My local change still remained after updating and that caused this behaviour. 2009/1/25 furaisanjin <furaisanjin(a)gmail.com>: > After pulling from http://freehg.org/u/dillo/main and updating dillo, > the charset conversion problem appeared again. > > Goto http://headlines.yahoo.co.jp/hl (this page is OK) and click some > of article like > http://headlines.yahoo.co.jp/hl?a=20090125-00000013-yom-soci. Charset > conversion doesn't happen on this page. These pages don't contain meta > but HTTP server specifies charset. > > Regards, > furaisanjin >

Jan. 25, 2009

dillo CSS and charset

by furaisanjin＠gmail.com

After pulling from http://freehg.org/u/dillo/main and updating dillo, the charset conversion problem appeared again. Goto http://headlines.yahoo.co.jp/hl (this page is OK) and click some of article like http://headlines.yahoo.co.jp/hl?a=20090125-00000013-yom-soci. Charset conversion doesn't happen on this page. These pages don't contain meta but HTTP server specifies charset. Regards, furaisanjin

Jan. 25, 2009

CSS parser leak

by onepoint＠starurchin.org

On Sat, Jan 24, 2009 at 06:13:48PM +0100, Hofmann Johannes wrote: > ... the problem is that the destructor is not called > atm. CssSimpleSelector is embedded in struct CombinatorAndSelector > which in turn lives in a lout::misc::SimpleVector. So the memory is > allocated with malloc and not properly handled with new/delete. > This is nasty and has to be fixed somehow. ...especially as valgrind reports that this is one of Dillo's biggest leaks. I'm attaching a quick and dirty fix that defines a finalize() method on selectors. This still misses the case when the SimpleVector is resize()-ed, but that appears to be much more rare. The proper fix would be to replace the SimpleVector with a typed Vector with ownerOfObjects = true. Then finalize() could be turned into a proper destructor. That would mean CombinatorAndSelector inheriting Object. Regards, Jeremy Henty

Jan. 24, 2009

inheriting background color

by Johannes.Hofmann＠gmx.de

On Sat, Jan 24, 2009 at 05:43:52PM +0000, corvid wrote: > Is the idea that we should stick in inheritBackgroundColor > whenever we encounter cases like the following? > (I see the "get rid of this somehow" comment.) The inheritBackgroundColor thing is a workaround for elements (<a>, <small> in the below case) that do not create a new dw widget. Things like: <span style="border: 2px solid black">hello</span> don't work at all. I'd like to see a general solution for this but have no idea yet. It's also somehow related to the CSS property "display" (http://www.w3.org/TR/CSS21/visuren.html#display-prop) which is not yet supported at all. But yes, as long as we stick with inheritBackgroundColor, we will need to add it whenever no dw widget is created. Cheers, Johannes > > <head> > <title></title> > <style type="text/css"> > body {background: #000000; color: #00ff00} > </style> > </head> > <body> > <SPAN STYLE='background:#fff6aa;'>link background dark( > <SMALL><A HREF="/">link</A></SMALL> > )</SPAN> > <p> > <SPAN STYLE='background:#fff6aa;'>link background light( > <A HREF="/">link</A>) > </SPAN> > </body> > > > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev

Jan. 24, 2009

inheriting background color

by corvid＠lavabit.com

Is the idea that we should stick in inheritBackgroundColor whenever we encounter cases like the following? (I see the "get rid of this somehow" comment.) <head> <title></title> <style type="text/css"> body {background: #000000; color: #00ff00} </style> </head> <body> <SPAN STYLE='background:#fff6aa;'>link background dark( <SMALL><A HREF="/">link</A></SMALL> )</SPAN> <p> <SPAN STYLE='background:#fff6aa;'>link background light( <A HREF="/">link</A>) </SPAN> </body>

Jan. 24, 2009

CSS parser leak

by Johannes.Hofmann＠gmx.de

On Sat, Jan 24, 2009 at 05:00:02PM +0000, Jeremy Henty wrote: > > The CSS parser gurus will have to verify this for me, but it *seems* > to me that the leak is because the CssSimpleSelector class does not > clean up its id, klass and pseudo members. Furthermore the only > method that sets those members is Css_parse_simple_selector(), and it > always assigns them to new heap-allocated values. So I reckon the fix > is just to add a CssSimpleSelector destructor that dFree()s those > members. Have I missed anything? No, you are right, but the problem is that the destructor is not called atm. CssSimpleSelector is embedded in struct CombinatorAndSelector which in turn lives in a lout::misc::SimpleVector. So the memory is allocated with malloc and not properly handled with new/delete. This is nasty and has to be fixed somehow. Regards, Johannes

Jan. 24, 2009

dillo CSS and charset

by jcid＠dillo.org

On Sat, Jan 24, 2009 at 03:00:33PM +0900, furaisanjin wrote: > Hi. > > This is work around for www.amazon.de. > > diff -r 93de73875a8c src/cache.c > --- a/src/cache.c Thu Jan 22 08:31:44 2009 -0300 > +++ b/src/cache.c Sat Jan 24 14:53:50 2009 +0900 > @@ -747,6 +747,7 @@ > dStr_free(entry->Data, 1); > entry->Data = dStr_sized_new(MIN(entry->ExpectedSize, MAX_INIT_BUF)); > } > + Cache_ref_data(entry); > > /* Get Content-Type */ > if ((Type = Cache_parse_field(header, "Content-Type")) == NULL) { > @@ -762,7 +763,6 @@ > _MSG("TypeMeta {%s}\n", entry->TypeMeta); > dFree(Type); > } > - Cache_ref_data(entry); > } > > /* > > I found that Cache_ref_data position was moved to the bottom. I don't > fully understand the logic but somehow this change helps. You're using repo's tip, right? Cache_ref_data() also updates UTF8Data according to CharsetDecoder (yes it's a trick). That's why moving it after a_Cache_set_content_type() has the effect of initializing the UTF8Data biffer. -- Cheers Jorge.-

Jan. 24, 2009

Valgrind errors: big improvement!

by jcid＠dillo.org

On Sat, Jan 24, 2009 at 03:26:14PM +0000, Jeremy Henty wrote: > > The very latest dillo is vastly more valgrind-clean than before: I got > no errors from my latest browsing session! I'll keep monitoring it > and look at the leak reports too. Good. Yes, there're still some css selector issues and some image structures leaking in border cases. -- Cheers Jorge.-

Jan. 24, 2009

Valgrind errors

by jcid＠dillo.org

On Sat, Jan 24, 2009 at 10:34:45AM +0100, Hofmann Johannes wrote: > On Fri, Jan 23, 2009 at 05:11:54PM -0300, Jorge Arellano Cid wrote: > > On Fri, Jan 23, 2009 at 07:56:33AM +0000, Jeremy Henty wrote: > > > On Fri, Jan 23, 2009 at 03:13:10AM +0000, corvid wrote: > > > > > > > I realized we should really be using entry->Data regardless of > > > > character encoding when showing progress in receiving the > > > > page. Attached. > > > > > > OK, then ignore my earlier patch. Do you expect this to fix both of > > > the valgrind errors, or just the second one as your previous > > > suggestion did? > > > > The new patches added expect to fix the remaining. > > The small patch (2 lines) aims to this problem, and the others are > > cleanups and logic fixes that hope to avoid future troubles. > > > > Please test. > > The amazon.de crash is fixed. > And I don't see any other crashes. Good. (It didn't crash for me, but valgrind complained. Fixing the latter did the trick). -- Cheers Jorge.-

Jan. 24, 2009

CSS parser leak

by onepoint＠starurchin.org

The CSS parser gurus will have to verify this for me, but it *seems* to me that the leak is because the CssSimpleSelector class does not clean up its id, klass and pseudo members. Furthermore the only method that sets those members is Css_parse_simple_selector(), and it always assigns them to new heap-allocated values. So I reckon the fix is just to add a CssSimpleSelector destructor that dFree()s those members. Have I missed anything? Regards, Jeremy Henty

Jan. 24, 2009