- Dillo-dev - lists.mailman3.com

New design of tag nesting cleanup within the parser.

by jcid＠dillo.org

Hi there, This is an important patchset that's just been committed. There're plenty of details in the hg comments (hg log -v). This are changes that affect the way dillo copes with Tag Soup (i.e. bad formed HTML). The idea is to create a valid doc tree before passing it to Dw for rendering, so yes, rendering may change. Please check the comments, then browse your regular sites and give it a test drive, then send some feedback. At least in my case there were nice surprises! -- Cheers Jorge.-

June 22, 2016

Strange performance behaviour related to <span>

by sgeerken＠dillo.org

On Fri, Jun 17, 2016, Sebastian Geerken wrote: > Committed, thanks for the good work! Well, there were still some problems, but I've eventually found a better solution, which has just been committed. Sebastian

June 20, 2016

an experiment using mbed TLS

by eocene＠gmx.com

I wrote: > As for how practical it would ever be to have this code in the real > dillo someday, I think that comes down to: How good are distributions > at making security updates available for their more obscure packages? I realized this is an exceedingly trivial concern when compared with the fact that distributions have configured dillo with --enable-ssl for years despite the state of the old dpi and our all-caps warnings, thereby causing users to trust something they shouldn't.

June 20, 2016

an experiment using mbed TLS

by johannes.hofmann＠gmx.de

On Sun, Jun 19, 2016 at 08:48:28PM +0000, eocene wrote: > > I wanted to see what it would take to use mbed tls with dillo. > > I put a copy of the diff at http://www.dillo.org/test/mbedtls.diff > and I mention it here in case someone should want that one day. Excellent. I like mbedtls (formerly known as PolarSSL). The code looks much saner to me than openssl. Cheers, Johannes

June 20, 2016

an experiment using mbed TLS

by eocene＠gmx.com

> What's the main point/difference in using mbedtls vs OpenSSL? OpenSSL is such a notorious nightmare--one gets the distinct impression that the developers have not taken their responsibility seriously--that I was curious to try a different one that is supposed to be more comprehensible. mbed tls had been on my mind as something I might want to try someday after they implement OCSP stapling, but then I was just in the mood for it the other day. As for how practical it would ever be to have this code in the real dillo someday, I think that comes down to: How good are distributions at making security updates available for their more obscure packages? > > That said, it looks like netsurf uses curl, and curl can use any > > tls library you care to mention. And I'm pretty sure netsurf does > > javascript. > > Sorry, I don't get the point here. I was thinking how if someone did get the idea in their head that they wanted a small browser that works with mbed tls, dillo might not be the first choice.

June 20, 2016

an experiment using mbed TLS

by jcid＠dillo.org

Hi, On Sun, Jun 19, 2016 at 08:48:28PM +0000, eocene wrote: > > I wanted to see what it would take to use mbed tls with dillo. > > I put a copy of the diff at http://www.dillo.org/test/mbedtls.diff > and I mention it here in case someone should want that one day. What's the main point/difference in using mbedtls vs OpenSSL? > That said, it looks like netsurf uses curl, and curl can use any > tls library you care to mention. And I'm pretty sure netsurf does > javascript. Sorry, I don't get the point here. -- Cheers Jorge.-

June 20, 2016

an experiment using mbed TLS

by eocene＠gmx.com

I wanted to see what it would take to use mbed tls with dillo. I put a copy of the diff at http://www.dillo.org/test/mbedtls.diff and I mention it here in case someone should want that one day. That said, it looks like netsurf uses curl, and curl can use any tls library you care to mention. And I'm pretty sure netsurf does javascript.

June 19, 2016

ComplexButtonResource initial size

by sgeerken＠dillo.org

On Do, Jun 16, 2016, Jorge Arellano Cid wrote: > Hi Sebastian, > > While testing the design corrections of the parser's nesting handling, > I noticed ComplexButtonResource takes full width as initial size. > > e.g. A<button></button> > > I didn't find where to set its initial size. > > Would you mind giving it a look? Has been fixed, see recent commit. <button> is displayed as - dw::core::ui::Embed, referring to - dw::core::ui::ComplexButtonResource, implemented by - dw::fltk::ui::FltkComplexButtonResource, referring to another - dw::core::Widget (actually dw::Textblock). Furhermore, there is another viewport (Fltk widget) between the latter two, so that the latter widget/textblock is technically a toplevel widget. To make it behave similar to an inline widget, a new flag was introduced (treatAsInline). Sebastian

June 18, 2016

Strange performance behaviour related to <span>

by jcid＠dillo.org

On Fri, Jun 17, 2016 at 11:10:24AM +0200, Sebastian Geerken wrote: > Hi Jorge, > > > > Still, Dw should handle this. Look at this example: > > > > > > (for i in $(seq 1 20); do echo '<div style="float:left"><div></div><div style="display:table"></div>'; done) > tmp.html; src/dillo tmp.html > > > > > > Here, only some <div>s at the end are open (and it is simple to make > > > the snippet correct HTML), but it still takes much time. This looks > > > still like a Dw problem, especially since it is much faster if you > > > leave the float definition away. > > > > Yes, I see. > > > > There's indeed a problem in Dw. > > > > After some inspired reflections on the exponential nature of the > > time taken, and the corresponding tests&experiments, I got to a simple patch > > that solves all the cases we've seen so far in this thread! > > > > It makes all cpu hog cases render as fast as expected, and even makes > > some "unrelated" sites I visit render twice faster or so. > > > > I'm not postulating this to be *the* correct solution, but is a strong > > hint as to what is wrong. I didn't want to mess with mustQueueResize > > subtleties, so I'm more than happy with this one-liner: > > > > > > diff -r bcf30ff0896c dw/textblock.cc > > --- a/dw/textblock.cc Thu Jun 16 16:27:56 2016 -0400 > > +++ b/dw/textblock.cc Thu Jun 16 23:21:40 2016 -0400 > > @@ -3034,7 +3034,8 @@ void Textblock::queueDrawRange (int inde > > > > void Textblock::updateReference (int ref) > > { > > - queueResize (ref, false); > > + if (lines->size ()) > > + queueResize (ref, false); > > } > > > > > > HTH. > > Committed, thanks for the good work! Great! BTW, I've found quite useful to include a brief description of the patch and test cases in the hg comment, that way when I do an "hg blame" and try to find out why a certain line of code is there it's really helpful, and much easier to find than in a mail thread! As hg has no way to amend a published patch, adding a single whitespace char, and the extended comment as a new patch did the trick. This comment is easily readable with "hg log -v" -- Cheers Jorge.-

June 17, 2016

Strange performance behaviour related to <span>

by sgeerken＠dillo.org

Hi Jorge, > > Still, Dw should handle this. Look at this example: > > > > (for i in $(seq 1 20); do echo '<div style="float:left"><div></div><div style="display:table"></div>'; done) > tmp.html; src/dillo tmp.html > > > > Here, only some <div>s at the end are open (and it is simple to make > > the snippet correct HTML), but it still takes much time. This looks > > still like a Dw problem, especially since it is much faster if you > > leave the float definition away. > > Yes, I see. > > There's indeed a problem in Dw. > > After some inspired reflections on the exponential nature of the > time taken, and the corresponding tests&experiments, I got to a simple patch > that solves all the cases we've seen so far in this thread! > > It makes all cpu hog cases render as fast as expected, and even makes > some "unrelated" sites I visit render twice faster or so. > > I'm not postulating this to be *the* correct solution, but is a strong > hint as to what is wrong. I didn't want to mess with mustQueueResize > subtleties, so I'm more than happy with this one-liner: > > > diff -r bcf30ff0896c dw/textblock.cc > --- a/dw/textblock.cc Thu Jun 16 16:27:56 2016 -0400 > +++ b/dw/textblock.cc Thu Jun 16 23:21:40 2016 -0400 > @@ -3034,7 +3034,8 @@ void Textblock::queueDrawRange (int inde > > void Textblock::updateReference (int ref) > { > - queueResize (ref, false); > + if (lines->size ()) > + queueResize (ref, false); > } > > > HTH. Committed, thanks for the good work! I've looked at this problem, too, and found out that the interaction between queueResize and markSizeChange was not perfect. I've not yet examined how it works now, but the performance problems seem to be solved (including the original case), so I'll assign a lower priority to this. Sebastian

June 17, 2016