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

[patch] make ComplexButton work

by corvid＠lavabit.com

Johannes wrote: > this patch fixes ComplexButton - at least it works here now :-) It's working for me, too! :)

April 13, 2008

[patch] make ComplexButton work

by Johannes.Hofmann＠gmx.de

Hi, this patch fixes ComplexButton - at least it works here now :-) The patch includes the ComplexButton destructor proposed by place and enables the ComplexButton code in dw-ui-test. It requires my last FltkViewBase::draw() patch. Cheers, Johannes

April 13, 2008

[patch] cleanup FltkViewBase::draw

by Johannes.Hofmann＠gmx.de

Hi, here comes a cleanup of FltkViewBase::draw(). It had grown too complicated... This patch also fixes two issues with nested views as they will exist with ComplexButtons. Cheers, Johannes

April 13, 2008

Re: patch: reset input

by jcid＠dillo.org

Hi, Committed -- Cheers Jorge.-

April 13, 2008

Re: patch: ISINDEX

by jcid＠dillo.org

On Sun, Apr 13, 2008 at 02:33:00AM +0000, corvid wrote: > Yeah, so very important... > > An isindex page: http://www.math.ncu.edu.tw/~shann/bcc16/7/html/isindex.cgi > Committed! Mmmm, ISINDEX, an old method that brings me back good memories. -- Cheers Jorge.-

April 13, 2008

Re: patch: file input

by corvid＠lavabit.com

Jorge wrote: > On Fri, Apr 11, 2008 at 09:21:16PM +0000, corvid wrote: > > Jorge wrote: > > > On Thu, Apr 10, 2008 at 04:13:56PM +0000, corvid wrote: > > > > If I read in a file, delete that file, and try to read it in again > > > > (uses E2EReload), the submit will send the (now empty) file because > > > > a_Capi_get_buf() finds the (now empty) entry in cache. > > > > So I'll have to find out where an a_Cache_entry_remove_by_url() should go. > > > > > > Yes. > > > > It looks like I'd have to figure out CCC for this, which would > > likely be more trouble than it's worth. > > OK, I'll allocate some time to give it a look. Cool. Sort of on topic, what do you think of reviving use of the bug tracker for the various little things that are easy to forget about?

April 12, 2008

Re: patch: file input

by jcid＠dillo.org

On Fri, Apr 11, 2008 at 09:21:16PM +0000, corvid wrote: > Jorge wrote: > > On Thu, Apr 10, 2008 at 04:13:56PM +0000, corvid wrote: > > > If I read in a file, delete that file, and try to read it in again > > > (uses E2EReload), the submit will send the (now empty) file because > > > a_Capi_get_buf() finds the (now empty) entry in cache. > > > So I'll have to find out where an a_Cache_entry_remove_by_url() should go. > > > > Yes. > > It looks like I'd have to figure out CCC for this, which would > likely be more trouble than it's worth. OK, I'll allocate some time to give it a look. -- Cheers Jorge.-

April 12, 2008

[patch] fix cookies freezing dillo problem

by akemnade＠tzi.de

Hi Jorge, On Fri, 11 Apr 2008 15:34:49 -0400 Jorge Arellano Cid <jcid(a)dillo.org> wrote: > Note: What still puzzles me, is why accept() returns when > there's nothing to read. > Hmm, accept() returns when you call connect() on the other side. Many TCP server programs send stuff to the client before receiving anything from the client (like ssh servers, smtp servers) so there is nothing unusual about that. So, normally you have on cookies.dpi side: accept() returns after connect() on dillo side read() returns after write() on dillo side then on dillo side: read() returns after write() on cookies.dpi side. As far as I understand in the race condition case you have: dillo cookies.dpi connect(sock1,...) sock1=accept(....) connect(sock2,...) (via a_Dpi_send_blocking_cmd) read(sock1,...) write(sock2,...) (does not block, contents will be added to the recv queue) read(sock2,...) and now, both sides are waiting for data,.... Greetings Andreas Kemnade

April 12, 2008

Re: patch: file input

by corvid＠lavabit.com

Jorge wrote: > On Thu, Apr 10, 2008 at 04:13:56PM +0000, corvid wrote: > > If I read in a file, delete that file, and try to read it in again > > (uses E2EReload), the submit will send the (now empty) file because > > a_Capi_get_buf() finds the (now empty) entry in cache. > > So I'll have to find out where an a_Cache_entry_remove_by_url() should go. > > Yes. It looks like I'd have to figure out CCC for this, which would likely be more trouble than it's worth.

April 11, 2008

Re: patch: file input

by jcid＠dillo.org

On Fri, Apr 11, 2008 at 07:12:06PM +0000, corvid wrote: > Jorge wrote: > > On Fri, Apr 11, 2008 at 05:48:25PM +0000, corvid wrote: > > > BTW, do you think dillo should do anything if it gets a huge file from > > > a server but didn't know to expect the file to be huge ahead of time > > > (no content length, or chunked transfer encoding)? > > > > Yes, of course. > > I mean should it take some particular action (a dialog or something) > once it figures out that it's N megs into something big? Good question. ;) Considering that we can only flag the entry as HUGE after it has grown a lot, aborting the connection and removing the entry is not an option. For root URLs: stopping the transfer could be offered, but OTOH the user can press the "Stop" button at will, and if he hasn't, we can assume he wants to continue (i.e. leave dillo2 "as is"). For non root URLs (mainly images): stopping the transfer once the threshold has being met, could be. Especially if we consider that the pixmap size is much bigger than the data, it makes sense. If it's simple to implement, it may be worth the effort. BTW, if we have a user clicking an iso, or movie that's served as "text/plain", the internal content-type checker will catch it, abort the connection, and leave the option of "Save link as...". -- Cheers Jorge.-

April 11, 2008