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

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

ComplexButtonResource initial size

by jcid＠dillo.org

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? -- Cheers Jorge.-

June 17, 2016

Strange performance behaviour related to <span>

by jcid＠dillo.org

Hi Sebastian, Good news here, I have patches for both problems! On Mon, Jun 06, 2016 at 10:13:15PM +0200, Sebastian Geerken wrote: > On Mo, Jun 06, 2016, Jorge Arellano Cid wrote: > > On Sun, Jun 05, 2016 at 11:34:13PM +0200, Sebastian Geerken wrote: > > > Hi! > > > > > > I've stripped down one testcase to a sequence of simple HTML snippets. > > > Try > > > > > > (for i in $(seq 1 20); do echo '<div style="float:left"><div></div><div style="display:table"><span></div></div>'; done) > tmp.html; dillo tmp.html > > > > > > and the development version of dillo hangs for a while. You may vary > > > the number (second argument of seq). > > > > > > If you look at the file tmp.html, you'll notice that it is incorrect > > > HTML. Interrestinly, leaving the <span> away still results in > > > incorrect and deeply nested HTML, but dillo is much faster: > > > > > > (for i in $(seq 1 20); do echo '<div style="float:left"><div></div><div style="display:table"></div></div>'; done) > tmp.html; dillo tmp.html > > > > > > Dillo 3.0.5 is fast in both cases. > > > > > > Does anyone have an idea what effect the <span> has? > > > > > > I've already run gprof, but the result does not look very meaningful > > > at a first glance. > > > > OK, after some experiments I see what happens. > > > > If you close the SPAN element, it's fast again. > > > > The problem lies in how the parser handles bad HTML, and how > > the rendering deals with it afterwards. > > > > In this case the span is left open, and so we end with an anomalous > > tree where an inline container has 20 levels of block containers > > inside inline containers. > > I thought something like this. I'm currently testing a patch for the nesting problem in the parser, and so far it works very well. I expect to commit it next week. > > You can surely imagine the mess textblock and OOFM get trapped-in > > when trying to make sense of it all! :) > > 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. > > > Good news, I already have a working patch. > > > > It needs some testing because it constitutes a big change in how > > we deal with bad-formed HTML, but so far it makes more sense than what > > we have now. > > > > If you need the patch quick just drop me a note. > > Take your time. Big patch here, as stated above, probably committed next week. -- Cheers Jorge.-

June 17, 2016

Bug report - enterpress_forces_submit; mouse cursor wonky

by nick＠linicks.net

Hi all, Hard one to explain. First some info; I am running: Slackware 14.1 Xfce4 4.10.0 Latest stable kernel 3.18.35 (updated today) Now, I have a word search/dictionary page with several fields, and for some reason Dillo needs to use the mouse to 'process' the submit form - I haven't investigated what can be wrong with my HTML to make Dillo just use 'enter' to 'submit' yet. I added dillorc option enterpress_forces_submit=YES and now the page 'submit' works with the enter key. But when doing so, sometimes the mouse cursor disappears altogether afterwards (but it is still there as in the WM toolbar it appears again) You can see the Dillo toolbar icons depress but no mouse. Sometimes the mouse cursor changes to a 'I' and stays like that (in Dillo). The behaviour is totally random. The page to test is here: https://linicks.net/AnAdIc/ Just use the first field to mess around in. Try 'dillo' first, then just add extra letters or other words to test (as Dillo saves the cache - we need to refresh it). Nick -- Gosh that takes me back... or is it forward? That's the trouble with time travel, you never can tell." -- Doctor Who "Androids of Tara"

June 8, 2016

Left border show on the top border of other cell table when use border-collapse: collapse.

by darkspirit5000＠gmail.com

Hello. I have find a this playing with border-collapse: collapse. Left border show on the top border of other cell table. the attachment have minimal code html that breaks Sorry for my english Salud! Diego

June 8, 2016

Strange performance behaviour related to <span>

by sgeerken＠dillo.org

On Mo, Jun 06, 2016, Jorge Arellano Cid wrote: > On Sun, Jun 05, 2016 at 11:34:13PM +0200, Sebastian Geerken wrote: > > Hi! > > > > I've stripped down one testcase to a sequence of simple HTML snippets. > > Try > > > > (for i in $(seq 1 20); do echo '<div style="float:left"><div></div><div style="display:table"><span></div></div>'; done) > tmp.html; dillo tmp.html > > > > and the development version of dillo hangs for a while. You may vary > > the number (second argument of seq). > > > > If you look at the file tmp.html, you'll notice that it is incorrect > > HTML. Interrestinly, leaving the <span> away still results in > > incorrect and deeply nested HTML, but dillo is much faster: > > > > (for i in $(seq 1 20); do echo '<div style="float:left"><div></div><div style="display:table"></div></div>'; done) > tmp.html; dillo tmp.html > > > > Dillo 3.0.5 is fast in both cases. > > > > Does anyone have an idea what effect the <span> has? > > > > I've already run gprof, but the result does not look very meaningful > > at a first glance. > > OK, after some experiments I see what happens. > > If you close the SPAN element, it's fast again. > > The problem lies in how the parser handles bad HTML, and how > the rendering deals with it afterwards. > > In this case the span is left open, and so we end with an anomalous > tree where an inline container has 20 levels of block containers > inside inline containers. I thought something like this. > You can surely imagine the mess textblock and OOFM get trapped-in > when trying to make sense of it all! :) 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. > Good news, I already have a working patch. > > It needs some testing because it constitutes a big change in how > we deal with bad-formed HTML, but so far it makes more sense than what > we have now. > > If you need the patch quick just drop me a note. Take your time. Sebastian

June 6, 2016

Patch: Zero detected HTML errors

by nick＠linicks.net

On Sun, 5 Jun 2016 15:43:20 +0100 Nick Warne <nick at linicks.net> wrote: > Hi Devs, > > The sentence (Dillo message): > > Zero detected HTML errors! > > Is a bit contrived in English - this small patch (attached) changes it > to more legal/legible English usage. No replies or nacks/acks. Am I doing something wrong? Nick -- Gosh that takes me back... or is it forward? That's the trouble with time travel, you never can tell." -- Doctor Who "Androids of Tara"

June 6, 2016