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

Hooked a decoder for text/plain with charset.

by corvid＠lavabit.com

Jorge wrote: > On Fri, May 30, 2008 at 10:51:33PM +0000, corvid wrote: > > Jorge wrote: > > > On Thu, May 29, 2008 at 09:15:24PM +0000, corvid wrote: > > > > Jorge wrote: > > > > > On Thu, May 29, 2008 at 08:49:22PM +0000, corvid wrote: > > > > > > Jorge wrote: > > > > > > > Just committed this patch. It makes things like: > > > > > > > > > > > > > > http://separat-lib.narod.ru/master.txt > > > > > > > > > > > > > > work. > > > > > > > > > > > > Why now? I don't understand the motivation for this. > > > > > > > > > > > > My next patch is just going to rip it out again because it > > > > > > will become unnecessary. > > > > > > > > > > Yeah, I noticed it could happen after making the patch, > > > > > but a segfault on that page made me fix and commit it. > > > > > > > > Why did it make plain segfault? > > > > > > The patch is attached for you to review in detail. > > > > > > The relevant part is an: > > > > > > Start_Ofs += i - len; > > > > > > substituted by a: > > > > > > Buf_Consumed = BufSize - len; > > > > > > (if the length of a long line got bigger than 'i', 'i - len' > > > was negative. A strange case triggered by that page, that has > > > really long lines). > > > > How did len get bigger than i? > > I tried the page yesterday without being able to get a crash. > > And now I've saved it locally and changed file.dpi to send it > > 200 bytes at a time, which gives me a long series of normal values > > when lines get bigger than packets: > > > > .. > > i-len 76 > > i-len 0 > > i-len 273 > > i-len 112 > > i-len 183 > > i-len 91 > > i-len 0 > > i-len 0 > > i-len 389 > > i-len 101 > > i-len 0 > > i-len 182 > > i-len 0 > > i-len 0 > > .. > > Well, it took me some time to reproduce it again... > > The attached patch is what I've got when adding the decoder over > the old code. It works most of the time, but if you go to: > > http://separat-lib.narod.ru/master.txt > > It will segfault with a Start_Ofs > BufSize. > Note: the patch is against current CVS. Oh, I thought the original no-decoder code was supposed to break.

June 1, 2008

Hooked a decoder for text/plain with charset.

by jcid＠dillo.org

On Fri, May 30, 2008 at 10:51:33PM +0000, corvid wrote: > Jorge wrote: > > On Thu, May 29, 2008 at 09:15:24PM +0000, corvid wrote: > > > Jorge wrote: > > > > On Thu, May 29, 2008 at 08:49:22PM +0000, corvid wrote: > > > > > Jorge wrote: > > > > > > Just committed this patch. It makes things like: > > > > > > > > > > > > http://separat-lib.narod.ru/master.txt > > > > > > > > > > > > work. > > > > > > > > > > Why now? I don't understand the motivation for this. > > > > > > > > > > My next patch is just going to rip it out again because it > > > > > will become unnecessary. > > > > > > > > Yeah, I noticed it could happen after making the patch, > > > > but a segfault on that page made me fix and commit it. > > > > > > Why did it make plain segfault? > > > > The patch is attached for you to review in detail. > > > > The relevant part is an: > > > > Start_Ofs += i - len; > > > > substituted by a: > > > > Buf_Consumed = BufSize - len; > > > > (if the length of a long line got bigger than 'i', 'i - len' > > was negative. A strange case triggered by that page, that has > > really long lines). > > How did len get bigger than i? > I tried the page yesterday without being able to get a crash. > And now I've saved it locally and changed file.dpi to send it > 200 bytes at a time, which gives me a long series of normal values > when lines get bigger than packets: > > .. > i-len 76 > i-len 0 > i-len 273 > i-len 112 > i-len 183 > i-len 91 > i-len 0 > i-len 0 > i-len 389 > i-len 101 > i-len 0 > i-len 182 > i-len 0 > i-len 0 > .. Well, it took me some time to reproduce it again... The attached patch is what I've got when adding the decoder over the old code. It works most of the time, but if you go to: http://separat-lib.narod.ru/master.txt It will segfault with a Start_Ofs > BufSize. Note: the patch is against current CVS. -- Cheers Jorge.-

June 1, 2008

why is SELECT a block container in Tags[]?

by jcid＠dillo.org

On Sat, May 31, 2008 at 07:02:02PM +0000, corvid wrote: > Jorge wrote: > > On Sat, May 31, 2008 at 03:26:50PM +0000, corvid wrote: > > > Why is SELECT a block container rather than an inline container in Tags[]? > > > > Most probably by mistake! > > > > Given that the DTD says: > > > > <!ELEMENT SELECT - - (OPTGROUP|OPTION)+ -- option selector --> > > [...] > > <!ELEMENT OPTGROUP - - (OPTION)+ -- option group --> > > [...] > > <!ELEMENT OPTION - O (#PCDATA) -- selectable choice --> > > > > it looks like inline container would fit better. > > (and stop some segfaults Justus detected). > > Well, it would still provide him with new segfaults for inline stuff like > > <form> > <select> > <font color=red>segfault</font> > </select> > </form> BTW, patch committed (now SELECT is an inline container). With regard to further segfaults, quoting myself: > SELECT can be closed in Html_stack_cleanup_at_open(). SELECT > can contain OPTGROUP and OPTION. > > It would be good to consider the other cases before making a patch. After Justus sends us a set of segfault cases (with the fuzzy technique) we can try to tackle a general solution. -- Cheers Jorge.-

June 1, 2008

[patch]: replace form::Form and remove form.{cc,hh}

by jcid＠dillo.org

On Sat, May 31, 2008 at 05:33:50PM +0100, Jeremy Henty wrote: > > The source files dillo2/src/form.{hh,cc} (which define the form::Form > class) are modified copies of dw2/test/form.{hh,cc} . Dillo uses > almost none of the code in these files. All dillo needs is a Receiver > class that wraps a DilloHtmlForm and delegates calls to the event > handlers to DilloHtmlForm methods. > > This patch removes all references to form::Form and form.{hh,cc} . It > replaces form::Form with DilloHtmlReceiver. It also moves the event > handler code into a DilloHtmlForm method and removes some unnecessary > (void *) casting. This simplifies the code that bridges form events > to DilloHtmlForm methods. > > WARNING: developers must run " make maintainer-clean ; ./autogen.sh " > after this patch appears in their CVS working directory. This is > because automake has to recreate Makefile.in , otherwise the build > will try to compile form.cc which no longer works. > > After this patch is applied you can delete dillo2/src/form.{hh,cc} . > Don't delete dw2/test/form.{hh,cc} though! Committed. I removed form.{hh,cc} from cvs. Although the may reappear once html.cc is split. -- Cheers Jorge.-

June 1, 2008