- Dillo-dev - lists.mailman3.com

fltk2 snapshot update

by corvid＠lavabit.com

Jeremy wrote: > On Mon, Jun 02, 2008 at 04:26:55PM +0200, Johannes Hofmann wrote: > > BTW, shouldn't we point users directly to fltk.org for downloading > > fltk2? Otherwise people might think that dillo2 needs a modified > > version of fltk2. > > +1 . We shouldn't let anything discourage people from trying dillo2, > so anything that suggests they might need to patch other software is a > bad idea. Along these lines, I've been wondering whether it might be a good idea to list the required and optional libraries on the CVS page.

June 2, 2008

fltk2 snapshot update

by onepoint＠starurchin.org

On Mon, Jun 02, 2008 at 04:26:55PM +0200, Johannes Hofmann wrote: > ... there is a new fltk2 snaphot (r6132) available. Thanks, I just upgraded. A nice change: the build now completes successfully without X windows running (it used to build the library but fail to build some of the apps, which was annoying). > It contains a bugfix for the weird green artifacts in the > FileChooser. By the way, when I was refactoring the form parsing code recently I saw those same artifacts on my form test page. They came and went as I changed the code: sometimes they didn't appear at all, sometimes a reload would get rid of them, sometimes I had to go back and forward in the navigation history to get rid of them. Since I was not touching any widget code I assumed I was triggering some sporadic bug in Dillo or FLTK. Let's see if the new FLTK behaves any better! > I think we should update the download instructions. +1 > BTW, shouldn't we point users directly to fltk.org for downloading > fltk2? Otherwise people might think that dillo2 needs a modified > version of fltk2. +1 . We shouldn't let anything discourage people from trying dillo2, so anything that suggests they might need to patch other software is a bad idea. Regards, Jeremy Henty

June 2, 2008

fltk2 snapshot update

by Johannes.Hofmann＠gmx.de

Hi, at fltk.org there is a new fltk2 snaphot (r6132) available. It contains a bugfix for the weird green artifacts in the FileChooser. I think we should update the download instructions. BTW, shouldn't we point users directly to fltk.org for downloading fltk2? Otherwise people might think that dillo2 needs a modified version of fltk2. Cheers, Johannes

June 2, 2008

why is SELECT a block container in Tags[]?

by corvid＠lavabit.com

Jorge wrote: > > > On Sat, May 31, 2008 at 07:02:02PM +0000, corvid wrote: > > > > <form> > > > > <select> > > > > <font color=red>segfault</font> > > > > </select> > > > > </form> > Patch committed (funny rendering sometimes, no segfault with > the above example). Justus got that sort of segfault because he must have standard_widget_colors set.

June 2, 2008

why is SELECT a block container in Tags[]?

by jcid＠dillo.org

On Sun, Jun 01, 2008 at 08:16:49PM +0000, corvid wrote: > Jorge wrote: > > 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). > > Now dillo can't deal with multiple <option>s without </option> in between, > e.g., http://www.dillo.org/bugtrack/Dquery.html Oh, yes. Patch committed (funny rendering sometimes, no segfault with the above example). It looks simpler to have SELECT as a block container, but I prefer this simple patch because it _is_ an inline container. The decision on what to do with unallowed elements is yet to be made (ignore & warn or close the open container for instance). -- Cheers Jorge.-

June 2, 2008

why is SELECT a block container in Tags[]?

by corvid＠lavabit.com

Jorge wrote: > 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). Now dillo can't deal with multiple <option>s without </option> in between, e.g., http://www.dillo.org/bugtrack/Dquery.html

June 1, 2008

Splitting html.cc: WAS: Re: [Dillo-dev] [patch]: replace form::Form ...

by onepoint＠starurchin.org

On Sun, Jun 01, 2008 at 01:42:11PM -0400, Jorge Arellano Cid wrote: > I removed form.{hh,cc} from cvs. Although they may reappear once > html.cc is split. Well, since you mention it...! :-) I had another go at splitting html.cc and this time I got it to work. No code was modified except that DilloHtml::getCurrentForm is no longer inline and the DilloHtmlForm constructor and destructor are wrapped in Html_form_{create,delete}, which can be called without access to the DilloHtmlForm class definition. So let's talk filenames! I moved the form code into new files called html_form.{hh,cc} . I really like hierarchical file names like that (they make related things sort next to each other), but maybe you would prefer the old form.{hh,cc} ? Also, I had to move a lot of declarations that both html.cc and html_form.cc use into a new header called html_internal.hh . Again, please specify a different file name if you want. I hadn't planned on creating a second new header but there are several definitions that are used by most of the html.cc internals, eg. almost everything needs the DilloHtml class definition and various HT2* macros etc. The "internal header" factors out that common API. I'd like to avoid it but it seems inevitable to me. Note that adding html_internal.hh is a one-off change. Further splitting should not require extra internal headers, just one new header per new source file as is standard. Also note that splitting off the form code is particularly messy since it includes new objects that appear in the DilloHtml definition. I would expect further splitting (eg, the table code) to be much simpler. The final decision is what to do with function names that move from *.cc to *.hh files. Leave them the same or rename "Html_*" to "a_Html_*"? I would suggest leaving them the same because they are still Html internals. They only appear in *.hh files because the internal implementation is spread among several files. If people think this sounds good and confirm the right names for files and functions then I will start proposing patches. I will move the code around in stages without breaking the build, so you'll get several small patches instead of one big one. I think that will be easier to review (but you can have a mega-patch if you really want one). Here are the stats: before: $ wc html*.{hh,cc} 21 42 338 html.hh 0 0 0 html_form.hh 0 0 0 html_internal.hh 6016 20229 191216 html.cc 0 0 0 html_form.cc 6037 20271 191554 total after: $ wc html*.{hh,cc} 21 42 338 html.hh 40 121 1404 html_form.hh 240 841 7832 html_internal.hh 4114 14090 129091 html.cc 1764 5563 57036 html_form.cc 6179 20657 195701 total (The final version may differ as I clean things up, but it won't be much different.) Regards, Jeremy Henty

June 1, 2008

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