March 2008 - Dillo-dev - lists.mailman3.com

https plugin status

by Christian.Kellermann＠nefkom.net

* Jeremy Henty <onepoint(a)starurchin.org> [080315 05:58]: > On Sat, Mar 15, 2008 at 01:22:09AM +0000, Jeremy Henty (ie. me) wrote: > > > I was wrong, the https filter dpi *is* starting. But, its debugging > > messages don't appear because it sends them to stdout, which dpid > > redirects to the DPI socket. This feels ... somehow ... wrong. > > And so it is! (Patch submitted in a new thread.) After redirecting > the debugging messages to stderr I see: > > [https dpi]: {In https.filter.dpi} > [https dpi]: ***Value of cmd, url or http_query is NULL - cannot continue > [https dpi]: { exiting https.dpi} > If you add an additional MSG output you see something like this: [https dpi]: {In https.filter.dpi} [https dpi]: dpip_tag <cmd='open_url' url='https://www.ccc.de' '> [https dpi]: ***Value of cmd, url or http_query is NULL - cannot continue [https dpi]: { exiting https.dpi} dpid_tag looks like there is a missing '. I added Index: dpi/https.c =================================================================== RCS file: /sfhome/cvs/dillo/dillo2/dpi/https.c,v retrieving revision 1.1.1.1 diff -b -u -p -r1.1.1.1 https.c --- dpi/https.c 6 Oct 2007 22:36:34 -0000 1.1.1.1 +++ dpi/https.c 15 Mar 2008 07:51:29 -0000 @@ -191,6 +191,9 @@ static void yes_ssl_support(void) /*Get the network address and command to be used*/ dpip_tag = sock_handler_read(sh); + + MSG("dpip_tag %s\n",dpip_tag); + cmd = a_Dpip_get_attr(dpip_tag, strlen(dpip_tag), "cmd"); url = a_Dpip_get_attr(dpip_tag, strlen(dpip_tag), "url"); http_query = a_Dpip_get_attr(dpip_tag, strlen(dpip_tag), "query"); I am not sure whether this is really save, is this tag \0 terminated? Nonetheless something is lost on the way... Kind regards, Christian -- You may use my gpg key for replies: pub 1024D/47F79788 2005/02/02 Christian Kellermann (C-Keen)

March 15, 2008

https plugin status

by onepoint＠starurchin.org

On Sat, Mar 15, 2008 at 02:18:27AM +0000, place wrote: > It appears that Capi_dpi_build_cmd() needs to test for "proto.https" > instead of "https"... Or maybe Capi_url_uses_dpi() should be checking for "https" and *not* adding the "proto." prefix? I'm just guessing here, I'm still figuring out this code. Regards, Jeremy Henty

March 15, 2008

https plugin status

by place＠gobigwest.com

Jeremy wrote: > On Sat, Mar 15, 2008 at 01:22:09AM +0000, Jeremy Henty (ie. me) wrote: > > > I was wrong, the https filter dpi *is* starting. But, its debugging > > messages don't appear because it sends them to stdout, which dpid > > redirects to the DPI socket. This feels ... somehow ... wrong. > > And so it is! (Patch submitted in a new thread.) After redirecting > the debugging messages to stderr I see: > > [https dpi]: {In https.filter.dpi} > [https dpi]: ***Value of cmd, url or http_query is NULL - cannot continue > [https dpi]: { exiting https.dpi} > > which at least gives some idea of what is going wrong. It appears that Capi_dpi_build_cmd() needs to test for "proto.https" instead of "https"...

March 15, 2008

https plugin status

by onepoint＠starurchin.org

On Sat, Mar 15, 2008 at 01:22:09AM +0000, Jeremy Henty (ie. me) wrote: > I was wrong, the https filter dpi *is* starting. But, its debugging > messages don't appear because it sends them to stdout, which dpid > redirects to the DPI socket. This feels ... somehow ... wrong. And so it is! (Patch submitted in a new thread.) After redirecting the debugging messages to stderr I see: [https dpi]: {In https.filter.dpi} [https dpi]: ***Value of cmd, url or http_query is NULL - cannot continue [https dpi]: { exiting https.dpi} which at least gives some idea of what is going wrong. Jeremy Henty

March 15, 2008

[PATCH]: send the https dpi plugin debug messages to the right place

by onepoint＠starurchin.org

The https DPI plugin sends its debug messages to stdin. This is wrong because the DPI daemon dups the plugin's stdin to the DPI socket. This patch redirects the debug messages to stderr. Jeremy Henty

March 15, 2008

https plugin status

by onepoint＠starurchin.org

On Fri, Mar 14, 2008 at 11:35:38PM +0000, Jeremy Henty (ie. me) wrote: > ... I can see the CCC setting up tearing down the IO links, so it > looks as though the dillo process is talking to something, and > getting something sensible from it. But AFAICT the https filter dpi > isn't even starting (it should dump some startup messages to stdout > which I'm not seeing). I was wrong, the https filter dpi *is* starting. But, its debugging messages don't appear because it sends them to stdout, which dpid redirects to the DPI socket. This feels ... somehow ... wrong. Jeremy Henty

March 15, 2008

https plugin status

by onepoint＠starurchin.org

On Fri, Mar 14, 2008 at 07:19:45PM +0100, Christian Kellermann wrote: > Dear list, > > is the https plugin supposed to work? My take on the status of https is that it's currently my biggest itch! :-) I've been gdb-ing dillo-fltk (looking at it from the other end from you, as it were), and I can see the CCC setting up tearing down the IO links, so it looks as though the dillo process is talking to something, and getting something sensible from it. But AFAICT the https filter dpi isn't even starting (it should dump some startup messages to stdout which I'm not seeing). Like you I'd appreciate some guidance from those wiser than myself. Getting https working would greatly reduce the number of times I run Firefox! Regards, Jeremy Henty

March 15, 2008

libiconv fix for OpenBSD

by Christian.Kellermann＠nefkom.net

* Jorge Arellano Cid <jcid(a)dillo.org> [080314 21:40]: > > Committed, but in two places! Yeah I have seen it. Why is the same code duplicated? Once should be enough. My original patch contained such one instance of the tests... Kind regards, Christian -- You may use my gpg key for replies: pub 1024D/47F79788 2005/02/02 Christian Kellermann (C-Keen)

March 15, 2008

[patch] further reduce redraws from resizing tables

by jcid＠dillo.org

Hi Johannes, On Tue, Mar 11, 2008 at 07:27:01PM +0100, Johannes Hofmann wrote: > Hi, > > below is another patch to reduce the redraws caused by resizing > tables. A new method Layout::queueDrawExcept(), that requests the > drawing of a rectangle except another rectangle is added. > It is then used in widget.cc to redraw the area that was previously > occupied by a widget, but is no longer occupied after a resize or move. > This makes it possible to redraw less when a table resizes. > All in all it should reduce the flicker a bit when loading table > based pages. On the topic of reducing the flicker, I'm far of an expert and please correct me if I'm wrong. AFAIU, the current design draws the background color before the widget content. This is: if you have an html page as big table, in dillo, it will become a table inside a textblock. When the textblock is asked to redraw, it will _erase_ the table with its background color and ask its child (the table) to redraw. Causing flicker. If this is true, a big gain could come from a different approach: just draw the surroundings of the widgets and ask the child widgets to redraw. This way widgets aren't erased beforehand, and can also decide not to redraw themselves when nothing has changed. I have worked a bit on this idea, and the attached patch mocks the idea hackishly. It draws the "padding" area of the CSS box (see the picture in namespacedw_1_1core_1_1style.html in dw docs) Please give it a review and share your comments, corrections and thoughts. -- Cheers Jorge.-

March 14, 2008

patch: meta charset changes decoder

by place＠gobigwest.com

Johannes wrote: > On Thu, Mar 13, 2008 at 10:49:47AM -0400, Jorge Arellano Cid wrote: > > Hi, > > > > On Fri, Mar 07, 2008 at 06:17:17AM +0000, place wrote: > > > This is no sort of proper fix whatsoever, but I was tired > > > of seeing the "would set charset" message. It's actually > > > surprisingly useful for remote files, since they're generally > > > still at the javascript-and-css point at the end of the first packet. > > > > In CVS there is a new approach that restarts parsing the whole page. > > It works with local/remote files, and page title. Please test it. > > Not 100% sure if it's this change, but since recently dillo-fltk > loops for me on http://www.ebay.com: > > META Content-Type changes charset to: ISO-8859-1 > Nav_open_url: new url='http://www.ebay.com/' > HTTP Content-Type gave charset as: ISO-8859-1 > META Content-Type gave charset as: ISO-8859-1 > FltkViewBase::drawTotal > META Content-Type changes charset to: Cp1252 > Nav_open_url: new url='http://www.ebay.com/' > HTTP Content-Type gave charset as: ISO-8859-1 > META Content-Type gave charset as: Cp1252 > FltkViewBase::drawTotal > META Content-Type changes charset to: ISO-8859-1 > Nav_open_url: new url='http://www.ebay.com/' > HTTP Content-Type gave charset as: ISO-8859-1 > META Content-Type gave charset as: ISO-8859-1 > FltkViewBase::drawTotal I should have made it clearer that my little patch from a day ago was intended to fix such looping.

March 14, 2008