- Dillo-dev - lists.mailman3.com

valgrind errors

by eocene＠gmx.com

I wrote: > Was just having a look at the valgrind errors, and I think the > main one is in textblock.cc: > > int leftBorder = boxOffsetX () + leftInnerPadding > + (lines->size () == 0 ? line1OffsetEff : 0); > > leftBorder being set to line1OffsetEff when line1OffsetEff > has not been initialized. I should have said 'making use of the value of line1OffsetEff'. I wasn't paying any attention to the specifics of the calculation because textblock has changed a lot since I worked on it...

June 22, 2016

valgrind errors

by eocene＠gmx.com

Another one is containerAllocationState not getting initialized in OOFPositionedMgr.

June 22, 2016

valgrind errors

by eocene＠gmx.com

Was just having a look at the valgrind errors, and I think the main one is in textblock.cc: int leftBorder = boxOffsetX () + leftInnerPadding + (lines->size () == 0 ? line1OffsetEff : 0); leftBorder being set to line1OffsetEff when line1OffsetEff has not been initialized.

June 22, 2016

New design of tag nesting cleanup within the parser.

by eocene＠gmx.com

Jorge wrote: > Yes, "must be closed" is the intended meaning. > > Is there a way to have the _same_ message in a softer tone? Umm...in ordinary spoken English, we'd be more likely to say "has to be closed", but I might be missing what you're getting at.

June 22, 2016

New design of tag nesting cleanup within the parser.

by jcid＠dillo.org

Hi, On Wed, Jun 22, 2016 at 05:18:12PM +0000, eocene wrote: > Jorge wrote: > > Please check the comments, then browse your regular sites and give it > > a test drive, then send some feedback. Oh, I meant the comments in hg! :-) Anyway checking the bug meter's messages doesn't hurt. > A fltk.org page gave the warning > "...<small> must have been closed before </td>..." > and it wasn't clear what that meant. > > The src has > <td><small>some text</td> > > and in that case "<small> must be closed before </td>" sounds right > to me. Oh, I didn't know until now that the phrase "must have been" can have two meanings in english. Yes, "must be closed" is the intended meaning. Is there a way to have the _same_ message in a softer tone? -- Cheers Jorge.-

June 22, 2016

New design of tag nesting cleanup within the parser.

by jcid＠dillo.org

On Wed, Jun 22, 2016 at 02:18:00PM +0000, eocene wrote: > Jorge wrote: > > Please check the comments, then browse your regular sites and give it > > a test drive, then send some feedback. > > The links to articles on arstechnica.com aren't working for me today. > The bug meter has lots of "<a> can't contain <figure>". Yes, this is the new HTML5's "transparent" mode. A is a transparent container, which is not yet handled by dillo. Let me think it a bit... -- Cheers Jorge.-

June 22, 2016

New design of tag nesting cleanup within the parser.

by eocene＠gmx.com

Jorge wrote: > Please check the comments, then browse your regular sites and give it > a test drive, then send some feedback. A fltk.org page gave the warning "...<small> must have been closed before </td>..." and it wasn't clear what that meant. The src has <td><small>some text</td> and in that case "<small> must be closed before </td>" sounds right to me.

June 22, 2016

New design of tag nesting cleanup within the parser.

by nick＠linicks.net

On Wed, 22 Jun 2016 14:18:00 +0000 eocene <eocene at gmx.com> wrote: > Jorge wrote: > > Please check the comments, then browse your regular sites and give > > it a test drive, then send some feedback. > > The links to articles on arstechnica.com aren't working for me today. > The bug meter has lots of "<a> can't contain <figure>". > /lists.dillo.org/cgi-bin/mailman/listinfo/dillo-dev Yes, same type of errors/no link works on the BBC news site: http://www.bbc.co.uk/news 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 22, 2016

New design of tag nesting cleanup within the parser.

by eocene＠gmx.com

Jorge wrote: > Please check the comments, then browse your regular sites and give it > a test drive, then send some feedback. The links to articles on arstechnica.com aren't working for me today. The bug meter has lots of "<a> can't contain <figure>".

June 22, 2016

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 21, 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

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

Strange performance behaviour related to <span>

by jcid＠dillo.org

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. You can surely imagine the mess textblock and OOFM get trapped-in when trying to make sense of it all! :) 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. HTH. -- Cheers Jorge.-

June 6, 2016

Strange performance behaviour related to <span>

by sgeerken＠dillo.org

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. Sebastian

June 5, 2016

Patch: Zero detected HTML errors

by nick＠linicks.net

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. Regards, 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 5, 2016

Missing anchor - strange results

by nick＠linicks.net

On Sat, 4 Jun 2016 20:48:28 -0400 Jorge Arellano Cid <jcid at dillo.org> wrote: > > > Strange one to find - Dillo is great at finding stuff like this - > > > other browsers hide it all. > > > > Good catch, good news, > > > > I'm testing a patch for this one (part 2 of patch 4557). > > Committed. Works perfectly - thanks! 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 5, 2016

Missing anchor - strange results

by jcid＠dillo.org

On Sat, Jun 04, 2016 at 05:54:09PM -0400, Jorge Arellano Cid wrote: > On Sat, Jun 04, 2016 at 09:45:31PM +0100, Nick Warne wrote: > > On Sat, 4 Jun 2016 16:51:09 +0000 > > eocene <eocene at gmx.com> wrote: > > > > > On Sat, Jun 04, 2016 at 04:21:24PM +0100, Nick Warne wrote: > > > > Hi All, > > > > > > > > I don't know what to make of this one: > > > > > > > > http://apod.nasa.gov/apod/ap160604.html > > > > > > > > It appears line 49 in the source is missing a </a> which seems make > > > > the whole paragraph a URL, but the other URLs in there are still > > > > shown/valid if you hover over the text. > > > > > > > > Viewing the source, no errors are reported by Dillo either. > > > > > > > > So do we get a URL embedding all the other URLs on the plain text > > > > in between? > > > > > > Hmm, it does say in HTML5 for the A element: > > > > > > "Content model: > > > > > > Transparent, but there must be no interactive content or a element > > > descendants." > > > > > > ...so perhaps one should be closed with a warning when another is > > > seen. > > > > Yes, also surely there is no case to do embedded <a href=... <a > > href=...</a> </a> is there (even though this was a typo)? > > > > Strange one to find - Dillo is great at finding stuff like this - other > > browsers hide it all. > > Good catch, good news, > > I'm testing a patch for this one (part 2 of patch 4557). Committed. -- Cheers Jorge.-

June 5, 2016

Missing anchor - strange results

by jcid＠dillo.org

On Sat, Jun 04, 2016 at 09:45:31PM +0100, Nick Warne wrote: > On Sat, 4 Jun 2016 16:51:09 +0000 > eocene <eocene at gmx.com> wrote: > > > On Sat, Jun 04, 2016 at 04:21:24PM +0100, Nick Warne wrote: > > > Hi All, > > > > > > I don't know what to make of this one: > > > > > > http://apod.nasa.gov/apod/ap160604.html > > > > > > It appears line 49 in the source is missing a </a> which seems make > > > the whole paragraph a URL, but the other URLs in there are still > > > shown/valid if you hover over the text. > > > > > > Viewing the source, no errors are reported by Dillo either. > > > > > > So do we get a URL embedding all the other URLs on the plain text > > > in between? > > > > Hmm, it does say in HTML5 for the A element: > > > > "Content model: > > > > Transparent, but there must be no interactive content or a element > > descendants." > > > > ...so perhaps one should be closed with a warning when another is > > seen. > > Yes, also surely there is no case to do embedded <a href=... <a > href=...</a> </a> is there (even though this was a typo)? > > Strange one to find - Dillo is great at finding stuff like this - other > browsers hide it all. Good catch, good news, I'm testing a patch for this one (part 2 of patch 4557). -- Cheers Jorge.-

June 4, 2016

Missing anchor - strange results

by nick＠linicks.net

On Sat, 4 Jun 2016 16:51:09 +0000 eocene <eocene at gmx.com> wrote: > On Sat, Jun 04, 2016 at 04:21:24PM +0100, Nick Warne wrote: > > Hi All, > > > > I don't know what to make of this one: > > > > http://apod.nasa.gov/apod/ap160604.html > > > > It appears line 49 in the source is missing a </a> which seems make > > the whole paragraph a URL, but the other URLs in there are still > > shown/valid if you hover over the text. > > > > Viewing the source, no errors are reported by Dillo either. > > > > So do we get a URL embedding all the other URLs on the plain text > > in between? > > Hmm, it does say in HTML5 for the A element: > > "Content model: > > Transparent, but there must be no interactive content or a element > descendants." > > ...so perhaps one should be closed with a warning when another is > seen. Yes, also surely there is no case to do embedded <a href=... <a href=...</a> </a> is there (even though this was a typo)? Strange one to find - Dillo is great at finding stuff like this - other browsers hide it all. 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 4, 2016

Missing anchor - strange results

by eocene＠gmx.com

On Sat, Jun 04, 2016 at 04:21:24PM +0100, Nick Warne wrote: > Hi All, > > I don't know what to make of this one: > > http://apod.nasa.gov/apod/ap160604.html > > It appears line 49 in the source is missing a </a> which seems make the > whole paragraph a URL, but the other URLs in there are still > shown/valid if you hover over the text. > > Viewing the source, no errors are reported by Dillo either. > > So do we get a URL embedding all the other URLs on the plain text > in between? Hmm, it does say in HTML5 for the A element: "Content model: Transparent, but there must be no interactive content or a element descendants." ...so perhaps one should be closed with a warning when another is seen.

June 4, 2016

Missing anchor - strange results

by nick＠linicks.net

Hi All, I don't know what to make of this one: http://apod.nasa.gov/apod/ap160604.html It appears line 49 in the source is missing a </a> which seems make the whole paragraph a URL, but the other URLs in there are still shown/valid if you hover over the text. Viewing the source, no errors are reported by Dillo either. So do we get a URL embedding all the other URLs on the plain text in between? 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 4, 2016

Download bug

by jcid＠dillo.org

On Sat, May 28, 2016 at 12:56:26PM +0100, Nick Warne wrote: > Hi All, > > Great work going on - Dillo is now my first choice of browser (apart > from when I need to do banking stuff and such that relies on heavy JS > crap). > > I just noticed that when using the download feature (mjpeg etc.), Dillo > default is to $HOME/dillodown > > Well, is that directory doesn't exist (I had to create it), the > download aborts. > > Perhaps specify a .dillo/downloads directory created at install? Please read your dillorc. (then read the one in the hg repo, or help page, and make your choices) -- Cheers Jorge.-

May 29, 2016

Download bug

by nick＠linicks.net

Hi All, Great work going on - Dillo is now my first choice of browser (apart from when I need to do banking stuff and such that relies on heavy JS crap). I just noticed that when using the download feature (mjpeg etc.), Dillo default is to $HOME/dillodown Well, is that directory doesn't exist (I had to create it), the download aborts. Perhaps specify a .dillo/downloads directory created at install? 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"

May 28, 2016

image overlaps text

by sgeerken＠dillo.org

On Sat, May 21, 2016, Sebastian Geerken wrote: > [test case n33180d.html ...] > > "rightBorder" goes back to the attribute "newLineRightBorder", which > is set in "calcBorders". If you look at the messages here, you'll > notice that the result of "getGeneratorRest" is -194, which is too > small (it should be 0 here). Further examination shows: > > - getGeneratorWidth (this widget) = 194: ok > - getGeneratorWidth (container) = 0: too small > > Examining the latter shows than the width of the child (194) is not > yet regarded here. > > I'm not yet sure how to fix this best; most probably a size > recalculation should be queued under certain circumstances. At least this one has been fixed, see recent change. Jorge, I'll look at your test cases now. Sebastian

May 27, 2016

Dillo ignores new lines in submitting and rendering in HTML forms

by nick＠linicks.net

Two examples that I posted tonight: Here, the <code></code> section has no line breaks, but renders ok in FF etc. http://www.perlmonks.org/?node_id=1164105 This one I posted with Dillo, but the <enter> line breaks are gone so all end up on one line. http://www.boards2go.com/boards/board.cgi?action=read&id=1464205605.38914&u… 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"

May 25, 2016

image overlaps text

by jcid＠dillo.org

Hi Sebastian, On Sun, May 22, 2016 at 11:29:34AM -0400, Jorge Arellano Cid wrote: > [...] > Short story: I have a working patch. > > It solves the overlap (not 1.- 2.- and 3.-). It seems there're > a few different bugs here. > > It's not as clean as I'd like, but it already is a proof of concept. > I'll try to understand the issues better and clean it up. > > AFAIS it can have an effect on general rendering of floats. Currently, > I dont know if it's related to n33180d.html. > > I'll try to share my findings this monday (unless you'd like to > look at it "as is" now). OK, here is what I've found so far. Two patches attached plus some testcases. The first patch is the fix for o4.html. The second one also tackles o5.html and o6.html (progressive patches). AFAIU the gist of the problem is in getGeneratorX() not returning the correct value on some cases. It is called in four places inside ooffloatsmgr.cc so other functions are sometimes making calculations with a wrong x value. The second problem is getFloatsSize() returning the widest among a list of floats instead of a cumulative sum of widths inside a cretain range (the second patch just adds to ilustrate the point). Some tests: o4.html o5.html o6.html some-sites [1] [2] First patch: OK Wrong Wrong OK (1) (2) Second patch: OK OK OK +/- (3) (4) (1), (2): No images over text. As it was before. (3) : Some images overlap text. (4) : Different background color! some rendering diffs. [1] http://www.pravdareport.com/} [2] http://tinyurl.com/j2uzps9 It looks like fixing getGeneratorX() paves the way for fixing hidden bugs. Also fixing getFloatsSize() can shed light for a patch for n33180d.html. Please get back to me when you've processed this so we can coordinate. HTH -- Cheers Jorge.-

May 23, 2016

image overlaps text

by jcid＠dillo.org

Hi Sebastian, On Sat, May 21, 2016 at 05:21:07PM +0200, Sebastian Geerken wrote: > On Fri, May 20, 2016, Sebastian Geerken wrote: > > Hi Jorge, > > > > On Fr, Mai 20, 2016, Jorge Arellano Cid wrote: > > > The attached tetscase is a slight variation of the previous one. > > > > > > Comparing rendering behaviour with Firefox here shows some interesting > > > facts/bugs/design-decisions: > > > > > > 1.- FF links the olive div's width to viewport width only. > > > Dillo links it to viewport and its own child width. > > > > Dillo has a rather (over-)simple definition as what do draw with the > > background color. I regard this as a low-priority issue, which can be > > solved after the next release. I was thinking more in the line of the outmost div's width side-effects on its children rendering. Anyway, this may be a different bug, read on... > > > 2.- When splitting the first sentence (in olive div), by narrowing the > > > viewport, text in the teal div is also split! > > > 3.- After 2.-, when widening the viewport, text in olive widens, but text > > > in teal not! (reload, does the trick). > > > > I'll write more on this later. > > I've looked a bit at this, and it seems to look like another case I > was working on, so it may be best to fix the latter, and hopefully the > former is fixed, too. > > I'll describe my analysis so far, which may give you a better > understanding of the code. Good news on this one! (i.e. the overlapped image/text in o4.html). After reading your description of the other problem (n33180d.html), especially the part where you wonder "why", it became clear that the code was meant to handle it, so I turned to try to find what may possible be going astray there. Short story: I have a working patch. It solves the overlap (not 1.- 2.- and 3.-). It seems there're a few different bugs here. It's not as clean as I'd like, but it already is a proof of concept. I'll try to understand the issues better and clean it up. AFAIS it can have an effect on general rendering of floats. Currently, I dont know if it's related to n33180d.html. I'll try to share my findings this monday (unless you'd like to look at it "as is" now). -- Cheers Jorge.-

May 22, 2016

image overlaps text

by sgeerken＠dillo.org

On Fri, May 20, 2016, Sebastian Geerken wrote: > Hi Jorge, > > On Fr, Mai 20, 2016, Jorge Arellano Cid wrote: > > The attached tetscase is a slight variation of the previous one. > > > > Comparing rendering behaviour with Firefox here shows some interesting > > facts/bugs/design-decisions: > > > > 1.- FF links the olive div's width to viewport width only. > > Dillo links it to viewport and its own child width. > > Dillo has a rather (over-)simple definition as what do draw with the > background color. I regard this as a low-priority issue, which can be > solved after the next release. > > > 2.- When splitting the first sentence (in olive div), by narrowing the > > viewport, text in the teal div is also split! > > 3.- After 2.-, when widening the viewport, text in olive widens, but text > > in teal not! (reload, does the trick). > > I'll write more on this later. I've looked a bit at this, and it seems to look like another case I was working on, so it may be best to fix the latter, and hopefully the former is fixed, too. I'll describe my analysis so far, which may give you a better understanding of the code. The test case is attached. Notice that there is a float within a float, with no sizes explicitly defined. Dillo (and also FF) will use the maximal width as size, as long as it fits into the available width (which is the case here). It should look like (and looks like in FF): abcdefghijkl float mnopqrstuvwx It actually is drawn by dillo like this: float abcdefghijkl mnopqrstuvwx There are two problems: 1. Why is the word "abcdefghijkl" in the second line? 2. Why is the float positioned too far right? Let's examine problem 1. I'm using RTFL (<http://home.gna.org/rtfl/>; use the latest version from SVN, not the release, and make sure you have the graphviz library installed). To enable the RTFL messages, run the dillo configure script with "--enable-rtfl". Run: $ src/dillo n33180d.html | rtfl-objview -OM -a "*" -A draw (I'm also adding "-v 'emacsclient -n %n %p'", and you may use the script rtfl-filter-out-classes.) The relevant textblock is the lower right one (some guessing, and examine the attributes). Go to the attribute "lines/0/firstWord", select the last (which is the relevant) assignment and press Ctrl+A. This way, we can focus on what has happened before the first line is eventually created. Then examine "words/0/badnessAndPenalty" (again last entry); you'll see "... vs. -31" here, which means that when calculating the badness (used for line breaking), an ideal width of -31 was assumed, which is obviously an icorrect value. The "stack trace" function (Ctrl+T) leads to "accumulateWordData", in which "calcLineBreak" is used to calculate this value. Press Ctrl+A again to hide everything behind the last command within "calcLineBreak" ("leave"). What values go into the return value? - lineBreakWidth = 194, which looks plausible. (You can examine this further: this is calculates by "getAvailWidth", which actually returns the maximal width.) - leftInnerPadding = 0 (ok) - leftBorder = 0 (ok) - rightBorder = 225, which is obviously too large. "rightBorder" goes back to the attribute "newLineRightBorder", which is set in "calcBorders". If you look at the messages here, you'll notice that the result of "getGeneratorRest" is -194, which is too small (it should be 0 here). Further examination shows: - getGeneratorWidth (this widget) = 194: ok - getGeneratorWidth (container) = 0: too small Examining the latter shows than the width of the child (194) is not yet regarded here. I'm not yet sure how to fix this best; most probably a size recalculation should be queued under certain circumstances. Sebastian

May 21, 2016

image overlaps text

by sgeerken＠dillo.org

Hi Jorge, On Fr, Mai 20, 2016, Jorge Arellano Cid wrote: > The attached tetscase is a slight variation of the previous one. > > Comparing rendering behaviour with Firefox here shows some interesting > facts/bugs/design-decisions: > > 1.- FF links the olive div's width to viewport width only. > Dillo links it to viewport and its own child width. Dillo has a rather (over-)simple definition as what do draw with the background color. I regard this as a low-priority issue, which can be solved after the next release. > 2.- When splitting the first sentence (in olive div), by narrowing the > viewport, text in the teal div is also split! > 3.- After 2.-, when widening the viewport, text in olive widens, but text > in teal not! (reload, does the trick). I'll write more on this later. Sebastian

May 20, 2016

CPU hog bug with https?

by jcid＠dillo.org

On Fri, May 20, 2016 at 09:45:30AM +0200, Diego . wrote: > Occasional problem with the text under the float seems to have gone at > www.astronautix.com too > > For example: > http://www.astronautix.com/lvs/n1.htm Ack. > Very good work. Thanks, in the name of the team. Credit where credit's Due, Sebastian made great progress with GROWS2. We support each other as we are able to. -- Cheers Jorge.-

May 20, 2016

image overlaps text

by jcid＠dillo.org

Hi Sebastian, On Sat, Apr 30, 2016 at 01:31:48PM +0200, Sebastian Geerken wrote: > On Fr, Apr 29, 2016, Jorge Arellano Cid wrote: > > On Fri, Apr 29, 2016 at 06:41:32PM +0200, Sebastian Geerken wrote: > > > On Fri, Apr 29, 2016, Nick Warne wrote: > > > > > > > > > > > > On 29/04/16 16:46, Alexander Voigt wrote: > > > > >I noticed, that in current Dillo (tip) there are cases where images > > > > >overlap surrounding text, making in unreadable. Here is an example page: > > > > > > > > > > https://netzpolitik.org/2016/massenbeschlagnahme-von-mobiltelefonen-in-leip… > > > > > > > > Strange, renders here OK (latest hg pull). > > > > > > As I wrote, this is hard to reproduce. > > > > Yes. > > > > (I can't reproduce it with your best URL :) > > > > Fortunately, today I managed to find&reduce a case that works all the time > > here. Attached it goes. Just resize horizontally to see the overlap. > > > > I hope it works there! > > Thanks, Jorge, for the perfect testcase. So far, I've tracked down the > problem, but I'm not yet sure how to fix it. Hopefully, the fix will > also solve the other issues with overlapping floats. The attached tetscase is a slight variation of the previous one. Comparing rendering behaviour with Firefox here shows some interesting facts/bugs/design-decisions: 1.- FF links the olive div's width to viewport width only. Dillo links it to viewport and its own child width. 2.- When splitting the first sentence (in olive div), by narrowing the viewport, text in the teal div is also split! 3.- After 2.-, when widening the viewport, text in olive widens, but text in teal not! (reload, does the trick). As usual, since a few years, following FF in these corner cases is the safe chioce. I'd like to dig into it with a view to learn more about rendering floats. Would you please explain a bit what you've found, which of the above points you'd recommend me to start with, and spill some suggestions on what parts of the code/design are most probably responsible for it. -- Cheers Jorge.-

May 20, 2016

Dillo_grows merged

by jcid＠dillo.org

On Thu, May 19, 2016 at 12:02:47PM -0400, Jorge Arellano Cid wrote: > On Wed, May 18, 2016 at 11:11:17PM +0200, Sebastian Geerken wrote: > > > > > The attached patch works OK for the text search, but I don't know > > > > > whether it fits with the overall design. > > > > > > > > > > It *seems to fit* but I'd prefer you to check it. ;) > > > > > > > > I've just pushed a variant of your patch, please give it a try. > > > > > > Much better! > > > > > > I still wander what a negative sectionIndex means (0 is in flow). > > > It takes negative values sometimes. It should be commented. > > > > It happens when iterating back gets behind 0. Likewise, it may become > > larger than NUM_SECTIONS - 1, when iterating forward. > > Yep, it also happens with "index". > > > > > > What should getPart() do upon a negative sectionIndex? > > > > It should not be called, actually. This should be checked, first. > > OK, I've rewrote next() and prev() with full protection and > made clear semantics for the corner cases in setValues(). > > As a side effect, the code got shorter and easier to read. > > Now in testing phase... Committed. -- Cheers Jorge.-

May 19, 2016

Dillo_grows merged

by jcid＠dillo.org

On Wed, May 18, 2016 at 11:11:17PM +0200, Sebastian Geerken wrote: > > > > The attached patch works OK for the text search, but I don't know > > > > whether it fits with the overall design. > > > > > > > > It *seems to fit* but I'd prefer you to check it. ;) > > > > > > I've just pushed a variant of your patch, please give it a try. > > > > Much better! > > > > I still wander what a negative sectionIndex means (0 is in flow). > > It takes negative values sometimes. It should be commented. > > It happens when iterating back gets behind 0. Likewise, it may become > larger than NUM_SECTIONS - 1, when iterating forward. Yep, it also happens with "index". > > > What should getPart() do upon a negative sectionIndex? > > It should not be called, actually. This should be checked, first. OK, I've rewrote next() and prev() with full protection and made clear semantics for the corner cases in setValues(). As a side effect, the code got shorter and easier to read. Now in testing phase... -- Cheers Jorge.-

May 19, 2016

CPU hog bug with https?

by jcid＠dillo.org

On Thu, May 19, 2016 at 06:06:32AM +0200, Sebastian Geerken wrote: > On Mi, Mai 18, 2016, Jorge Arellano Cid wrote: > > On Wed, May 18, 2016 at 11:08:03PM +0200, Sebastian Geerken wrote: > > > It also seems to fix the problems with > > > netzpolitik.org and nachdenkseiten.de. (Others please check this, > > > too.) > > > > Both sites render blazingly fast here. > > The (occasional) problem with the text under the float seems to have > gone. Oh, I see. nachdenkseiten.de showed the bug 4 of 4 times without the patch and none with patched version. netzpolitik.org doesn't show the bug here. Neither from net, nor locally. -- Cheers Jorge.-

May 19, 2016

CPU hog bug with https?

by sgeerken＠dillo.org

On Mi, Mai 18, 2016, Jorge Arellano Cid wrote: > On Wed, May 18, 2016 at 11:08:03PM +0200, Sebastian Geerken wrote: > > It also seems to fix the problems with > > netzpolitik.org and nachdenkseiten.de. (Others please check this, > > too.) > > Both sites render blazingly fast here. The (occasional) problem with the text under the float seems to have gone. Sebastian

May 19, 2016

CPU hog bug with https?

by jcid＠dillo.org

On Wed, May 18, 2016 at 11:08:03PM +0200, Sebastian Geerken wrote: > Hi Jorge, > > On Di, Mai 17, 2016, Jorge Arellano Cid wrote: > > On Sun, May 01, 2016 at 09:58:53PM +0200, Sebastian Geerken wrote: > > > On So, Mai 01, 2016, Jorge Arellano Cid wrote: > > > > Hi, > > > > > > > > If I start current dillo with [1], an https dialog springs > > > > (untrusted certificate). Answering "continue" gets into a CPU hog, > > > > answering "cancel" allows reading the page with no problems. > > > > > > > > FWIW, I've done that lots of times with other sites, and this is the > > > > first CPU hog I get accross. > > > > > > > > > > > > [1] https://linux.slashdot.org/comments.pl?sid=5852295&cid=48188823 > > > > > > I can reproduce this. However, profiling shows rather problems in the > > > rendering code (dw::core::Widget::queueResize etc.), so the problem is > > > probably not related to HTTPS. > > > > > > Also, mirroring this page ("wget -pkH") and displaying it locally > > > shows the same symptoms. > > > > > > Looks that this belongs rather on my todo list. > > > > Good news on this one. > > > > Patch committed! > > Thanks for the good work! You're welcomed. I aim at reducing your workload so you can focus on corework. BTW, the speed improvements introduced with GROWS2, and the way I picture dillo's rendering once floats/absolutes work right are quite motivating. ;) > It also seems to fix the problems with > netzpolitik.org and nachdenkseiten.de. (Others please check this, > too.) Both sites render blazingly fast here. > > [...] > > It was hard to find, sometimes backtraces gave near 85 or more nested calls, > > full of different functions. There was no CPU lock because it finally solved > > the page (after more than two minutes in my machine). > > > > It took a few days of work, by reducing the testcase (a slashdot page) by: > > * removing the scripting > > * removing one stylesheet completely (no bug without CSS). > > * removing sections of the HTML code > > while checking the bug was still reproducible. And checking the backtrace > > stack from gdb from time to time. gprof may have served also, but as there > > where so many functions I decided to keep reducing the case. > > > > This is a trial&error iteration process. > > > > At some point I could clean the testcase enough to run tidy on it, and > > no, it wasn't a tag soup corner case. > > > > Back to reducing the testcase. It started to solve in less time, but still > > hogging my CPU for near 20 secs.. > > > > Then suddenly at some point, gdb's backtrace was still near the hundred > > in depth, but a few functions remained. Studying the code in the involved > > functions made me finally spot the hiding bug. Trivial to fix, but very > > hard to find. > > > > For this case, what took more than 2 minutes to render, now takes near 1/8 > > second. ;-) > > Yes, this is the usual way I track down bugs, too. This is much > simpler for rendering bugs, which can be preserved while simplifying > the page. This kind of bug is much more difficult since the effect > (taking too much time) vanishes the more the simpler the page gets. Good point. -- Cheers Jorge.-

May 18, 2016

Dillo_grows merged

by sgeerken＠dillo.org

> > > The attached patch works OK for the text search, but I don't know > > > whether it fits with the overall design. > > > > > > It *seems to fit* but I'd prefer you to check it. ;) > > > > I've just pushed a variant of your patch, please give it a try. > > Much better! > > I still wander what a negative sectionIndex means (0 is in flow). > It takes negative values sometimes. It should be commented. It happens when iterating back gets behind 0. Likewise, it may become larger than NUM_SECTIONS - 1, when iterating forward. > What should getPart() do upon a negative sectionIndex? It should not be called, actually. This should be checked, first. Sebastian

May 18, 2016