- Dillo-dev - lists.mailman3.com

patch: a_Capi_get_flags and following redirection

by corvid＠lavabit.com

When an image on a page wouldn't load due to redirection, I would isolate the image, and often notice that message about Content-Length not matching message body. The reason is in a_Capi_open_url(), where reload is set by checking a_Capi_get_flags() for CAPI_IsCached. It follows the redirection, determines the Location URL isn't cached, and makes another HTTP request for the original URL. The cache entry data for that URL ends up containing the body from the first request with the header and body from the second request appended to it. Ah, but sometimes we want to follow redirection for get_flags. - the download check in capi - the load_stylesheet check in html.cc, assuming that we want to make that work with redirection at some point. - load_now for images in html.cc and the rest don't really matter too terribly much either way. So, unable to think of anything nice or clever, I added an argument to get_flags specifying whether redirection should be followed.

April 23, 2009

towards a dillo-2.1 release

by jcid＠dillo.org

Hi Devid, On Wed, Apr 22, 2009 at 03:05:37PM +0200, Devid Antonio Filoni wrote: > Hi, > I can work on point 4. Good! Although packages are to be provided after the final release is ready, you should start testing the packages now. Just put them somewhere (based on current repo) and let the list know for people to check they work OK. If you don't have a server to upload them, we can host them in dillo.org/test. > > Devid Antonio Filoni > > On Mon, Apr 20, 2009 at 11:10 PM, Jorge Arellano Cid <jcid(a)dillo.org> wrote: > > Hi there, > > > > ?It'd ?be ?very good if we can complete these points for the 2.1 > > release. Listed in no particular order: > > > > ?1.- Dw documentation: online and as tarball. > > ? ? ?We ?have ?good docs. but to generate them there's a need to > > ? ? ?have: doxygen, graphviz, dot, latex and friends. That's why > > ? ? ?having it online and as a tarball is a good idea. > > ?2.- Mapcity segfault > > ? ? ?In www.mapcity.cl playing with the "Tipo Calle" while the > > ? ? ?page ?is ?loading ?makes dillo segfault. If "Remote CSS" is > > ? ? ?disabled, it doesn't happen (also OK in dillo-2.0). > > ?3.- New web site design > > ? ? ?We have a new banner and after finding a good color palette > > ? ? ?it may be ready to renew the site before 2.1 is announced. > > ?4.- Debian/Ubuntu packages (after 2.1 final is ready) > > ?5.- Update "8 years" page (it's nine) > > ? ? ?Yes, I should have done it already... > > ?6.- Configurable key bindings. > > ? ? ?I'm reviewing this with Tim. Hopefully it will make it into > > ? ? ?the 2.1 release. > > ?7.- Memory usage statistics > > ? ? ?Scott has posted some data on this, in another thread. I'll > > ? ? ?answer there. -- Cheers Jorge.-

April 22, 2009

towards a dillo-2.1 release

by devidfil＠gmail.com

Hi, I can work on point 4. Devid Antonio Filoni On Mon, Apr 20, 2009 at 11:10 PM, Jorge Arellano Cid <jcid(a)dillo.org> wrote: > Hi there, > > ?It'd ?be ?very good if we can complete these points for the 2.1 > release. Listed in no particular order: > > ?1.- Dw documentation: online and as tarball. > ? ? ?We ?have ?good docs. but to generate them there's a need to > ? ? ?have: doxygen, graphviz, dot, latex and friends. That's why > ? ? ?having it online and as a tarball is a good idea. > ?2.- Mapcity segfault > ? ? ?In www.mapcity.cl playing with the "Tipo Calle" while the > ? ? ?page ?is ?loading ?makes dillo segfault. If "Remote CSS" is > ? ? ?disabled, it doesn't happen (also OK in dillo-2.0). > ?3.- New web site design > ? ? ?We have a new banner and after finding a good color palette > ? ? ?it may be ready to renew the site before 2.1 is announced. > ?4.- Debian/Ubuntu packages (after 2.1 final is ready) > ?5.- Update "8 years" page (it's nine) > ? ? ?Yes, I should have done it already... > ?6.- Configurable key bindings. > ? ? ?I'm reviewing this with Tim. Hopefully it will make it into > ? ? ?the 2.1 release. > ?7.- Memory usage statistics > ? ? ?Scott has posted some data on this, in another thread. I'll > ? ? ?answer there. > > > ?I'd be working on 5, 6 and 3. > ?Volunteers please assign yourselves to the pending points. > > ?BTW, ?if ?you ?have important points to add to the list, please > say so. > > ?Of course any segfaults or regressions have high priority too. > > ?TIA. > > -- > ?Cheers > ?Jorge.- > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev >

April 22, 2009

towards a dillo-2.1 release

by Johannes.Hofmann＠gmx.de

On Tue, Apr 21, 2009 at 11:06:09AM -0400, Jorge Arellano Cid wrote: > On Tue, Apr 21, 2009 at 09:01:46AM +0200, Hofmann Johannes wrote: > > On Tue, Apr 21, 2009 at 07:48:11AM +0200, Hofmann Johannes wrote: > > > On Mon, Apr 20, 2009 at 05:10:41PM -0400, Jorge Arellano Cid wrote: > > > > Hi there, > > > > > > > > It'd be very good if we can complete these points for the 2.1 > > > > release. Listed in no particular order: > > > > > > > > 1.- Dw documentation: online and as tarball. > > > > We have good docs. but to generate them there's a need to > > > > have: doxygen, graphviz, dot, latex and friends. That's why > > > > having it online and as a tarball is a good idea. > > > > 2.- Mapcity segfault > > > > In www.mapcity.cl playing with the "Tipo Calle" while the > > > > page is loading makes dillo segfault. If "Remote CSS" is > > > > disabled, it doesn't happen (also OK in dillo-2.0). > > > > 3.- New web site design > > > > We have a new banner and after finding a good color palette > > > > it may be ready to renew the site before 2.1 is announced. > > > > 4.- Debian/Ubuntu packages (after 2.1 final is ready) > > > > 5.- Update "8 years" page (it's nine) > > > > Yes, I should have done it already... > > > > 6.- Configurable key bindings. > > > > I'm reviewing this with Tim. Hopefully it will make it into > > > > the 2.1 release. > > > > 7.- Memory usage statistics > > > > Scott has posted some data on this, in another thread. I'll > > > > answer there. > > > > > > > > > > > > I'd be working on 5, 6 and 3. > > > > Volunteers please assign yourselves to the pending points. > > > > > > I will check 2. > > > > Ok, I can reproduce it now with > > > > trickle -d 15 dillo > > > > trickle (http://monkey.org/~marius/pages/?page=trickle) is really > > cool for debugging! > > > > The problem is the repush caused by the arriving CSS stylesheet. It > > deletes all form widgets and recreates them later. > > I guess I can fix the segfault somehow, but there is a fundamental > > problem if the user starts to fill in a form and then the repush > > deletes all his data :( > > > > I currently see these options: > > > > 1. Disable forms while CSS stylesheets are pending. > > 2. Disable the repush once the user started to fill in forms. > > 3. Save form data in memory and restore it after repush. > > This could also be used to restore form data when going back to a > > forms page. > > > > Opinions? > > To implement what we had with dillo1: This is, inactive forms > until the full form is loaded. Adding the restriction of pending > stylesheets too (like in 1). Ok, I just commited a fix. Please test carefully as there might be negative sideeffects like permanentely deactivated forms if a stylesheet fails to load. Cheers, Johannes

April 22, 2009

towards a dillo-2.1 release

by jcid＠dillo.org

On Tue, Apr 21, 2009 at 08:03:57PM +0000, corvid wrote: > Jorge wrote: > > Please check and comment. > > > The next release, dillo-2.1, scheduled for middle 2009 will provide basic CSS > > support, and the usual bugfixes and cleanups. > > Auth deserves mention, I think. > And I'd add "new features" or "improvements" in front of > "bugfixes and cleanups", since we have added various new > little things as well. Please go ahead. -- Cheers Jorge.-

April 21, 2009

towards a dillo-2.1 release

by corvid＠lavabit.com

Jorge wrote: > Please check and comment. > The next release, dillo-2.1, scheduled for middle 2009 will provide basic CSS > support, and the usual bugfixes and cleanups. Auth deserves mention, I think. And I'd add "new features" or "improvements" in front of "bugfixes and cleanups", since we have added various new little things as well.

April 21, 2009

towards a dillo-2.1 release

by jcid＠dillo.org

On Mon, Apr 20, 2009 at 05:10:41PM -0400, Jorge Arellano Cid wrote: > Hi there, > > It'd be very good if we can complete these points for the 2.1 > release. Listed in no particular order: > > 1.- Dw documentation: online and as tarball. > We have good docs. but to generate them there's a need to > have: doxygen, graphviz, dot, latex and friends. That's why > having it online and as a tarball is a good idea. > 2.- Mapcity segfault > In www.mapcity.cl playing with the "Tipo Calle" while the > page is loading makes dillo segfault. If "Remote CSS" is > disabled, it doesn't happen (also OK in dillo-2.0). > 3.- New web site design > We have a new banner and after finding a good color palette > it may be ready to renew the site before 2.1 is announced. > 4.- Debian/Ubuntu packages (after 2.1 final is ready) > 5.- Update "8 years" page (it's nine) > Yes, I should have done it already... > 6.- Configurable key bindings. > I'm reviewing this with Tim. Hopefully it will make it into > the 2.1 release. > 7.- Memory usage statistics > Scott has posted some data on this, in another thread. I'll > answer there. > > > I'd be working on 5, 6 and 3. 5 is done. BTW, there's a good potential link for "memory usage" when the collected data makes its way into a web page. Please check and comment. -- Cheers Jorge.-

April 21, 2009

towards a dillo-2.1 release

by corvid＠lavabit.com

Jorge wrote: > On Mon, Apr 20, 2009 at 10:46:49PM +0000, corvid wrote: > > Jorge wrote: > > > Of course any segfaults or regressions have high priority too. > > > > The dicache changes broke scaled multiscan images. > > I don't think FltkImgbuf::newScan() gets called anymore. > > You're right. Can you look at it? > > BTW: FltkImgbuf::newScan() can be issued by adding a call to > a_Image_new_scan(). All right. PS I was glad to hear that the website will get a new banner.

April 21, 2009

[Patch 2/4] Refactoring src/prefs.c and src/dir.c

by tim.nieradzik＠gmx.de

> The patch has a strange comment WRT equal signs: > > + // parse the value > + i = 0; > + while (*p) { > + // skip all spaces and equal signs > + if (!isspace(*p)) { > + value[i++] = *p; > + } > + > + p++; > + } > + > + value[i] = '\0'; > > So either the implementation or the comment is wrong... The comment is wrong, I am sorry. If you look a few lines above, you will see that we have already checked whether the current character is an equal sign. In a previous implementation I used to have an additional check there but removed it later as we do not want to skip any equal signs within values. Equal signs are very common in search URLs so skipping them could have led to many problems. I guess I just forgot to adjust the comment accordingly after having changed this part. > If the required job is basically the same, I can keep the current > function (maybe returning the new termination codes) and continue > integrating the patchset. Yes, that is probably best. --Tim

April 21, 2009

[Patch 2/4] Refactoring src/prefs.c and src/dir.c

by jcid＠dillo.org

On Mon, Apr 20, 2009 at 06:44:16PM +0000, Tim Nieradzik wrote: > > What's the main point of dParser_parse_rc_line()? > > The main difference to the current implementation is that equal > signs are interpreted as separator. The current implementation also does that. The patch has a strange comment WRT equal signs: + // parse the value + i = 0; + while (*p) { + // skip all spaces and equal signs + if (!isspace(*p)) { + value[i++] = *p; + } + + p++; + } + + value[i] = '\0'; So either the implementation or the comment is wrong... > > Besides, it requires that ``line'', ``name'' and ``value'' are > initialised with a specific length (in dpid/dpid.c it is set to > 1024). The major advantage is that corrupt files (with very long > lines) would not congest the RAM since we abort after 1024 > characters. This is very unlikely though. > > > The comment says it extracts type, name and value, but it doesn't > > extract type. > > Sorry, I had forgotten to update the description. In a previous > version of my patch there has been a ``type'' attribute. As > proposed, I removed it later on. Since then this function does > basically the same job as dParser_get_rc_pair(). If the required job is basically the same, I can keep the current function (maybe returning the new termination codes) and continue integrating the patchset. Otherwise, what is exactly the new function supposed to do differently? -- Cheers Jorge.-

April 21, 2009