- Dillo-dev - lists.mailman3.com

IMG ratio

by corvid＠lavabit.com

I wrote: > Johannes wrote: > > On Sun, Jan 11, 2009 at 09:00:51AM -0300, Jorge Arellano Cid wrote: > > > On Sun, Jan 11, 2009 at 01:00:14AM +0000, corvid wrote: > > > > Johannes wrote: > > > > > On Fri, Jan 09, 2009 at 11:58:54PM +0100, Hofmann Johannes wrote: > > > > > > I think the html part needs not be changed. Everything is available > > > > > > in style already. > > > > > > I've attached a quick patch that seems to work for fixed sizes. > > > > > > It does not handle something like width="50%" however. > > > > > > > > > > As the patch works rather well for me and improves the current > > > > > behaviour, I've cleaned it up a bit (avoiding a possible division by > > > > > 0) for inclusion into main. > > > > > > > > Loading an image scales properly for me, but I still see > > > > lack of scaling when I leave a page and come back. > > > > Is that supposed to work now? > > > > > > Yes, it is supposed to work. > > > > > > Altough now that you mention it, I have problems the *first* > > > time a only-one-dimension-specified image tag is loaded. Once coming back > > > it works OK. This is because the second time the image dimensions > > > are known from the dicache. > > > > > > Patch 8f7293125059 from main fixes this. > > > > > > Johannes: please test and merge. > > > > Done. > > > > corvid, can you please verify that this fixes the issue you were > > seeing? > > Same problem for me still. > It turns out that > > <img src="http://www.dillo.org/wearlab.png" height=20> > > in isolation works fine, but > > <a href="http://auriga.wearlab.de/"> > <img src="http://www.dillo.org/wearlab.png" height=20> > </a> > > doesn't. Ah, it works for me with css-prototype but not with main. I didn't realize there would be any difference. Sorry for any confusion...

Jan. 11, 2009

IMG ratio

by corvid＠lavabit.com

Johannes wrote: > On Sun, Jan 11, 2009 at 09:00:51AM -0300, Jorge Arellano Cid wrote: > > On Sun, Jan 11, 2009 at 01:00:14AM +0000, corvid wrote: > > > Johannes wrote: > > > > On Fri, Jan 09, 2009 at 11:58:54PM +0100, Hofmann Johannes wrote: > > > > > I think the html part needs not be changed. Everything is available > > > > > in style already. > > > > > I've attached a quick patch that seems to work for fixed sizes. > > > > > It does not handle something like width="50%" however. > > > > > > > > As the patch works rather well for me and improves the current > > > > behaviour, I've cleaned it up a bit (avoiding a possible division by > > > > 0) for inclusion into main. > > > > > > Loading an image scales properly for me, but I still see > > > lack of scaling when I leave a page and come back. > > > Is that supposed to work now? > > > > Yes, it is supposed to work. > > > > Altough now that you mention it, I have problems the *first* > > time a only-one-dimension-specified image tag is loaded. Once coming back > > it works OK. This is because the second time the image dimensions > > are known from the dicache. > > > > Patch 8f7293125059 from main fixes this. > > > > Johannes: please test and merge. > > Done. > > corvid, can you please verify that this fixes the issue you were > seeing? Same problem for me still. It turns out that <img src="http://www.dillo.org/wearlab.png" height=20> in isolation works fine, but <a href="http://auriga.wearlab.de/"> <img src="http://www.dillo.org/wearlab.png" height=20> </a> doesn't.

Jan. 11, 2009

IMG ratio

by Johannes.Hofmann＠gmx.de

On Sun, Jan 11, 2009 at 09:00:51AM -0300, Jorge Arellano Cid wrote: > On Sun, Jan 11, 2009 at 01:00:14AM +0000, corvid wrote: > > Johannes wrote: > > > On Fri, Jan 09, 2009 at 11:58:54PM +0100, Hofmann Johannes wrote: > > > > I think the html part needs not be changed. Everything is available > > > > in style already. > > > > I've attached a quick patch that seems to work for fixed sizes. > > > > It does not handle something like width="50%" however. > > > > > > As the patch works rather well for me and improves the current > > > behaviour, I've cleaned it up a bit (avoiding a possible division by > > > 0) for inclusion into main. > > > > Loading an image scales properly for me, but I still see > > lack of scaling when I leave a page and come back. > > Is that supposed to work now? > > Yes, it is supposed to work. > > Altough now that you mention it, I have problems the *first* > time a only-one-dimension-specified image tag is loaded. Once coming back > it works OK. This is because the second time the image dimensions > are known from the dicache. > > Patch 8f7293125059 from main fixes this. > > Johannes: please test and merge. Done. corvid, can you please verify that this fixes the issue you were seeing? Cheers, Johannes

Jan. 11, 2009

Blimey, when was this fixed? Selections are fast!

by onepoint＠starurchin.org

I used to complain that drawing the text selection was desperately slow when I dragged the mouse across the contents of a table with two columns and very many rows. Today I suddenly realised that this hadn't bothered me for a while, so I checked the problem page and indeed the selection now draws itself as fast I can drag the mouse. Big thanks to whoever fixed this performance bug! Regards, Jeremy Henty

Jan. 11, 2009

IMG ratio

by jcid＠dillo.org

On Sun, Jan 11, 2009 at 01:00:14AM +0000, corvid wrote: > Johannes wrote: > > On Fri, Jan 09, 2009 at 11:58:54PM +0100, Hofmann Johannes wrote: > > > I think the html part needs not be changed. Everything is available > > > in style already. > > > I've attached a quick patch that seems to work for fixed sizes. > > > It does not handle something like width="50%" however. > > > > As the patch works rather well for me and improves the current > > behaviour, I've cleaned it up a bit (avoiding a possible division by > > 0) for inclusion into main. > > Loading an image scales properly for me, but I still see > lack of scaling when I leave a page and come back. > Is that supposed to work now? Yes, it is supposed to work. Altough now that you mention it, I have problems the *first* time a only-one-dimension-specified image tag is loaded. Once coming back it works OK. This is because the second time the image dimensions are known from the dicache. Patch 8f7293125059 from main fixes this. Johannes: please test and merge. -- Cheers Jorge.-

Jan. 11, 2009

IMG ratio

by corvid＠lavabit.com

Johannes wrote: > On Fri, Jan 09, 2009 at 11:58:54PM +0100, Hofmann Johannes wrote: > > I think the html part needs not be changed. Everything is available > > in style already. > > I've attached a quick patch that seems to work for fixed sizes. > > It does not handle something like width="50%" however. > > As the patch works rather well for me and improves the current > behaviour, I've cleaned it up a bit (avoiding a possible division by > 0) for inclusion into main. Loading an image scales properly for me, but I still see lack of scaling when I leave a page and come back. Is that supposed to work now?

Jan. 11, 2009

IMG ratio

by jcid＠dillo.org

On Sat, Jan 10, 2009 at 02:07:57PM +0100, Hofmann Johannes wrote: > On Fri, Jan 09, 2009 at 11:58:54PM +0100, Hofmann Johannes wrote: > > On Fri, Jan 09, 2009 at 06:53:12PM -0300, Jorge Arellano Cid wrote: > > > On Fri, Jan 09, 2009 at 08:27:17PM +0100, Hofmann Johannes wrote: > > > > On Fri, Jan 09, 2009 at 04:11:36PM -0300, Jorge Arellano Cid wrote: > > > > > On Fri, Jan 09, 2009 at 06:04:09PM +0100, Hofmann Johannes wrote: > > > > > > Hi Jorge, > > > > > > > > > > > > On Fri, Jan 09, 2009 at 02:00:20PM -0300, Jorge Arellano Cid wrote: > > > > > > > Hi Johannes, > > > > > > > > > > > > > > Now that I have the image process mostly in my head, I'd like > > > > > > > to hook correct image ratio scaling when only one of width/height > > > > > > > is given. > > > > > > > > > > > > > > I see scaling done with the styleengine in a_Html_add_new_image > > > > > > > but 'props' goes away when popping the tag. How do I handle this? > > > > > > > > > > > > > > Do I have to preserve props in the stack until I have the > > > > > > > final data, or is there another way? Please explain. > > > > > > > > > > > > What about just setting the data that is available (width, height, > > > > > > or both) and let the image do the rest? > > > > > > It already handles the case where neither width nor height are > > > > > > given. > > > > > > So it should be possible to make it work with just width or > > > > > > height too. Am I missing something? > > > > > > > > > > Yes, the problem is when only one of the dimenssions is given, > > > > > bacause the other one is only known at image arrival time (much > > > > > later). > > > > > > > > > > i.e. Only once the real dimenssions of the image are known it > > > > > is possible to calculate the missing one. At this time, props is > > > > > long gone, and thus the question. > > > > > > > > Yes, props is gone, but - if not overridden - it's data will have > > > > made it into the style object associated with the image. > > > > > > How do I get to the style object of a dw::Image? > > > (once endElement has been called on it) > > > > > > > I guess the calculation of the missing dimension could be done in > > > > Image::sizeRequestImpl() or Image::sizeAllocateImpl() but I haven't > > > > looked at it enough to know exactly. > > > > > > I guess we're in a situation were you know easily the style > > > part and I know how to hook the rest, hence the conversation! :-) > > > > > > The HTML-requested size can be stored in the DilloImage structure, > > > and updated in a_Image_set_parms(). The latter is called by the dicache > > > when the original width and height are known. So at this point we have > > > the requested size, original size and dw:Image well defined. > > > > I think the html part needs not be changed. Everything is available > > in style already. > > I've attached a quick patch that seems to work for fixed sizes. > > It does not handle something like width="50%" however. > > As the patch works rather well for me and improves the current > behaviour, I've cleaned it up a bit (avoiding a possible division by > 0) for inclusion into main. Committed! I'm stuck chasing what looks like a weird bug in the image code... (not from this patch). -- Cheers Jorge.-

Jan. 10, 2009

IMG ratio

by Johannes.Hofmann＠gmx.de

On Fri, Jan 09, 2009 at 11:58:54PM +0100, Hofmann Johannes wrote: > On Fri, Jan 09, 2009 at 06:53:12PM -0300, Jorge Arellano Cid wrote: > > On Fri, Jan 09, 2009 at 08:27:17PM +0100, Hofmann Johannes wrote: > > > On Fri, Jan 09, 2009 at 04:11:36PM -0300, Jorge Arellano Cid wrote: > > > > On Fri, Jan 09, 2009 at 06:04:09PM +0100, Hofmann Johannes wrote: > > > > > Hi Jorge, > > > > > > > > > > On Fri, Jan 09, 2009 at 02:00:20PM -0300, Jorge Arellano Cid wrote: > > > > > > Hi Johannes, > > > > > > > > > > > > Now that I have the image process mostly in my head, I'd like > > > > > > to hook correct image ratio scaling when only one of width/height > > > > > > is given. > > > > > > > > > > > > I see scaling done with the styleengine in a_Html_add_new_image > > > > > > but 'props' goes away when popping the tag. How do I handle this? > > > > > > > > > > > > Do I have to preserve props in the stack until I have the > > > > > > final data, or is there another way? Please explain. > > > > > > > > > > What about just setting the data that is available (width, height, > > > > > or both) and let the image do the rest? > > > > > It already handles the case where neither width nor height are > > > > > given. > > > > > So it should be possible to make it work with just width or > > > > > height too. Am I missing something? > > > > > > > > Yes, the problem is when only one of the dimenssions is given, > > > > bacause the other one is only known at image arrival time (much > > > > later). > > > > > > > > i.e. Only once the real dimenssions of the image are known it > > > > is possible to calculate the missing one. At this time, props is > > > > long gone, and thus the question. > > > > > > Yes, props is gone, but - if not overridden - it's data will have > > > made it into the style object associated with the image. > > > > How do I get to the style object of a dw::Image? > > (once endElement has been called on it) > > > > > I guess the calculation of the missing dimension could be done in > > > Image::sizeRequestImpl() or Image::sizeAllocateImpl() but I haven't > > > looked at it enough to know exactly. > > > > I guess we're in a situation were you know easily the style > > part and I know how to hook the rest, hence the conversation! :-) > > > > The HTML-requested size can be stored in the DilloImage structure, > > and updated in a_Image_set_parms(). The latter is called by the dicache > > when the original width and height are known. So at this point we have > > the requested size, original size and dw:Image well defined. > > I think the html part needs not be changed. Everything is available > in style already. > I've attached a quick patch that seems to work for fixed sizes. > It does not handle something like width="50%" however. As the patch works rather well for me and improves the current behaviour, I've cleaned it up a bit (avoiding a possible division by 0) for inclusion into main. Cheers, Johannes

Jan. 10, 2009

IMG ratio

by Johannes.Hofmann＠gmx.de

On Fri, Jan 09, 2009 at 06:53:12PM -0300, Jorge Arellano Cid wrote: > On Fri, Jan 09, 2009 at 08:27:17PM +0100, Hofmann Johannes wrote: > > On Fri, Jan 09, 2009 at 04:11:36PM -0300, Jorge Arellano Cid wrote: > > > On Fri, Jan 09, 2009 at 06:04:09PM +0100, Hofmann Johannes wrote: > > > > Hi Jorge, > > > > > > > > On Fri, Jan 09, 2009 at 02:00:20PM -0300, Jorge Arellano Cid wrote: > > > > > Hi Johannes, > > > > > > > > > > Now that I have the image process mostly in my head, I'd like > > > > > to hook correct image ratio scaling when only one of width/height > > > > > is given. > > > > > > > > > > I see scaling done with the styleengine in a_Html_add_new_image > > > > > but 'props' goes away when popping the tag. How do I handle this? > > > > > > > > > > Do I have to preserve props in the stack until I have the > > > > > final data, or is there another way? Please explain. > > > > > > > > What about just setting the data that is available (width, height, > > > > or both) and let the image do the rest? > > > > It already handles the case where neither width nor height are > > > > given. > > > > So it should be possible to make it work with just width or > > > > height too. Am I missing something? > > > > > > Yes, the problem is when only one of the dimenssions is given, > > > bacause the other one is only known at image arrival time (much > > > later). > > > > > > i.e. Only once the real dimenssions of the image are known it > > > is possible to calculate the missing one. At this time, props is > > > long gone, and thus the question. > > > > Yes, props is gone, but - if not overridden - it's data will have > > made it into the style object associated with the image. > > How do I get to the style object of a dw::Image? > (once endElement has been called on it) > > > I guess the calculation of the missing dimension could be done in > > Image::sizeRequestImpl() or Image::sizeAllocateImpl() but I haven't > > looked at it enough to know exactly. > > I guess we're in a situation were you know easily the style > part and I know how to hook the rest, hence the conversation! :-) > > The HTML-requested size can be stored in the DilloImage structure, > and updated in a_Image_set_parms(). The latter is called by the dicache > when the original width and height are known. So at this point we have > the requested size, original size and dw:Image well defined. I think the html part needs not be changed. Everything is available in style already. I've attached a quick patch that seems to work for fixed sizes. It does not handle something like width="50%" however. Cheers, Johannes

Jan. 10, 2009

IMG ratio

by jcid＠dillo.org

On Fri, Jan 09, 2009 at 08:27:17PM +0100, Hofmann Johannes wrote: > On Fri, Jan 09, 2009 at 04:11:36PM -0300, Jorge Arellano Cid wrote: > > On Fri, Jan 09, 2009 at 06:04:09PM +0100, Hofmann Johannes wrote: > > > Hi Jorge, > > > > > > On Fri, Jan 09, 2009 at 02:00:20PM -0300, Jorge Arellano Cid wrote: > > > > Hi Johannes, > > > > > > > > Now that I have the image process mostly in my head, I'd like > > > > to hook correct image ratio scaling when only one of width/height > > > > is given. > > > > > > > > I see scaling done with the styleengine in a_Html_add_new_image > > > > but 'props' goes away when popping the tag. How do I handle this? > > > > > > > > Do I have to preserve props in the stack until I have the > > > > final data, or is there another way? Please explain. > > > > > > What about just setting the data that is available (width, height, > > > or both) and let the image do the rest? > > > It already handles the case where neither width nor height are > > > given. > > > So it should be possible to make it work with just width or > > > height too. Am I missing something? > > > > Yes, the problem is when only one of the dimenssions is given, > > bacause the other one is only known at image arrival time (much > > later). > > > > i.e. Only once the real dimenssions of the image are known it > > is possible to calculate the missing one. At this time, props is > > long gone, and thus the question. > > Yes, props is gone, but - if not overridden - it's data will have > made it into the style object associated with the image. How do I get to the style object of a dw::Image? (once endElement has been called on it) > I guess the calculation of the missing dimension could be done in > Image::sizeRequestImpl() or Image::sizeAllocateImpl() but I haven't > looked at it enough to know exactly. I guess we're in a situation were you know easily the style part and I know how to hook the rest, hence the conversation! :-) The HTML-requested size can be stored in the DilloImage structure, and updated in a_Image_set_parms(). The latter is called by the dicache when the original width and height are known. So at this point we have the requested size, original size and dw:Image well defined. -- Cheers Jorge.-

Jan. 9, 2009

CSS freeze

by Johannes.Hofmann＠gmx.de

Hi Jorge, On Fri, Jan 09, 2009 at 04:32:33PM -0300, Jorge Arellano Cid wrote: > Hi, > > Current and former CSS protos freeze on this page: > > http://www.instantfundas.com/2007/12/5-opera-tricks-you-did-not-know-about.… I know that one... It is looping in the CSS parser. table td, { margin: 0em } is enough to reproduce the problem. Fixes welcome. The whole CSS parsing code is a bit fragile and it would be nice to make sure somehow that it never loops on any input. Fixes and suggestions welcome :-) Cheers, Johannes

Jan. 9, 2009

IMG ratio

by Johannes.Hofmann＠gmx.de

On Fri, Jan 09, 2009 at 04:11:36PM -0300, Jorge Arellano Cid wrote: > On Fri, Jan 09, 2009 at 06:04:09PM +0100, Hofmann Johannes wrote: > > Hi Jorge, > > > > On Fri, Jan 09, 2009 at 02:00:20PM -0300, Jorge Arellano Cid wrote: > > > Hi Johannes, > > > > > > Now that I have the image process mostly in my head, I'd like > > > to hook correct image ratio scaling when only one of width/height > > > is given. > > > > > > I see scaling done with the styleengine in a_Html_add_new_image > > > but 'props' goes away when popping the tag. How do I handle this? > > > > > > Do I have to preserve props in the stack until I have the > > > final data, or is there another way? Please explain. > > > > What about just setting the data that is available (width, height, > > or both) and let the image do the rest? > > It already handles the case where neither width nor height are > > given. > > So it should be possible to make it work with just width or > > height too. Am I missing something? > > Yes, the problem is when only one of the dimenssions is given, > bacause the other one is only known at image arrival time (much > later). > > i.e. Only once the real dimenssions of the image are known it > is possible to calculate the missing one. At this time, props is > long gone, and thus the question. Yes, props is gone, but - if not overridden - it's data will have made it into the style object associated with the image. I guess the calculation of the missing dimension could be done in Image::sizeRequestImpl() or Image::sizeAllocateImpl() but I haven't looked at it enough to know exactly. Cheers, Johannes

Jan. 9, 2009

CSS freeze

by jcid＠dillo.org

Hi, Current and former CSS protos freeze on this page: http://www.instantfundas.com/2007/12/5-opera-tricks-you-did-not-know-about.… -- Cheers Jorge.-

Jan. 9, 2009

IMG ratio

by jcid＠dillo.org

On Fri, Jan 09, 2009 at 06:04:09PM +0100, Hofmann Johannes wrote: > Hi Jorge, > > On Fri, Jan 09, 2009 at 02:00:20PM -0300, Jorge Arellano Cid wrote: > > Hi Johannes, > > > > Now that I have the image process mostly in my head, I'd like > > to hook correct image ratio scaling when only one of width/height > > is given. > > > > I see scaling done with the styleengine in a_Html_add_new_image > > but 'props' goes away when popping the tag. How do I handle this? > > > > Do I have to preserve props in the stack until I have the > > final data, or is there another way? Please explain. > > What about just setting the data that is available (width, height, > or both) and let the image do the rest? > It already handles the case where neither width nor height are > given. > So it should be possible to make it work with just width or > height too. Am I missing something? Yes, the problem is when only one of the dimenssions is given, bacause the other one is only known at image arrival time (much later). i.e. Only once the real dimenssions of the image are known it is possible to calculate the missing one. At this time, props is long gone, and thus the question. -- Cheers Jorge.-

Jan. 9, 2009

IMG ratio

by Johannes.Hofmann＠gmx.de

Hi Jorge, On Fri, Jan 09, 2009 at 02:00:20PM -0300, Jorge Arellano Cid wrote: > Hi Johannes, > > Now that I have the image process mostly in my head, I'd like > to hook correct image ratio scaling when only one of width/height > is given. > > I see scaling done with the styleengine in a_Html_add_new_image > but 'props' goes away when popping the tag. How do I handle this? > > Do I have to preserve props in the stack until I have the > final data, or is there another way? Please explain. What about just setting the data that is available (width, height, or both) and let the image do the rest? It already handles the case where neither width nor height are given. So it should be possible to make it work with just width or height too. Am I missing something? Cheers, Johannes

Jan. 9, 2009

RE: Dillo in Debian

by devidfil＠gmail.com

Hi, I'm the current dillo Debian maintainer. I know, dillo 2.0 isn't in Debian right now but it isn't caused by me, fltk2 package is missing in Debian so I can't upload the 2.0 version right now. However I've done the fltk2 package for Debian and if all is ok it will uploaded (and accepted) in Debian as soon as possible (but it won't be in Lenny). If you will switch dillo to fltk1.3 then the problem will be the same because actually Debian doesn't have the 1.3 version of fltk (only 1.1) so I will need to work on a new package for fltk1.3 and this will require time (there is no a good documentation about how to work on a static lib package). So please continue to use fltk2. I'm sorry for the delay. Devid Antonio Filoni

Jan. 9, 2009

IMG ratio

by jcid＠dillo.org

Hi Johannes, Now that I have the image process mostly in my head, I'd like to hook correct image ratio scaling when only one of width/height is given. I see scaling done with the styleengine in a_Html_add_new_image but 'props' goes away when popping the tag. How do I handle this? Do I have to preserve props in the stack until I have the final data, or is there another way? Please explain. -- Cheers Jorge.-

Jan. 9, 2009

one more crash

by Johannes.Hofmann＠gmx.de

On Thu, Jan 08, 2009 at 01:31:13PM -0300, Jorge Arellano Cid wrote: > On Thu, Jan 08, 2009 at 01:37:26PM +0100, Johannes Hofmann wrote: > > On Wed, Jan 07, 2009 at 07:54:51PM -0300, Jorge Arellano Cid wrote: > > > On Wed, Jan 07, 2009 at 09:59:22PM +0100, Johannes Hofmann wrote: > > > > Sorry, but I'm seeing one more crash with > > > > current css-prototype. > > > > > > Thanks for the politeness. > > > It's good to be testing. > > > > > > I've long forgotten the mess that image processing code became. > > > That's why I've taken the time to try to push code cleanups... > > > > > > > > > > Program terminated with signal 11, Segmentation fault. > > > > #0 0x08073f8e in dw::core::Layout::createImgbuf (this=0x3, type=dw::core::Imgbuf::RGB, width=140, height=80) > > > > at ../dw/layout.hh:241 > > > > 241 return platform->createImgbuf (type, width, height); > > > > (gdb) bt > > > > #0 0x08073f8e in dw::core::Layout::createImgbuf (this=0x3, type=dw::core::Imgbuf::RGB, width=140, height=80) > > > > at ../dw/layout.hh:241 > > > > #1 0x0805f016 in a_Dicache_set_parms (url=0x28fa2a00, version=1, Image=0x2952d040, width=140, height=80, > > > > type=DILLO_IMG_TYPE_RGB) at dicache.c:268 > > > > #2 0x08072f2e in Jpeg_write (jpeg=0x28f85000, Buf=0x28f97000, BufSize=8000) at jpeg.c:299 > > > > #3 0x08072df4 in Jpeg_callback (Op=0, Client=0x297b4e20) at jpeg.c:246 > > > > #4 0x0805f407 in a_Dicache_callback (Op=0, Client=0x297b4e20) at dicache.c:396 > > > > > > The layout belongs to the bw, so it shouldn't dissappear with > > > repush. It looks like Image is already freed. > > > > > > Let's see: > > > > > > jcid@d620:~/C/Dillo/d2/dillo-css-wc2/src$ srch a_Image_ref > > > image.cc:void a_Image_ref(DilloImage *Image) > > > image.hh:void a_Image_ref(DilloImage *Image); > > > gif.c: a_Image_ref(web->Image); > > > jpeg.c: a_Image_ref(web->Image); > > > png.c: a_Image_ref(web->Image); > > > jcid@d620:~/C/Dillo/d2/dillo-css-wc2/src$ srch a_Image_unref > > > html.cc: a_Image_unref(li->image); > > > image.cc:void a_Image_unref(DilloImage *Image) > > > image.cc: a_Image_unref(Image); > > > image.hh:void a_Image_unref(DilloImage *Image); > > > web.cc: a_Image_unref(web->Image); > > > > > > this looks like unbalanced ref/unref for the Image. > > > Gif/Jpeg/Png match with image.cc > > > The initial Ref=1 matches web.cc > > > html.cc matches ?? > > > > > > Please test with one or two extra a_Image_ref() > > > at dicache.c:269, or at your choice, on the proper place! :-) > > > > That didn't help. Backing out abdae95b1c9e however helps so far. > > OK, let's back it out and see if it becomes stable again. It's been very stable for me after the backout, so I pushed that to css-prototype. We can come back to this later, if someone figures out the root of the problem. Cheers, Johannes

Jan. 9, 2009

Dillo in Debian

by akemnade＠tzi.de

Hi, a status update: I just got a notice from the official dillo package maintainer that fltk2 will be added to debian. So I think the chances for dillo 2.0 to go into debian (not lenny) will be good. Greetings Andreas Kemnade

Jan. 8, 2009

Dillo in Debian

by jcid＠dillo.org

Hi Wookey, A post in dillo-dev made me aware of this thread: http://bugs.debian.org/cgi-bin/bugreport.cgi?archive=no&bug=510348 Thanks for your comment ;-) Some technical facts (all available from dillo.org) * dillo-0.8.x is unmaintained * dillo-2.x is the official stable branch * dillo-2.x uses FLTK2 not GTK2 as stated in the thread IMHO it'd be good to have dillo-0.8.x in Lenny, at least until dillo-2.x makes its way into Debian. We've been working on this branch for more than a year and it's way better than the former (details in the website). I'm aware of the problem distros have with including statically linked packages, and it looks like dillo-2.x will be left out of them until this issue is solved. Unfortunately FLTK-2.0 is stalled and an official release of it is nowhere near in the future. OTOH, an active set of developers is pushing FLTK-1.3.x very fast. This branch provides more or less the same FLTK-2.0 does. It's being actively developed, is less buggy and more stable, and will most probably be released soon (I'm yet to ask the team about dates). At some point in time we'll be migrating to FLTK-1.3.x (it has almost the same API), and hopefully then it'll be easier to include dillo in Debian. If you make progress with the certificate patch, please let us know. We're fully devoted to CSS now, and have no SSL expert in the team :( -- On a personal level, I'd love to have Dillo used in Debian as a help browser. This is, since a long time ago I've noticed applications come with almost no help (F1 button in the old days) and help drives you to an "About" window. But OTOH they have very good HTML docs (usually in usr/share/), that could provide for accurate context-sensitive help pages. The problem is they don't hook a web browser to the help button because a bloated app. that takes a long time to start, only to crawl the computer afterwards, is the last thing a developer hopes as her end user experience. There's the possibility of having a simple API to remote control the browser so the same instance is used. Dillo is fast, lean, and low on library dependencies. Any doubts, just don't hesitate to ask. -- Cheers Jorge.-

Jan. 8, 2009

one more crash

by jcid＠dillo.org

On Thu, Jan 08, 2009 at 01:37:26PM +0100, Johannes Hofmann wrote: > On Wed, Jan 07, 2009 at 07:54:51PM -0300, Jorge Arellano Cid wrote: > > On Wed, Jan 07, 2009 at 09:59:22PM +0100, Johannes Hofmann wrote: > > > Sorry, but I'm seeing one more crash with > > > current css-prototype. > > > > Thanks for the politeness. > > It's good to be testing. > > > > I've long forgotten the mess that image processing code became. > > That's why I've taken the time to try to push code cleanups... > > > > > > > Program terminated with signal 11, Segmentation fault. > > > #0 0x08073f8e in dw::core::Layout::createImgbuf (this=0x3, type=dw::core::Imgbuf::RGB, width=140, height=80) > > > at ../dw/layout.hh:241 > > > 241 return platform->createImgbuf (type, width, height); > > > (gdb) bt > > > #0 0x08073f8e in dw::core::Layout::createImgbuf (this=0x3, type=dw::core::Imgbuf::RGB, width=140, height=80) > > > at ../dw/layout.hh:241 > > > #1 0x0805f016 in a_Dicache_set_parms (url=0x28fa2a00, version=1, Image=0x2952d040, width=140, height=80, > > > type=DILLO_IMG_TYPE_RGB) at dicache.c:268 > > > #2 0x08072f2e in Jpeg_write (jpeg=0x28f85000, Buf=0x28f97000, BufSize=8000) at jpeg.c:299 > > > #3 0x08072df4 in Jpeg_callback (Op=0, Client=0x297b4e20) at jpeg.c:246 > > > #4 0x0805f407 in a_Dicache_callback (Op=0, Client=0x297b4e20) at dicache.c:396 > > > > The layout belongs to the bw, so it shouldn't dissappear with > > repush. It looks like Image is already freed. > > > > Let's see: > > > > jcid@d620:~/C/Dillo/d2/dillo-css-wc2/src$ srch a_Image_ref > > image.cc:void a_Image_ref(DilloImage *Image) > > image.hh:void a_Image_ref(DilloImage *Image); > > gif.c: a_Image_ref(web->Image); > > jpeg.c: a_Image_ref(web->Image); > > png.c: a_Image_ref(web->Image); > > jcid@d620:~/C/Dillo/d2/dillo-css-wc2/src$ srch a_Image_unref > > html.cc: a_Image_unref(li->image); > > image.cc:void a_Image_unref(DilloImage *Image) > > image.cc: a_Image_unref(Image); > > image.hh:void a_Image_unref(DilloImage *Image); > > web.cc: a_Image_unref(web->Image); > > > > this looks like unbalanced ref/unref for the Image. > > Gif/Jpeg/Png match with image.cc > > The initial Ref=1 matches web.cc > > html.cc matches ?? > > > > Please test with one or two extra a_Image_ref() > > at dicache.c:269, or at your choice, on the proper place! :-) > > That didn't help. Backing out abdae95b1c9e however helps so far. OK, let's back it out and see if it becomes stable again. -- Cheers Jorge.-

Jan. 8, 2009

dillo about to be dropped from debian

by r00t＠constancy.org

FYI: http://bugs.debian.org/cgi-bin/bugreport.cgi?archive=no&bug=510348 it seems that dillo is about to be dropped from debian, because * ssl lacks proper certificate verification * it still uses gtk1.2 (personally, the first never bothered me, and i consider the second a _feature_) Greetings, Thorben Thuermer

Jan. 8, 2009

one more crash

by Johannes.Hofmann＠gmx.de

On Wed, Jan 07, 2009 at 07:54:51PM -0300, Jorge Arellano Cid wrote: > On Wed, Jan 07, 2009 at 09:59:22PM +0100, Johannes Hofmann wrote: > > Sorry, but I'm seeing one more crash with > > current css-prototype. > > Thanks for the politeness. > It's good to be testing. > > I've long forgotten the mess that image processing code became. > That's why I've taken the time to try to push code cleanups... > > > > Program terminated with signal 11, Segmentation fault. > > #0 0x08073f8e in dw::core::Layout::createImgbuf (this=0x3, type=dw::core::Imgbuf::RGB, width=140, height=80) > > at ../dw/layout.hh:241 > > 241 return platform->createImgbuf (type, width, height); > > (gdb) bt > > #0 0x08073f8e in dw::core::Layout::createImgbuf (this=0x3, type=dw::core::Imgbuf::RGB, width=140, height=80) > > at ../dw/layout.hh:241 > > #1 0x0805f016 in a_Dicache_set_parms (url=0x28fa2a00, version=1, Image=0x2952d040, width=140, height=80, > > type=DILLO_IMG_TYPE_RGB) at dicache.c:268 > > #2 0x08072f2e in Jpeg_write (jpeg=0x28f85000, Buf=0x28f97000, BufSize=8000) at jpeg.c:299 > > #3 0x08072df4 in Jpeg_callback (Op=0, Client=0x297b4e20) at jpeg.c:246 > > #4 0x0805f407 in a_Dicache_callback (Op=0, Client=0x297b4e20) at dicache.c:396 > > The layout belongs to the bw, so it shouldn't dissappear with > repush. It looks like Image is already freed. > > Let's see: > > jcid@d620:~/C/Dillo/d2/dillo-css-wc2/src$ srch a_Image_ref > image.cc:void a_Image_ref(DilloImage *Image) > image.hh:void a_Image_ref(DilloImage *Image); > gif.c: a_Image_ref(web->Image); > jpeg.c: a_Image_ref(web->Image); > png.c: a_Image_ref(web->Image); > jcid@d620:~/C/Dillo/d2/dillo-css-wc2/src$ srch a_Image_unref > html.cc: a_Image_unref(li->image); > image.cc:void a_Image_unref(DilloImage *Image) > image.cc: a_Image_unref(Image); > image.hh:void a_Image_unref(DilloImage *Image); > web.cc: a_Image_unref(web->Image); > > this looks like unbalanced ref/unref for the Image. > Gif/Jpeg/Png match with image.cc > The initial Ref=1 matches web.cc > html.cc matches ?? > > Please test with one or two extra a_Image_ref() > at dicache.c:269, or at your choice, on the proper place! :-) That didn't help. Backing out abdae95b1c9e however helps so far. Cheers, Johannes

Jan. 8, 2009

one more crash

by jcid＠dillo.org

On Wed, Jan 07, 2009 at 09:59:22PM +0100, Johannes Hofmann wrote: > Sorry, but I'm seeing one more crash with > current css-prototype. Thanks for the politeness. It's good to be testing. I've long forgotten the mess that image processing code became. That's why I've taken the time to try to push code cleanups... > Program terminated with signal 11, Segmentation fault. > #0 0x08073f8e in dw::core::Layout::createImgbuf (this=0x3, type=dw::core::Imgbuf::RGB, width=140, height=80) > at ../dw/layout.hh:241 > 241 return platform->createImgbuf (type, width, height); > (gdb) bt > #0 0x08073f8e in dw::core::Layout::createImgbuf (this=0x3, type=dw::core::Imgbuf::RGB, width=140, height=80) > at ../dw/layout.hh:241 > #1 0x0805f016 in a_Dicache_set_parms (url=0x28fa2a00, version=1, Image=0x2952d040, width=140, height=80, > type=DILLO_IMG_TYPE_RGB) at dicache.c:268 > #2 0x08072f2e in Jpeg_write (jpeg=0x28f85000, Buf=0x28f97000, BufSize=8000) at jpeg.c:299 > #3 0x08072df4 in Jpeg_callback (Op=0, Client=0x297b4e20) at jpeg.c:246 > #4 0x0805f407 in a_Dicache_callback (Op=0, Client=0x297b4e20) at dicache.c:396 The layout belongs to the bw, so it shouldn't dissappear with repush. It looks like Image is already freed. Let's see: jcid@d620:~/C/Dillo/d2/dillo-css-wc2/src$ srch a_Image_ref image.cc:void a_Image_ref(DilloImage *Image) image.hh:void a_Image_ref(DilloImage *Image); gif.c: a_Image_ref(web->Image); jpeg.c: a_Image_ref(web->Image); png.c: a_Image_ref(web->Image); jcid@d620:~/C/Dillo/d2/dillo-css-wc2/src$ srch a_Image_unref html.cc: a_Image_unref(li->image); image.cc:void a_Image_unref(DilloImage *Image) image.cc: a_Image_unref(Image); image.hh:void a_Image_unref(DilloImage *Image); web.cc: a_Image_unref(web->Image); this looks like unbalanced ref/unref for the Image. Gif/Jpeg/Png match with image.cc The initial Ref=1 matches web.cc html.cc matches ?? Please test with one or two extra a_Image_ref() at dicache.c:269, or at your choice, on the proper place! :-) -- Cheers Jorge.-

Jan. 7, 2009

one more crash

by jcid＠dillo.org

On Wed, Jan 07, 2009 at 09:59:22PM +0100, Johannes Hofmann wrote: > Sorry, but I'm seeing one more crash with > current css-prototype. I think it has to do with abdae95b1c9e. > I get it often - but not always e.g. on www.spiegel.de. > Somehow layout is not set properly in the Image widget. > Below is the stack. Hmm, I haven't been able to reproduce it yet... Do you mean it never crashes without abdae95b1c9e? -- Cheers Jorge.-

Jan. 7, 2009

one more crash

by Johannes.Hofmann＠gmx.de

Sorry, but I'm seeing one more crash with current css-prototype. I think it has to do with abdae95b1c9e. I get it often - but not always e.g. on www.spiegel.de. Somehow layout is not set properly in the Image widget. Below is the stack. Cheers, Johannes Program terminated with signal 11, Segmentation fault. #0 0x08073f8e in dw::core::Layout::createImgbuf (this=0x3, type=dw::core::Imgbuf::RGB, width=140, height=80) at ../dw/layout.hh:241 241 return platform->createImgbuf (type, width, height); (gdb) bt #0 0x08073f8e in dw::core::Layout::createImgbuf (this=0x3, type=dw::core::Imgbuf::RGB, width=140, height=80) at ../dw/layout.hh:241 #1 0x0805f016 in a_Dicache_set_parms (url=0x28fa2a00, version=1, Image=0x2952d040, width=140, height=80, type=DILLO_IMG_TYPE_RGB) at dicache.c:268 #2 0x08072f2e in Jpeg_write (jpeg=0x28f85000, Buf=0x28f97000, BufSize=8000) at jpeg.c:299 #3 0x08072df4 in Jpeg_callback (Op=0, Client=0x297b4e20) at jpeg.c:246 #4 0x0805f407 in a_Dicache_callback (Op=0, Client=0x297b4e20) at dicache.c:396 #5 0x0805de7a in Cache_process_queue (entry=0x2952d080) at cache.c:1134 #6 0x0805d624 in a_Cache_process_dbuf (Op=0, buf=0x2955d000 "Z121\034\002\n", buf_size=7930, Url=0x2952d200) at cache.c:856 #7 0x08060af9 in a_Capi_ccc (Op=2, Branch=2, Dir=1, Info=0x294d6b40, Data1=0x286bb5b0, Data2=0x80fb16c) at capi.c:596 #8 0x08059f38 in a_Chain_fcb (Op=2, Info=0x294d6740, Data1=0x286bb5b0, Data2=0x80fb16c) at chain.c:112 #9 0x080794d2 in Dpi_parse_token (conn=0x2952d240) at dpi.c:219 #10 0x080797b2 in Dpi_process_dbuf (Op=0, Data1=0x286bbca0, conn=0x2952d240) at dpi.c:278 #11 0x0807a545 in a_Dpi_ccc (Op=2, Branch=2, Dir=1, Info=0x294d6740, Data1=0x286bbca0, Data2=0x0) at dpi.c:668 #12 0x08059f38 in a_Chain_fcb (Op=2, Info=0x294d6fa0, Data1=0x286bbca0, Data2=0x0) at chain.c:112 #13 0x0807b197 in a_IO_ccc (Op=2, Branch=2, Dir=1, Info=0x294d6fa0, Data1=0x294d6560, Data2=0x0) at IO.c:414 #14 0x0807abdd in IO_read (io=0x294d6560) at IO.c:201 #15 0x0807acf7 in IO_callback (io=0x294d6560) at IO.c:266 #16 0x0807ad80 in IO_fd_read_cb (fd=64, data=0x8e) at IO.c:287 #17 0x080c8c99 in fltk::wait () #18 0x080c8e49 in fltk::run () #19 0x0804f19c in main (argc=1, argv=Cannot access memory at address 0x3c ) at dillo.cc:334 (gdb)

Jan. 7, 2009

Strange valgrind complain

by jcid＠dillo.org

On Wed, Jan 07, 2009 at 09:07:19PM +0100, Johannes Hofmann wrote: > Hi Jorge, > > On Wed, Jan 07, 2009 at 03:56:55PM -0300, Jorge Arellano Cid wrote: > > On Wed, Jan 07, 2009 at 01:19:38PM -0300, Jorge Arellano Cid wrote: > > > On Tue, Jan 06, 2009 at 01:37:10PM +0100, Johannes Hofmann wrote: > > > > On Mon, Jan 05, 2009 at 02:51:03PM -0300, Jorge Arellano Cid wrote: > > > > > Hi there, > > > > > > > > > > With Johannes, we're trying to find out why valgrind complains > > > > > on the newest CSS branch with a certain URL: > > > > > > > > > > $ valgrind --tool=memcheck --leak-check=yes \ > > > > > ./dillo http://selenic.com/pipermail/mercurial/ &>out > > > > > > > > > > $ less out > > > > > > > > > > There're several "Invalid read of size 1". > > > > > > > > > > It doesn't complain with a local file, nor after repush. It > > > > > seems the timing is important, and maybe the decoder... > > > > > > > > The problem seems to be that at cache.c:1149 data is assigned > > > > entry->UTF8Data, then during Html_callback() > > > > a_Cache_set_content_type() get's called which since revision > > > > 48029b8a5478 frees entry->UTF8Data. > > > > That also explains why the earlier read of start went ok. > > > > > > > > I don't really now how to fix that though... > > > > > > Good news: now I have a big cleanup patch that gets rid of > > > every valgrind complain on that page! > > > > > > jcid@d620:~/C/Dillo/d2/dillo-css-wc2/src$ diffstat try2.diff > > > cache.c | 157 ++++++++++++++++++++++++++++------------------------------------ > > > cache.h | 3 - > > > capi.c | 5 -- > > > capi.h | 3 - > > > html.cc | 22 ++++++-- > > > 5 files changed, 89 insertions(+), 101 deletions(-) > > > > > > Let me polish it a bit more before you review and test it. > > > > Here go the patches attached. For test, review & commments. > > Please apply styleengine-init-values first. > > This patch fixes these crashes for me. > I think we should reintroduce the force parameter given corvid's > comment. Yes, sure. It was stripped because it wasn't used. Good to know it works! -- Cheers Jorge.-

Jan. 7, 2009

Strange valgrind complain

by Johannes.Hofmann＠gmx.de

Hi Jorge, On Wed, Jan 07, 2009 at 03:56:55PM -0300, Jorge Arellano Cid wrote: > On Wed, Jan 07, 2009 at 01:19:38PM -0300, Jorge Arellano Cid wrote: > > On Tue, Jan 06, 2009 at 01:37:10PM +0100, Johannes Hofmann wrote: > > > On Mon, Jan 05, 2009 at 02:51:03PM -0300, Jorge Arellano Cid wrote: > > > > Hi there, > > > > > > > > With Johannes, we're trying to find out why valgrind complains > > > > on the newest CSS branch with a certain URL: > > > > > > > > $ valgrind --tool=memcheck --leak-check=yes \ > > > > ./dillo http://selenic.com/pipermail/mercurial/ &>out > > > > > > > > $ less out > > > > > > > > There're several "Invalid read of size 1". > > > > > > > > It doesn't complain with a local file, nor after repush. It > > > > seems the timing is important, and maybe the decoder... > > > > > > The problem seems to be that at cache.c:1149 data is assigned > > > entry->UTF8Data, then during Html_callback() > > > a_Cache_set_content_type() get's called which since revision > > > 48029b8a5478 frees entry->UTF8Data. > > > That also explains why the earlier read of start went ok. > > > > > > I don't really now how to fix that though... > > > > Good news: now I have a big cleanup patch that gets rid of > > every valgrind complain on that page! > > > > jcid@d620:~/C/Dillo/d2/dillo-css-wc2/src$ diffstat try2.diff > > cache.c | 157 ++++++++++++++++++++++++++++------------------------------------ > > cache.h | 3 - > > capi.c | 5 -- > > capi.h | 3 - > > html.cc | 22 ++++++-- > > 5 files changed, 89 insertions(+), 101 deletions(-) > > > > Let me polish it a bit more before you review and test it. > > Here go the patches attached. For test, review & commments. > Please apply styleengine-init-values first. This patch fixes these crashes for me. I think we should reintroduce the force parameter given corvid's comment. Thanks, Johannes

Jan. 7, 2009

Strange valgrind complain

by corvid＠lavabit.com

The purpose of "force" was for users setting content type (or at least character encoding) through a dialog or menu or whatever.

Jan. 7, 2009

Strange valgrind complain

by jcid＠dillo.org

On Wed, Jan 07, 2009 at 01:19:38PM -0300, Jorge Arellano Cid wrote: > On Tue, Jan 06, 2009 at 01:37:10PM +0100, Johannes Hofmann wrote: > > On Mon, Jan 05, 2009 at 02:51:03PM -0300, Jorge Arellano Cid wrote: > > > Hi there, > > > > > > With Johannes, we're trying to find out why valgrind complains > > > on the newest CSS branch with a certain URL: > > > > > > $ valgrind --tool=memcheck --leak-check=yes \ > > > ./dillo http://selenic.com/pipermail/mercurial/ &>out > > > > > > $ less out > > > > > > There're several "Invalid read of size 1". > > > > > > It doesn't complain with a local file, nor after repush. It > > > seems the timing is important, and maybe the decoder... > > > > The problem seems to be that at cache.c:1149 data is assigned > > entry->UTF8Data, then during Html_callback() > > a_Cache_set_content_type() get's called which since revision > > 48029b8a5478 frees entry->UTF8Data. > > That also explains why the earlier read of start went ok. > > > > I don't really now how to fix that though... > > Good news: now I have a big cleanup patch that gets rid of > every valgrind complain on that page! > > jcid@d620:~/C/Dillo/d2/dillo-css-wc2/src$ diffstat try2.diff > cache.c | 157 ++++++++++++++++++++++++++++------------------------------------ > cache.h | 3 - > capi.c | 5 -- > capi.h | 3 - > html.cc | 22 ++++++-- > 5 files changed, 89 insertions(+), 101 deletions(-) > > Let me polish it a bit more before you review and test it. Here go the patches attached. For test, review & commments. Please apply styleengine-init-values first. -- Cheers Jorge.-

Jan. 7, 2009

Strange valgrind complain

by jcid＠dillo.org

On Tue, Jan 06, 2009 at 01:37:10PM +0100, Johannes Hofmann wrote: > On Mon, Jan 05, 2009 at 02:51:03PM -0300, Jorge Arellano Cid wrote: > > Hi there, > > > > With Johannes, we're trying to find out why valgrind complains > > on the newest CSS branch with a certain URL: > > > > $ valgrind --tool=memcheck --leak-check=yes \ > > ./dillo http://selenic.com/pipermail/mercurial/ &>out > > > > $ less out > > > > There're several "Invalid read of size 1". > > > > It doesn't complain with a local file, nor after repush. It > > seems the timing is important, and maybe the decoder... > > The problem seems to be that at cache.c:1149 data is assigned > entry->UTF8Data, then during Html_callback() > a_Cache_set_content_type() get's called which since revision > 48029b8a5478 frees entry->UTF8Data. > That also explains why the earlier read of start went ok. > > I don't really now how to fix that though... Good news: now I have a big cleanup patch that gets rid of every valgrind complain on that page! jcid@d620:~/C/Dillo/d2/dillo-css-wc2/src$ diffstat try2.diff cache.c | 157 ++++++++++++++++++++++++++++------------------------------------ cache.h | 3 - capi.c | 5 -- capi.h | 3 - html.cc | 22 ++++++-- 5 files changed, 89 insertions(+), 101 deletions(-) Let me polish it a bit more before you review and test it. -- Cheers Jorge.-

Jan. 7, 2009

default search engine

by corvid＠lavabit.com

I was thinking about the news that was going around last month about yahoo making its data retention period shorter (with exceptions to let them get away with whatever they want, but that's par for the course). e.g. http://www.theregister.co.uk/2008/12/17/yahoo_anonymization_explained/ It seems like a good idea to set the search_url default to whoever is the...let's say "least bad" in terms of privacy at a given time.

Jan. 7, 2009

Strange valgrind complain

by corvid＠lavabit.com

Jorge wrote: > On Tue, Jan 06, 2009 at 01:37:10PM +0100, Johannes Hofmann wrote: > > On Mon, Jan 05, 2009 at 02:51:03PM -0300, Jorge Arellano Cid wrote: > > > Hi there, > > > > > > With Johannes, we're trying to find out why valgrind complains > > > on the newest CSS branch with a certain URL: > > > > > > $ valgrind --tool=memcheck --leak-check=yes \ > > > ./dillo http://selenic.com/pipermail/mercurial/ &>out > > > > > > $ less out > > > > > > There're several "Invalid read of size 1". > > > > > > It doesn't complain with a local file, nor after repush. It > > > seems the timing is important, and maybe the decoder... > > > > The problem seems to be that at cache.c:1149 data is assigned > > entry->UTF8Data, then during Html_callback() > > a_Cache_set_content_type() get's called which since revision > > 48029b8a5478 frees entry->UTF8Data. > > That also explains why the earlier read of start went ok. > > Good catch! > > I made those changes (48029b8a5478) not knowing exactly > how the whole process goes. What I don't understand now is: > > * The Hg CSS repo from freehg (tip: f9099e82be08) has the problem, > but it doesn't have the "Free UTF8Data" patch (48029b8a5478). > > Anyway, it seems the bug is related to setting the new decoder. Now that I see 48029b8a5478, I'm curious about it: Is there an unref missing somewhere that caused UTF8Data to need to be freed in those cases?

Jan. 6, 2009

Re: Added a right-click menu to the form submit button (allows to show hiddens)

by Johannes.Hofmann＠gmx.de

this is cool! Johannes

Jan. 6, 2009

Strange valgrind complain

by corvid＠lavabit.com

Jorge wrote: > As a matter of fact, the main branch of dillo doesn't show > the same problem, but it *has* a problem: > > Nav_open_url: new url='http://selenic.com/pipermail/mercurial/' > Dns_server [0]: selenic.com is 66.93.16.53 > Connecting to 66.93.16.53 > ==29247== Invalid read of size 4 > ==29247== at 0x8061926: Cache_process_queue (cache.c:1151) > ==29247== by 0x8061232: a_Cache_process_dbuf (cache.c:900) > ==29247== by 0x80645C8: a_Capi_ccc (capi.c:597) > ==29247== by 0x805D30B: a_Chain_fcb (chain.c:112) > ==29247== by 0x8081760: Dpi_parse_token (dpi.c:219) > ==29247== by 0x80819E8: Dpi_process_dbuf (dpi.c:278) > ==29247== by 0x808290A: a_Dpi_ccc (dpi.c:668) > ==29247== by 0x805D30B: a_Chain_fcb (chain.c:112) > ==29247== by 0x8083668: a_IO_ccc (IO.c:414) > ==29247== by 0x8083041: IO_read (IO.c:201) > ==29247== by 0x808319D: IO_callback (IO.c:266) > ==29247== by 0x808321E: IO_fd_read_cb (IO.c:287) > ==29247== Address 0x480644c is 4 bytes inside a block of size 12 free'd > ==29247== at 0x4024B4A: free (vg_replace_malloc.c:323) > ==29247== by 0x807E466: dFree (dlib.c:60) > ==29247== by 0x807EAA4: dStr_free (dlib.c:293) > ==29247== by 0x8060381: a_Cache_set_content_type (cache.c:513) > ==29247== by 0x8063F13: a_Capi_set_content_type (capi.c:427) > ==29247== by 0x806DF45: _ZL18Html_tag_open_metaP9DilloHtmlPKci (html.cc:3020) > ==29247== by 0x806D2E6: _ZL16Html_process_tagP9DilloHtmlPci (html.cc:3538) > ==29247== by 0x806D970: _ZL14Html_write_rawP9DilloHtmlPcii (html.cc:3876) > ==29247== by 0x806DAEC: DilloHtml::write(char*, int, int) (html.cc:667) > ==29247== by 0x806DB7F: _ZL13Html_callbackiP12_CacheClient (html.cc:3767) > ==29247== by 0x8061915: Cache_process_queue (cache.c:1149) > ==29247== by 0x8061232: a_Cache_process_dbuf (cache.c:900) > Nav_open_url: new url='http://selenic.com/pipermail/mercurial/' > a_Nav_expect_done: repush! If you give the a_UIcmd_set_page_prog() Cache_data(entry)->len, does the problem go away?

Jan. 6, 2009

Strange valgrind complain

by jcid＠dillo.org

On Tue, Jan 06, 2009 at 01:37:10PM +0100, Johannes Hofmann wrote: > On Mon, Jan 05, 2009 at 02:51:03PM -0300, Jorge Arellano Cid wrote: > > Hi there, > > > > With Johannes, we're trying to find out why valgrind complains > > on the newest CSS branch with a certain URL: > > > > $ valgrind --tool=memcheck --leak-check=yes \ > > ./dillo http://selenic.com/pipermail/mercurial/ &>out > > > > $ less out > > > > There're several "Invalid read of size 1". > > > > It doesn't complain with a local file, nor after repush. It > > seems the timing is important, and maybe the decoder... > > The problem seems to be that at cache.c:1149 data is assigned > entry->UTF8Data, then during Html_callback() > a_Cache_set_content_type() get's called which since revision > 48029b8a5478 frees entry->UTF8Data. > That also explains why the earlier read of start went ok. Good catch! I made those changes (48029b8a5478) not knowing exactly how the whole process goes. What I don't understand now is: * The Hg CSS repo from freehg (tip: f9099e82be08) has the problem, but it doesn't have the "Free UTF8Data" patch (48029b8a5478). Anyway, it seems the bug is related to setting the new decoder. As a matter of fact, the main branch of dillo doesn't show the same problem, but it *has* a problem: Nav_open_url: new url='http://selenic.com/pipermail/mercurial/' Dns_server [0]: selenic.com is 66.93.16.53 Connecting to 66.93.16.53 ==29247== Invalid read of size 4 ==29247== at 0x8061926: Cache_process_queue (cache.c:1151) ==29247== by 0x8061232: a_Cache_process_dbuf (cache.c:900) ==29247== by 0x80645C8: a_Capi_ccc (capi.c:597) ==29247== by 0x805D30B: a_Chain_fcb (chain.c:112) ==29247== by 0x8081760: Dpi_parse_token (dpi.c:219) ==29247== by 0x80819E8: Dpi_process_dbuf (dpi.c:278) ==29247== by 0x808290A: a_Dpi_ccc (dpi.c:668) ==29247== by 0x805D30B: a_Chain_fcb (chain.c:112) ==29247== by 0x8083668: a_IO_ccc (IO.c:414) ==29247== by 0x8083041: IO_read (IO.c:201) ==29247== by 0x808319D: IO_callback (IO.c:266) ==29247== by 0x808321E: IO_fd_read_cb (IO.c:287) ==29247== Address 0x480644c is 4 bytes inside a block of size 12 free'd ==29247== at 0x4024B4A: free (vg_replace_malloc.c:323) ==29247== by 0x807E466: dFree (dlib.c:60) ==29247== by 0x807EAA4: dStr_free (dlib.c:293) ==29247== by 0x8060381: a_Cache_set_content_type (cache.c:513) ==29247== by 0x8063F13: a_Capi_set_content_type (capi.c:427) ==29247== by 0x806DF45: _ZL18Html_tag_open_metaP9DilloHtmlPKci (html.cc:3020) ==29247== by 0x806D2E6: _ZL16Html_process_tagP9DilloHtmlPci (html.cc:3538) ==29247== by 0x806D970: _ZL14Html_write_rawP9DilloHtmlPcii (html.cc:3876) ==29247== by 0x806DAEC: DilloHtml::write(char*, int, int) (html.cc:667) ==29247== by 0x806DB7F: _ZL13Html_callbackiP12_CacheClient (html.cc:3767) ==29247== by 0x8061915: Cache_process_queue (cache.c:1149) ==29247== by 0x8061232: a_Cache_process_dbuf (cache.c:900) Nav_open_url: new url='http://selenic.com/pipermail/mercurial/' a_Nav_expect_done: repush! Well, so far I managed to get rid of the complain in my local CSS tree, by changing the way the decoder is engaged, but I want to understand it better before sharing it. There's also a segfault I have to chase... > I don't really now how to fix that though... I assume backing out 48029b8a5478 doesn't make it... -- Cheers Jorge.- ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________

Jan. 6, 2009

Strange valgrind complain

by Johannes.Hofmann＠gmx.de

On Mon, Jan 05, 2009 at 02:51:03PM -0300, Jorge Arellano Cid wrote: > Hi there, > > With Johannes, we're trying to find out why valgrind complains > on the newest CSS branch with a certain URL: > > $ valgrind --tool=memcheck --leak-check=yes \ > ./dillo http://selenic.com/pipermail/mercurial/ &>out > > $ less out > > There're several "Invalid read of size 1". > > It doesn't complain with a local file, nor after repush. It > seems the timing is important, and maybe the decoder... The problem seems to be that at cache.c:1149 data is assigned entry->UTF8Data, then during Html_callback() a_Cache_set_content_type() get's called which since revision 48029b8a5478 frees entry->UTF8Data. That also explains why the earlier read of start went ok. I don't really now how to fix that though... Cheers, Johannes

Jan. 6, 2009

Strange valgrind complain

by jcid＠dillo.org

On Mon, Jan 05, 2009 at 07:26:12PM +0000, corvid wrote: > Jorge wrote: > > With Johannes, we're trying to find out why valgrind complains > > on the newest CSS branch with a certain URL: > > > > $ valgrind --tool=memcheck --leak-check=yes \ > > ./dillo http://selenic.com/pipermail/mercurial/ &>out > > > > $ less out > > > > There're several "Invalid read of size 1". > > > > It doesn't complain with a local file, nor after repush. It > > seems the timing is important, and maybe the decoder... > > > > Please help us, it's important to stabilize this branch before > > merging into main. > > And it doesn't happen with main? Yes, main works OK. -- Cheers Jorge.- ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________

Jan. 5, 2009

Strange valgrind complain

by corvid＠lavabit.com

Jorge wrote: > With Johannes, we're trying to find out why valgrind complains > on the newest CSS branch with a certain URL: > > $ valgrind --tool=memcheck --leak-check=yes \ > ./dillo http://selenic.com/pipermail/mercurial/ &>out > > $ less out > > There're several "Invalid read of size 1". > > It doesn't complain with a local file, nor after repush. It > seems the timing is important, and maybe the decoder... > > Please help us, it's important to stabilize this branch before > merging into main. And it doesn't happen with main?

Jan. 5, 2009

Strange valgrind complain

by jcid＠dillo.org

Hi there, With Johannes, we're trying to find out why valgrind complains on the newest CSS branch with a certain URL: $ valgrind --tool=memcheck --leak-check=yes \ ./dillo http://selenic.com/pipermail/mercurial/ &>out $ less out There're several "Invalid read of size 1". It doesn't complain with a local file, nor after repush. It seems the timing is important, and maybe the decoder... Please help us, it's important to stabilize this branch before merging into main. -- BTW, after we merge CSS into the main branch, it seems like floating objects will be the highest priority. Dillo rendering would improve a lot by using both! -- Cheers Jorge.- ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________

Jan. 5, 2009

Re: We have competition!

by sandshrew＠gmail.com

> http://www.freesoftwaremagazine.com/columns/h3v_web_browser_it_dillo_killer > > What a headline! I was testing hv3 for quite awhile when the project was still active and would like to point out some stupid mistakes made in the article: 1) it's NOT h3v or h3w - it's hv3 (Html Viewer 3)! 2) it's written primarily in TCL, not in C; 3) both dillo and hv3 do support SSL (hv3 requires TLS for that and TLS is incorporated in the startkits, provided in the official website) 4) in both articles it is said "developerS". Actually 99% of the code (some parts were borrowed from another TCL browser called "BrowseX"(http://wiki.tcl.tk/2136)) was written by one genius named Daniel Kennedy. 5) Dillo actually launches a lot faster than hv3, but hv3 renders pages really fast too. And few comments from my side... Hv3 has a lot better bookmark manager when compared to dillo. Furthermore, in addition to bookmark, setting and cookie saving it can save history and has autocompletion. It has highly advanced css support - it even passes ACID2 test (something what microsoft with their internet exploiter was trying achieve for quite awhile...). As it's primarily written in TCL, it's platform independent, doesn't require any external dependencies, can run straight from USB flash memory (it can also save its db there too). Unlike dillo, hv3 also supports frames. Finally, even it's considered to be alpha state software, at least when javascript support is disabled, it is pretty stable. If you'd like to know something more about hv3, I think, you should still be able to contact Daniel - danielk1977 AT gmail DOT com. BTW, I don't know the current status of SEE project, I just know that the last time I checked (half a year ago or so) it had really many problems. SEE: http://www.adaptive-enterprises.com.au/~d/software/see/ -- Brain: an apparatus with which we think we think. - A. Bierce

Jan. 4, 2009

Re: We have competition!

by onepoint＠starurchin.org

On Sat, Jan 03, 2009 at 07:05:39PM -0300, Jorge Arellano Cid wrote: > http://www.freesoftwaremagazine.com/columns/h3v_web_browser_it_dillo_killer > > What a headline! Yes, it's flattering that Dillo is considered to be the one to beat! > but the comments there give a different idea... Indeed, it looks as thought H3w and SEE are dead projects. That's a shame. Jeremy Henty

Jan. 4, 2009

Re: We have competition!

by jcid＠dillo.org

On Sat, Jan 03, 2009 at 09:14:05PM +0000, Jeremy Henty wrote: > On Sat, Jan 03, 2009 at 01:48:42PM +0200, Tomas R wrote: > > > Sorry to disappoint you, but hv3 is officially unmaintained already > > for almost a year and SEE has LOTS of problems... > > That *is* disappointing. It would be good to have a simple, > maintained JavaScript engine to study. It's odd the article didn't > mention any of this; it made it sound as though both projects were > active. > > Thanks for the update, Sometime ago I read this: http://www.freesoftwaremagazine.com/columns/h3v_web_browser_it_dillo_killer What a headline! but the comments there give a different idea... -- Cheers Jorge.- ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________

Jan. 3, 2009

Re: We have competition!

by onepoint＠starurchin.org

On Sat, Jan 03, 2009 at 01:48:42PM +0200, Tomas R wrote: > Sorry to disappoint you, but hv3 is officially unmaintained already > for almost a year and SEE has LOTS of problems... That *is* disappointing. It would be good to have a simple, maintained JavaScript engine to study. It's odd the article didn't mention any of this; it made it sound as though both projects were active. Thanks for the update, Jeremy Henty

Jan. 3, 2009

open new tab

by Hole.destructor＠gmx.de

Hi Dillo team, I have a simple question concerning the new tabbed browsing feature in Dillo2: The only way to open a link in a new tab seems to be a click with the middle mouse button. Since there are some people, who don't have a mouse (for example on Laptops, MacBooks etc.) and therefore must find this middle-click very unhandy, I was wondering whether it is possible to open a link within a new tab by using another method, for example the common <CTRL>-<left mous button> combination? If this is currently not possible, could you introduce it in a future version of dillo? (I think the inofficial Dillo version, which is currently shipped with Debian/Ubuntu knows this alternative combination.) Many thanks in advance for your help, Alexander

Jan. 3, 2009

Re: We have competition!

by sandshrew＠gmail.com

Sorry to disappoint you, but hv3 is officially unmaintained already for almost a year and SEE has LOTS of problems... -- Brain: an apparatus with which we think we think. - A. Bierce

Jan. 3, 2009

[patch]: use the dlib dStr* functions everywhere

by jcid＠dillo.org

On Fri, Jan 02, 2009 at 10:05:23PM +0000, Jeremy Henty wrote: > > This is a small consistency cleanup. Most of the Dillo source uses > dlib's dStr* functions for string operations. This patch fixes the > few places that do not. Good! Committed. BTW, you already have a patch entry in the Changelog. Please reuse it instead of adding a new one. -- Cheers Jorge.- ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________

Jan. 2, 2009

[patch]: use the dlib dStr* functions everywhere

by onepoint＠starurchin.org

This is a small consistency cleanup. Most of the Dillo source uses dlib's dStr* functions for string operations. This patch fixes the few places that do not. Jeremy Henty

Jan. 2, 2009

Best wishes for 2009!

by Johannes.Hofmann＠gmx.de

On Fri, Jan 02, 2009 at 03:34:13PM -0300, Jorge Arellano Cid wrote: > Hi there, > > Please receive my best wishes for this new year 2009! > > We've come a long way since dillo restarted, and progress > in several fronts has improved the browser a lot. > > Thanks to you all for the good work!!! > > > > Amyway, it looks like 2009 will be an exciting year for Dillo. > > In the hope of it coming true, I just sent Johannes an image > handling patch series for CSS to work properly with stylesheet > loading. Just wait for his signal after he commits to download > and enjoy the new code. > > Note: I'm still working on it, but it's quite usable "as is". I've just pushed Jorge's work to the css-prototype repository. It works fine for me so far :-) Happy new year, Johannes

Jan. 2, 2009

[patch]: fix dialog callback

by jcid＠dillo.org

On Sun, Dec 28, 2008 at 07:56:55PM +0000, Jeremy Henty wrote: > > Dialog_user_password_cb() should not use VOIDP2INT, because the (void > *) argument was originally an (int *), not an int or long. This bug > makes the dialog always call its callback even when the user presses > the Cancel button. As a result it is futile to cancel the Basic > Authentication dialog: the page reloads and the dialog pops up again. Ooops! Committed with minor modifications and a fix for some unrelated missing INT2VOIDP. -- Cheers Jorge.- ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________

Jan. 2, 2009