November 2007 - Dillo-dev - lists.mailman3.com

Re: patch: base url page menu

by jcid＠dillo.org

On Mon, Nov 12, 2007 at 04:59:34PM +0000, place wrote: > Considering how all of the arguments are bw, do you think > the control should go html -> bw -> uicmd -> menu? The "Load images" via page menu patch was committed. I also made a big cleanup of html.hh. It was exporting data no module besides html.cc was using. With regard to your question, currently we have this dependency graph: ,-------------> menu | ^ -----> timeout | | / | v / | ui <-----> uicmd <-----> nav | ^ ^ \ | | / | \ | | / v \ v '-> html ----' bw ----> dialog ^ | form I don't like the double relation between "html" and "menu". It could be "html" calling "menu" only. For instance if we implement setting a callback function in menu's API for "Load Images". Maybe there's a better way, and I'm not sure, but a least the committed cleanup makes it look much cleaner. ;-) BTW, I also added premliminar activate/deactivate to this menu item. -- Cheers Jorge.-

Nov. 14, 2007

Re: Accept-Encoding: gzip

by place＠gobigwest.com

Now that I'm on gcc4, let's get rid of the embarrassing signedness warnings: diff -pur dillo2/src/decode.c dillo2-cur/src/decode.c --- dillo2/src/decode.c 2007-11-14 11:40:05.000000000 +0000 +++ dillo2-cur/src/decode.c 2007-11-14 19:40:29.000000000 +0000 @@ -32,10 +32,10 @@ static Dstr *Decode_gzip(Decode *dc, con Dstr *output = dStr_new(""); while ((rc == Z_OK) && (inputConsumed < inLen)) { - zs->next_in = (char *)inData + inputConsumed; + zs->next_in = (Bytef *)inData + inputConsumed; zs->avail_in = inLen - inputConsumed; - zs->next_out = dc->buffer; + zs->next_out = (Bytef *)dc->buffer; zs->avail_out = bufsize; rc = inflate(zs, Z_SYNC_FLUSH); @@ -69,7 +69,7 @@ static Dstr *Decode_charset(Decode *dc, Dstr *input, *output; char *inPtr, *outPtr; - int inLeft, outRoom; + size_t inLeft, outRoom; output = dStr_new("");

Nov. 14, 2007

Re: patch: TransferSize

by jcid＠dillo.org

On Tue, Nov 13, 2007 at 09:07:48PM +0000, place wrote: > > I'd prefer TransferSize (this is the whole http transfer size minus the > > Header length --i.e. Content-Length). > Committed with some minor changes: s/TotalSize/ExpectedSize/g e.g.: + int ExpectedSize; /* Goal size of the HTTP transfer (0 if unknown)*/ + int TransferSize; /* Actual length of the HTTP transfer */ I also decided to remove this line: entry->Flags |= CA_GotData; entry->Flags &= ~CA_Stopped; /* it may catch up! */ - entry->TotalSize = entry->Data->len; if (entry->Decoder) { a_Decode_free(entry->Decoder); ... and now the transfer-size mismatch messages, shed more light on the redirection bug! For instance if you take the same "mm1.html" test case, going back and forward, it's clear that the image is being reloaded, but the HTTP header is not re-parsed. This is a problem with the cache_null_client. I haven't investigated it further, but this hint should be enough. -- Cheers Jorge.-

Nov. 14, 2007

Re: Accept-Encoding: gzip

by jcid＠dillo.org

On Tue, Nov 13, 2007 at 09:10:08PM +0100, Johannes Hofmann wrote: > On Tue, Nov 13, 2007 at 11:11:29AM -0300, Jorge Arellano Cid wrote: > > Hi, > > > > [gzip decoder] > > > > On Mon, Nov 12, 2007 at 02:52:43PM +0000, place wrote: > > > Hmm, how unfortunate. It had been working just fine for me, though I took it > > > out yesterday so that I could have a clean tree... I wonder whether > > > we're constantly going to see timing problems or something, where the > > > people with fast machines write things that work on fast machines and > > > the person with a slow machine will write things that work on a slow machine. > > > > Good news! > > Committed. > > Is decode.h perhaps missing in cvs? Ooops! Yes, sorry... Committed both: decode.[ch] -- Cheers Jorge.-

Nov. 14, 2007

forms related segfault

by Johannes.Hofmann＠gmx.de

On Mon, Nov 12, 2007 at 04:13:49PM -0300, Jorge Arellano Cid wrote: > On Mon, Nov 12, 2007 at 05:56:36PM +0100, Johannes Hofmann wrote: > > > > > On Fri, Nov 09, 2007 at 09:34:33AM -0300, Jorge Arellano Cid wrote: > > > > > > Hi, > > > > > > > > > > > > On Fri, Nov 09, 2007 at 09:09:26AM -0300, Jorge Arellano Cid wrote: > > > > > > > [...] > > > > > > > As a side effect of flickering, I noticed several times how some > > > > > > > non existent inputs (text entries and buttons) were phantom-rendered > > > > > > > during updates (i.e. appeared on screen for a few jiffies). > > > > > > > > > > > > > > [...] > > > > > > > > > > > > For instance, enable flickering (disable double-buffer and > > > > > > internal buffer), then go to: > > > > > > > > > > > > 1. www.google.com //and then to > > > > > > 2. chlamydia.fs.ei.tum.de/pub/DragonFly/packages/stable/DragonFly-1.10/All/ > > > > > > > > > > > > While loading the second URL you'll see the phantom-rendering > > > > > > of the text input and the two buttons that google uses. > > > > > > > > > > > > > > > Although now we have memory-freeing hooked, the phantom > > > > > rendering still occurs... > > > > > > > > Yes, maybe it has to do with how dillo widgets must be deleted. > > > > There was recently a discussion about this in the fltk forums. > > > > I will try to figure out what happens. But at the moment I get > > > > various sorts of crashes with this patch immediately when I load a > > > > page with forms. > > > > > > Here it doesn't crash, but it's sure the phantom widgets are referencing > > > freed memory (it get garbage labels). > > > > > > You can comment: > > > > > > dw->setDeleteCallback(a_Html_free, this); > > > > > > and test as it was before the patch (with no memory freeing). > > > > just a short update on this issue. There seems to be something more > > fundamentally wrong on my system. > > > > #include "../dlib.h" > > > > int main (char **argv, int argc) { > > Dstr *ds = dStr_new(""); > > > > dStr_sprintfa(ds, "Hello %s", "foo"); > > dStr_sprintfa(ds, "World %d", 42); > > } > > > > > > crashes here, but it runs fine on Linux and even valgrind does not > > complain on Linux. > > If vsnprintf(), when called alone, works on your system, > try adding the extra: > > va_copy(argp2, argp); > > to dStr_sprintfa() as in dStr_vsprintfa(). > > Just an idea. Thanks, but I think the culprit is a weird bug when libc was compiled with a special gcc-version. Anyway, I now have a system again on which current dillo-fltk runs pretty stable. So I can now attack the phantom widgets - at least I will try :-) cheers, Johannes

Nov. 13, 2007

Re: Accept-Encoding: gzip

by Johannes.Hofmann＠gmx.de

On Tue, Nov 13, 2007 at 11:11:29AM -0300, Jorge Arellano Cid wrote: > Hi, > > [gzip decoder] > > On Mon, Nov 12, 2007 at 02:52:43PM +0000, place wrote: > > Hmm, how unfortunate. It had been working just fine for me, though I took it > > out yesterday so that I could have a clean tree... I wonder whether > > we're constantly going to see timing problems or something, where the > > people with fast machines write things that work on fast machines and > > the person with a slow machine will write things that work on a slow machine. > > Good news! > Committed. Is decode.h perhaps missing in cvs? cheers, Johannes

Nov. 13, 2007

Re: Accept-Encoding: gzip

by place＠gobigwest.com

Jorge wrote: > It doesn't look like a race condition, but a problem of handling redirections > and the null_decoder in cache.c (redirections is a somewhat ad-hoc code, not > well designed yet). > > Attached goes a page to reproduce the segfault (without the patch in CVS). > For instance: > > 1- save the attached page in /tmp > 2- dillo-fltk /tmp > 3- click on the page > 4- go back > 5- go forward (segfault) // you may need to repeat this 4 and 5 Perhaps along these same lines, I did manage to break my image-loading code once when I clicked a few times on an image that wanted to redirect. I couldn't get it to crash again, though. > With regard to the iconv decoder: > > Please note that we may still need the original data, to be > able to save verbatim. This is, if the original page is encoded > in latin2 (with a <meta http-equiv charset line in the source), > and it is saved translated to UTF-8 we have two problems (the > misleading "meta" and that the user will get a page that's not a > verbatim copy of the original). > > One way to solve this is to re-encode into the original charset > at save time. This is not 8bit clean but could work most of the > time. > > Another way is to keep a copy of the verbatim data. In this > case we're 8bit clean and it would only take more memory when the > original is not UTF-8. > > I *feel* 8bit clean is the correct path, and here there're lots > of ways to optimize. For instance, with UTF-8 pages we don't need > an extra buffer. For pages that need one, we can deallocate the > UTF-8 encoded one when leaving the page (and re-create it if the > page is visited again). > > This is just some food for thought. You had mentioned once before that you wanted to keep the original in cache, and I agree completely.

Nov. 13, 2007

Re: is the visited_color pref somehow deprecated?

by jcid＠dillo.org

On Sun, Nov 11, 2007 at 07:42:56PM +0000, place wrote: > Jorge wrote: > > > > dillorc2 doesn't list it, but if you have force_my_colors set and you > > > don't know to add visited_color to the rc, you get stuck with purple, > > > which is not optimal on a black background... > > > > No it's not deprecated. I tried to add the working options in dillorc2 > > only. Patch is welcomed! :-) > > I've had it set for weeks now, and it seems to work fine for me. > > Oh, speaking of colors, what do you consider to be the proper behavior > for buttons? My text color is set to white, so buttons have white > text on a nearly-white background. Should the button not use the text color, > or should the button background color be some sort of modification of the > page background color, or...? I haven't thought much of this. The idea was to apply a CSS stylesheet given by the user, but this may take a long while... Given that you are using a black background, you'll probably experience better what the problems are with this. If we need to provide a button_bg preference or similar, it's no problem. Just try to get them into a kind. For instance if the same color can be used for selection widgets and checkboxes, it could be "form_element_bg" instead. -- Cheers Jorge.-

Nov. 13, 2007

Re: Accept-Encoding: gzip

by jcid＠dillo.org

Hi, [gzip decoder] On Mon, Nov 12, 2007 at 02:52:43PM +0000, place wrote: > Hmm, how unfortunate. It had been working just fine for me, though I took it > out yesterday so that I could have a clean tree... I wonder whether > we're constantly going to see timing problems or something, where the > people with fast machines write things that work on fast machines and > the person with a slow machine will write things that work on a slow machine. Good news! Committed. I found a workaround for the segfault and decided to commit to allow further investigation and polishing from in-CVS code. It doesn't look like a race condition, but a problem of handling redirections and the null_decoder in cache.c (redirections is a somewhat ad-hoc code, not well designed yet). Attached goes a page to reproduce the segfault (without the patch in CVS). For instance: 1- save the attached page in /tmp 2- dillo-fltk /tmp 3- click on the page 4- go back 5- go forward (segfault) // you may need to repeat this 4 and 5 BTW, the workaround is mainly: - dStr_append_l(entry->Data, buf, (int)buf_size); + /* Assert we have a Decoder. + * BUG: this is a workaround, more study and a proper design + * for handling redirects is required */ + if (entry->Decoder != NULL) { + decodedBuf = a_Decode_process(entry->Decoder, buf, buf_size); + dStr_append_l(entry->Data, decodedBuf->str, decodedBuf->len); + dStr_free(decodedBuf, 1); + } else { + dStr_append_l(entry->Data, buf, buf_size); + } With regard to: // Doesn't work. I could make TotalSize into something like BytesRemaining, // seeing whether it goes precisely to 0. I'd prefer TransferSize (this is the whole http transfer size minus the Header length --i.e. Content-Length). With regard to the iconv decoder: Please note that we may still need the original data, to be able to save verbatim. This is, if the original page is encoded in latin2 (with a <meta http-equiv charset line in the source), and it is saved translated to UTF-8 we have two problems (the misleading "meta" and that the user will get a page that's not a verbatim copy of the original). One way to solve this is to re-encode into the original charset at save time. This is not 8bit clean but could work most of the time. Another way is to keep a copy of the verbatim data. In this case we're 8bit clean and it would only take more memory when the original is not UTF-8. I *feel* 8bit clean is the correct path, and here there're lots of ways to optimize. For instance, with UTF-8 pages we don't need an extra buffer. For pages that need one, we can deallocate the UTF-8 encoded one when leaving the page (and re-create it if the page is visited again). This is just some food for thought. -- Cheers Jorge.-

Nov. 13, 2007

forms related segfault

by jcid＠dillo.org

On Mon, Nov 12, 2007 at 05:56:36PM +0100, Johannes Hofmann wrote: > > > > On Fri, Nov 09, 2007 at 09:34:33AM -0300, Jorge Arellano Cid wrote: > > > > > Hi, > > > > > > > > > > On Fri, Nov 09, 2007 at 09:09:26AM -0300, Jorge Arellano Cid wrote: > > > > > > [...] > > > > > > As a side effect of flickering, I noticed several times how some > > > > > > non existent inputs (text entries and buttons) were phantom-rendered > > > > > > during updates (i.e. appeared on screen for a few jiffies). > > > > > > > > > > > > [...] > > > > > > > > > > For instance, enable flickering (disable double-buffer and > > > > > internal buffer), then go to: > > > > > > > > > > 1. www.google.com //and then to > > > > > 2. chlamydia.fs.ei.tum.de/pub/DragonFly/packages/stable/DragonFly-1.10/All/ > > > > > > > > > > While loading the second URL you'll see the phantom-rendering > > > > > of the text input and the two buttons that google uses. > > > > > > > > > > > > Although now we have memory-freeing hooked, the phantom > > > > rendering still occurs... > > > > > > Yes, maybe it has to do with how dillo widgets must be deleted. > > > There was recently a discussion about this in the fltk forums. > > > I will try to figure out what happens. But at the moment I get > > > various sorts of crashes with this patch immediately when I load a > > > page with forms. > > > > Here it doesn't crash, but it's sure the phantom widgets are referencing > > freed memory (it get garbage labels). > > > > You can comment: > > > > dw->setDeleteCallback(a_Html_free, this); > > > > and test as it was before the patch (with no memory freeing). > > just a short update on this issue. There seems to be something more > fundamentally wrong on my system. > > #include "../dlib.h" > > int main (char **argv, int argc) { > Dstr *ds = dStr_new(""); > > dStr_sprintfa(ds, "Hello %s", "foo"); > dStr_sprintfa(ds, "World %d", 42); > } > > > crashes here, but it runs fine on Linux and even valgrind does not > complain on Linux. If vsnprintf(), when called alone, works on your system, try adding the extra: va_copy(argp2, argp); to dStr_sprintfa() as in dStr_vsprintfa(). Just an idea. -- Cheers Jorge.-

Nov. 12, 2007