- Dillo-dev - lists.mailman3.com

URL field / Loading page images / Refreshing DNS cache

by jgaffney＠lawrenceville.org

Johannes Hofmann <johannes.hofmann at gmx.de> writes: [...] >> > To make the switch to the current snapshot, I had, sadly, to terminate >> > an instance of 3.0.5 that had been running continuously for 90 days >> > without any issues. But to get that much up time it was necessary to >> > add a little code so that SIGUSR1 would call a_Dns_freeall() and >> > a_Dns_init(), otherwise (unless I am missing something) Dillo will >> > persist in using the cached lookup indefinitely and not detect when >> > the IP address has changed. So maybe some sort of key binding could >> > be added that would flush the cache when needed? >> >> good point. However I'd like to avoid another key-binding and rather >> do the right thing automatically. >> I could think of a general DNS entry timeout of a couple of seconds. >> In many cases DNS responses are cached at OS-level too respecting >> lifetime values given by the server. > > Firefox has an option to configure the DNS cache expiration > (network.dnsCacheExpiration). > Attached patch implements a similar feature for Dillo. > > Cheers, > Johannes That was fast! Thanks for this; I will try it out.

July 8, 2016

URL field / Loading page images / Refreshing DNS cache: Correction

by jgaffney＠lawrenceville.org

Jorge Arellano Cid <jcid at dillo.org> writes: > Hi John, > > On Thu, Jul 07, 2016 at 05:16:04PM -0400, John Gaffney wrote: >> [...] >> > In the current snapshot, the navigation bar has changed, and the URL >> > field does not seem to be taking into account font_factor -- with the >> > result that the window is smaller than the font height. You can test >> > this by setting, e.g., font_factor=2.0 in your dillorc (most >> > dramatically for a tiny panel with small icons). The issue seems to >> > be with this factor not being taken into account when bh and lh are >> > set in make_panel() in ui.cc. >> [...] >> >> I meant what is actually called the "location box," and on comparing >> the code for 3.0.5 to the snapshot of a few days ago, I see that there >> has been no change in the section of make_panel() in ui.cc that sets >> the values of bh, lh, etc. The change that has caused the problem is >> the addition of line 466 of ui.cc: >> >> i->textsize((int) rint(14.0 * prefs.font_factor)); >> >> But the height of the CustInput i is still set to lh, which does not >> take into account prefs.font_factor. > > Yes man. > > That was a quick patch (#4222 in Hg) for a larger font. > > I'll look at it after I finish a general rendering algorithm bug > I'm working in. > > Please be patient. > > BTW, do you really need a font size that enlarges the location box? or > would it be enough to clamp the font size to fit in? The second case is > a much simpler patch. No rush! I was just pointing out the issue; for myself, just commenting out the above line works just fine by reverting to the old behavior and smaller font size in the location bar.

July 8, 2016

URL field / Loading page images / Refreshing DNS cache: Correction

by jcid＠dillo.org

Hi John, On Thu, Jul 07, 2016 at 05:16:04PM -0400, John Gaffney wrote: > [...] > > In the current snapshot, the navigation bar has changed, and the URL > > field does not seem to be taking into account font_factor -- with the > > result that the window is smaller than the font height. You can test > > this by setting, e.g., font_factor=2.0 in your dillorc (most > > dramatically for a tiny panel with small icons). The issue seems to > > be with this factor not being taken into account when bh and lh are > > set in make_panel() in ui.cc. > [...] > > I meant what is actually called the "location box," and on comparing > the code for 3.0.5 to the snapshot of a few days ago, I see that there > has been no change in the section of make_panel() in ui.cc that sets > the values of bh, lh, etc. The change that has caused the problem is > the addition of line 466 of ui.cc: > > i->textsize((int) rint(14.0 * prefs.font_factor)); > > But the height of the CustInput i is still set to lh, which does not > take into account prefs.font_factor. Yes man. That was a quick patch (#4222 in Hg) for a larger font. I'll look at it after I finish a general rendering algorithm bug I'm working in. Please be patient. BTW, do you really need a font size that enlarges the location box? or would it be enough to clamp the font size to fit in? The second case is a much simpler patch. -- Cheers Jorge.-

July 8, 2016

URL field / Loading page images / Refreshing DNS cache

by johannes.hofmann＠gmx.de

On Wed, Jul 06, 2016 at 10:28:04AM +0200, Johannes Hofmann wrote: > On Tue, Jul 05, 2016 at 04:53:45PM -0400, John Gaffney wrote: > > First, a huge thanks to all the Dillo team for their efforts: I just > > switched from 3.0.5 to the current snapshot to try out the mbedtls > > changes, and I am wowed not only by this, but by all the improvements > > in rendering, etc. Great work! > > > > A few suggestions, all very minor, that might be added to the back of > > the development queue: > > > > In the current snapshot, the navigation bar has changed, and the URL > > field does not seem to be taking into account font_factor -- with the > > result that the window is smaller than the font height. You can test > > this by setting, e.g., font_factor=2.0 in your dillorc (most > > dramatically for a tiny panel with small icons). The issue seems to > > be with this factor not being taken into account when bh and lh are > > set in make_panel() in ui.cc. > > > > As far as I can see, one can use the context menu to download > > individual images on a page, or use the panel to toggle image > > loading. But if one wants not to download images in general, but to > > download all the images for some one page (e.g., a weather forecast > > page), then one has to toggle downloading of images on and then off > > again. Maybe a command could be added to KeysCommand_t in keys.hh, > > bound by default to something like Ctrl-i in keys.cc, with a > > corresponding call to a_Html_load_images() in handle() in ui.cc? > > > > To make the switch to the current snapshot, I had, sadly, to terminate > > an instance of 3.0.5 that had been running continuously for 90 days > > without any issues. But to get that much up time it was necessary to > > add a little code so that SIGUSR1 would call a_Dns_freeall() and > > a_Dns_init(), otherwise (unless I am missing something) Dillo will > > persist in using the cached lookup indefinitely and not detect when > > the IP address has changed. So maybe some sort of key binding could > > be added that would flush the cache when needed? > > good point. However I'd like to avoid another key-binding and rather > do the right thing automatically. > I could think of a general DNS entry timeout of a couple of seconds. > In many cases DNS responses are cached at OS-level too respecting > lifetime values given by the server. Firefox has an option to configure the DNS cache expiration (network.dnsCacheExpiration). Attached patch implements a similar feature for Dillo. Cheers, Johannes

July 8, 2016

CSS files downloaded only after reloading page

by eocene＠gmx.com

Alexander wrote: > Hi Dillo developers, > > the dillo version from the repository seems to have problems > downloading some CSS files the first time some pages are loaded. > Though, the remaining CSS files are downloaded when the page is > re-loaded using CTRL-r. > > Example page: > > https://netzpolitik.org/ > > Reproduce: > > 1) dillo https://netzpolitik.org/ > -> styles from some CSS files seem to be missing > 2) press CTRL-r > -> some new CSS file is downloaded and styles are applied > 3) press CTRL-r > -> some new CSS file is downloaded and styles are applied My guess is that it might have something to do with redirections, where we think we're ready but we don't have the final endpoint documents yet.

July 7, 2016

URL field / Loading page images / Refreshing DNS cache: Correction

by eocene＠gmx.com

John wrote: > I meant what is actually called the "location box," and on comparing > the code for 3.0.5 to the snapshot of a few days ago, I see that there > has been no change in the section of make_panel() in ui.cc that sets > the values of bh, lh, etc. The change that has caused the problem is > the addition of line 466 of ui.cc: > > i->textsize((int) rint(14.0 * prefs.font_factor)); > > But the height of the CustInput i is still set to lh, which does not > take into account prefs.font_factor. My recollection is that I increased the size of the text because I had gotten a computer with higher dpi, but I didn't want to mess with the sizes of the boxes because that's Jorge's.

July 7, 2016

URL field / Loading page images / Refreshing DNS cache: Correction

by jgaffney＠lawrenceville.org

[...] > In the current snapshot, the navigation bar has changed, and the URL > field does not seem to be taking into account font_factor -- with the > result that the window is smaller than the font height. You can test > this by setting, e.g., font_factor=2.0 in your dillorc (most > dramatically for a tiny panel with small icons). The issue seems to > be with this factor not being taken into account when bh and lh are > set in make_panel() in ui.cc. [...] I meant what is actually called the "location box," and on comparing the code for 3.0.5 to the snapshot of a few days ago, I see that there has been no change in the section of make_panel() in ui.cc that sets the values of bh, lh, etc. The change that has caused the problem is the addition of line 466 of ui.cc: i->textsize((int) rint(14.0 * prefs.font_factor)); But the height of the CustInput i is still set to lh, which does not take into account prefs.font_factor.

July 7, 2016

CSS files downloaded only after reloading page

by Hole.destructor＠gmx.de

Hi Dillo developers, the dillo version from the repository seems to have problems downloading some CSS files the first time some pages are loaded. Though, the remaining CSS files are downloaded when the page is re-loaded using CTRL-r. Example page: https://netzpolitik.org/ Reproduce: 1) dillo https://netzpolitik.org/ -> styles from some CSS files seem to be missing 2) press CTRL-r -> some new CSS file is downloaded and styles are applied 3) press CTRL-r -> some new CSS file is downloaded and styles are applied Best regards, Alex

July 7, 2016

URL field / Loading page images / Refreshing DNS cache

by johannes.hofmann＠gmx.de

On Tue, Jul 05, 2016 at 04:53:45PM -0400, John Gaffney wrote: > First, a huge thanks to all the Dillo team for their efforts: I just > switched from 3.0.5 to the current snapshot to try out the mbedtls > changes, and I am wowed not only by this, but by all the improvements > in rendering, etc. Great work! > > A few suggestions, all very minor, that might be added to the back of > the development queue: > > In the current snapshot, the navigation bar has changed, and the URL > field does not seem to be taking into account font_factor -- with the > result that the window is smaller than the font height. You can test > this by setting, e.g., font_factor=2.0 in your dillorc (most > dramatically for a tiny panel with small icons). The issue seems to > be with this factor not being taken into account when bh and lh are > set in make_panel() in ui.cc. > > As far as I can see, one can use the context menu to download > individual images on a page, or use the panel to toggle image > loading. But if one wants not to download images in general, but to > download all the images for some one page (e.g., a weather forecast > page), then one has to toggle downloading of images on and then off > again. Maybe a command could be added to KeysCommand_t in keys.hh, > bound by default to something like Ctrl-i in keys.cc, with a > corresponding call to a_Html_load_images() in handle() in ui.cc? > > To make the switch to the current snapshot, I had, sadly, to terminate > an instance of 3.0.5 that had been running continuously for 90 days > without any issues. But to get that much up time it was necessary to > add a little code so that SIGUSR1 would call a_Dns_freeall() and > a_Dns_init(), otherwise (unless I am missing something) Dillo will > persist in using the cached lookup indefinitely and not detect when > the IP address has changed. So maybe some sort of key binding could > be added that would flush the cache when needed? good point. However I'd like to avoid another key-binding and rather do the right thing automatically. I could think of a general DNS entry timeout of a couple of seconds. In many cases DNS responses are cached at OS-level too respecting lifetime values given by the server. Cheers, Johannes

July 6, 2016

CSS parser bug

by sgeerken＠dillo.org

On Di, Jul 05, 2016, Johannes Hofmann wrote: > On Mon, Jul 04, 2016 at 08:21:56PM +0200, Sebastian Geerken wrote: > > The CSS parser seems to have a bug handling shorthand properties. This > > example works well, both properties are handled correctly: > > > > <body style="background: url(http://www.gnu.org/graphics/heckert_gnu.small.png) repeat-y"> > > > > Adding "transparent" (for "background-color"), however, causes the > > other parts not to be parsed: > > > > <body style="background: transparent url(http://www.gnu.org/graphics/heckert_gnu.small.png) repeat-y"> > > > > Not a regression, dillo 3.0.5 shows the same behaviour. > > transparent seems to be the problem. > > <body style="background: red url(http://www.gnu.org/graphics/heckert_gnu.small.png) repeat-y"> > > works here. Not sure yet what it would take to support transparent properly. Suggested by your hint, I successfully tried this hack of CssParser::tokenMatchesProperty: diff -r c449be1f747f src/cssparser.cc --- a/src/cssparser.cc Mon Jul 04 14:04:49 2016 +0000 +++ b/src/cssparser.cc Tue Jul 05 23:06:31 2016 +0200 @@ -762,6 +762,7 @@ if ((ttype == CSS_TK_COLOR || ttype == CSS_TK_SYMBOL) && (dStrAsciiCasecmp(tval, "rgb") == 0 || + dStrAsciiCasecmp(tval, "transparent") == 0 || a_Color_parse(tval, -1, &err) != -1)) return true; break; Of course, I get a warning "color is not in "#RRGGBB" format", but at least "transparent" is /recognized/ as color at this point. Sebastian

July 5, 2016

URL field / Loading page images / Refreshing DNS cache

by jgaffney＠lawrenceville.org

First, a huge thanks to all the Dillo team for their efforts: I just switched from 3.0.5 to the current snapshot to try out the mbedtls changes, and I am wowed not only by this, but by all the improvements in rendering, etc. Great work! A few suggestions, all very minor, that might be added to the back of the development queue: In the current snapshot, the navigation bar has changed, and the URL field does not seem to be taking into account font_factor -- with the result that the window is smaller than the font height. You can test this by setting, e.g., font_factor=2.0 in your dillorc (most dramatically for a tiny panel with small icons). The issue seems to be with this factor not being taken into account when bh and lh are set in make_panel() in ui.cc. As far as I can see, one can use the context menu to download individual images on a page, or use the panel to toggle image loading. But if one wants not to download images in general, but to download all the images for some one page (e.g., a weather forecast page), then one has to toggle downloading of images on and then off again. Maybe a command could be added to KeysCommand_t in keys.hh, bound by default to something like Ctrl-i in keys.cc, with a corresponding call to a_Html_load_images() in handle() in ui.cc? To make the switch to the current snapshot, I had, sadly, to terminate an instance of 3.0.5 that had been running continuously for 90 days without any issues. But to get that much up time it was necessary to add a little code so that SIGUSR1 would call a_Dns_freeall() and a_Dns_init(), otherwise (unless I am missing something) Dillo will persist in using the cached lookup indefinitely and not detect when the IP address has changed. So maybe some sort of key binding could be added that would flush the cache when needed? Thanks again for all your hard work!

July 5, 2016

CSS parser bug

by Johannes.Hofmann＠gmx.de

On Mon, Jul 04, 2016 at 08:21:56PM +0200, Sebastian Geerken wrote: > Hi! > > The CSS parser seems to have a bug handling shorthand properties. This > example works well, both properties are handled correctly: > > <body style="background: url(http://www.gnu.org/graphics/heckert_gnu.small.png) repeat-y"> > > Adding "transparent" (for "background-color"), however, causes the > other parts not to be parsed: > > <body style="background: transparent url(http://www.gnu.org/graphics/heckert_gnu.small.png) repeat-y"> > > Not a regression, dillo 3.0.5 shows the same behaviour. transparent seems to be the problem. <body style="background: red url(http://www.gnu.org/graphics/heckert_gnu.small.png) repeat-y"> works here. Not sure yet what it would take to support transparent properly. Cheers, Johannes

July 5, 2016

Problem related to generated content

by sgeerken＠dillo.org

Hi! I've come upon an interesting problem. Consider this HTML (stripped down from a real world example): <head> <style> .fc:after { content: ""; display: block; clear: both; } </style> </head> <body> <div class="fc"> <div style="float: left">main</div> </div> <div style="background:#404040; color:#ffffff">footer</div> </body> Firefox (and probably other browsers) renders black text "main" on white background above white text "footer" on dark gray background. Dillo 3.0.5 does the same, for the simple reason that it does not support floats. Dillo 3.1-dev, however, renders black text "main" and white text "footer" side by side on dark gray background, because "main" is within a float. (Which is, of course, difficult to read.) The reason why Firefox renders this as it does: the definition within <style> generates something like a block element before the text containing "footer", with "clear: both" as CSS attributes; something like: <body> <div class="fc"> <div style="float: left">main</div> </div> <div style="clear:both"></div> <div style="background:#404040; color:#ffffff">footer</div> </body> Aside from the fact that dillo has still problems with this ("footer" is too much to the right; I'll investigate this independently), this shows that dillo's limited capabilities regarding generated content, together with floats, causes some unpleasing rendering errors, which are furthermore laborious to analyse (and thus not so simple to be ignored). Has someone a feasible idea to deal with this? Sebastian

July 5, 2016

trustworthiness of dillo's TLS code at present

by eocene＠gmx.com

Currently I'd trust dillo for https about as much as I'd trust wget for https. (Not that I've really examined wget, but just as a sort of gauge here...) Back in the DPI days, dillo didn't check hostnames on certificates because that was an impossible nightmare with openssl unless you found the code somewhere to modify for your own project. [By the way, there was outrage a couple of years ago when people realized that lots and lots of tools out there, and tls libraries for popular languages, were using OpenSSL and not doing any hostname validation.] It was only with 3.0.5 that I had looked into TLS myself and learned enough about what's insecure at present to disable old ciphers, disable ssl3, disable tls compression. When TLS moved into the browser with the OpenSSL version, I integrated hostname checking code adapted from wget source. And now mbed TLS does the checking itself. At present, our weakness relative to something like chrome or firefox would be in the area of certificate revocation. Dillo has never had a way to know when a certificate has been revoked. For a while, there were certificate revocation lists (CRLs) that are generally published by the assorted certificate authorities, although sometimes you have to click on agreements to get them. The other problem is that those grow _huge_, and distributions don't generally have packages for them (unlike ca-certificates for root certificates). I wouldn't be surprised if the agreements bar distribution. And there was OCSP, which stands for.... Online Certificate Status Protocol. Every time you get a certificate, you query some server, often a third-party server, and ask it whether this certificate is still valid. But those OCSP servers were/are nowhere near reliable enough, and browsers couldn't very well fail everything when the OCSP servers were being flaky.. So OCSP stapling has been coming along, where the OCSP data comes from the original server along with the certificate. OpenSSL has had OCSP code for a little while, but it's very buggy and not documented, and maybe you could get it to work if your application is exceedingly similar to the sample client, but good luck. mbed TLS has OCSP on their roadmap, but it's not implemented yet. As for what the firefoxes and chromes of the world are up to, firefox ripped out their CRL code a while back and they have some other mechanism where certificate authorities notify them of revocations and they push it out. Because they're still big enough to get certificate authorities to do things for them. And they have 'public key pinning' where a server sends keys to certificates, and the client checks that, when certificates are presented in the future, they continue to use one or more of those keys. My understanding is that this is not at all widely used currently. Like if you go to google while claiming that you're chrome, maybe.

July 4, 2016

CSS parser bug

by sgeerken＠dillo.org

Hi! The CSS parser seems to have a bug handling shorthand properties. This example works well, both properties are handled correctly: <body style="background: url(http://www.gnu.org/graphics/heckert_gnu.small.png) repeat-y"> Adding "transparent" (for "background-color"), however, causes the other parts not to be parsed: <body style="background: transparent url(http://www.gnu.org/graphics/heckert_gnu.small.png) repeat-y"> Not a regression, dillo 3.0.5 shows the same behaviour. Sebastian

July 4, 2016

an experiment using mbed TLS

by nick＠linicks.net

On Mon, 4 Jul 2016 17:01:39 +0000 eocene <eocene at gmx.com> wrote: > Nick wrote: > > > Should be -lmbedtls, -lmbedx509 and -lmbedcrypto > > > > All really does build fine now :) > > > > mbedtls seems to work well - seems a tad quicker too. > > I don't know where you got the > "-libmbedtls -libmbedx509 -libmbedcrypto" from. > Mine has "-lmbedtls -lmbedx509 -lmbedcrypto", > and it says "-lmbedtls -lmbedx509 -lmbedcrypto when > I double-check on hg.dillo.org. Ummm. You are right. Maybe I was messing around late last night with the earlier error message - I can't remember now :) Sorry for the noise - all builds and works fine. 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"

July 4, 2016

an experiment using mbed TLS

by eocene＠gmx.com

Nick wrote: > A bit premature here. I quickly ran ./configure before work and > configure worked OK. But tonight, run make, my linker bombed out with: > > /usr/lib/gcc/i486-slackware-linux/4.8.2/../../../../i486-slackware-linux/bin/ld: > cannot find > -libmbedtls /usr/lib/gcc/i486-slackware-linux/4.8.2/../../../../i486-slackware-linux/bin/ld: > cannot find > -libmbedx509 /usr/lib/gcc/i486-slackware-linux/4.8.2/../../../../i486-slackware-linux/bin/ld: > cannot find -libmbedcrypto > > Strange, as ldconfig -v reveals: > > /usr/local/lib: > libmbedcrypto.so.0 -> libmbedcrypto.so.2.3.0 > libmbedtls.so.10 -> libmbedtls.so.2.3.0 > libmbedx509.so.0 -> libmbedx509.so.2.3.0 > > Anyway, an hour of investing, it turns out the linker flags are > incorrect - changing in configure fixed it up: > > if test "x$ssl_ok" = "xyes"; then > LIBSSL_LIBS="-libmbedtls -libmbedx509 -libmbedcrypto" > > Should be -lmbedtls, -lmbedx509 and -lmbedcrypto > > All really does build fine now :) > > mbedtls seems to work well - seems a tad quicker too. I don't know where you got the "-libmbedtls -libmbedx509 -libmbedcrypto" from. Mine has "-lmbedtls -lmbedx509 -lmbedcrypto", and it says "-lmbedtls -lmbedx509 -lmbedcrypto when I double-check on hg.dillo.org.

July 4, 2016

an experiment using mbed TLS

by nick＠linicks.net

On Mon, 4 Jul 2016 06:08:58 +0100 Nick Warne <nick at linicks.net> wrote: > On Sun, 3 Jul 2016 21:09:40 +0000 > eocene <eocene at gmx.com> wrote: > > > I wrote: > > > I wrote: > > > > Nick wrote: > > > > > OK, what do I need to do to build this after an hour of head > > > > > scratching: > > > Making the attached changes makes it succeed, although I've only > > > gotten just that far at the moment and haven't looked into whether > > > it's an error on their part or what... > > > > Their bug: https://github.com/ARMmbed/mbedtls/issues/522 > > Good catch - all builds fine now - thanks, A bit premature here. I quickly ran ./configure before work and configure worked OK. But tonight, run make, my linker bombed out with: /usr/lib/gcc/i486-slackware-linux/4.8.2/../../../../i486-slackware-linux/bin/ld: cannot find -libmbedtls /usr/lib/gcc/i486-slackware-linux/4.8.2/../../../../i486-slackware-linux/bin/ld: cannot find -libmbedx509 /usr/lib/gcc/i486-slackware-linux/4.8.2/../../../../i486-slackware-linux/bin/ld: cannot find -libmbedcrypto Strange, as ldconfig -v reveals: /usr/local/lib: libmbedcrypto.so.0 -> libmbedcrypto.so.2.3.0 libmbedtls.so.10 -> libmbedtls.so.2.3.0 libmbedx509.so.0 -> libmbedx509.so.2.3.0 Anyway, an hour of investing, it turns out the linker flags are incorrect - changing in configure fixed it up: if test "x$ssl_ok" = "xyes"; then LIBSSL_LIBS="-libmbedtls -libmbedx509 -libmbedcrypto" Should be -lmbedtls, -lmbedx509 and -lmbedcrypto All really does build fine now :) mbedtls seems to work well - seems a tad quicker too. 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"

July 4, 2016

an experiment using mbed TLS

by nick＠linicks.net

On Sun, 3 Jul 2016 21:09:40 +0000 eocene <eocene at gmx.com> wrote: > I wrote: > > I wrote: > > > Nick wrote: > > > > OK, what do I need to do to build this after an hour of head > > > > scratching: > > Making the attached changes makes it succeed, although I've only > > gotten just that far at the moment and haven't looked into whether > > it's an error on their part or what... > > Their bug: https://github.com/ARMmbed/mbedtls/issues/522 Good catch - all builds fine now - 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"

July 4, 2016

an experiment using mbed TLS

by eocene＠gmx.com

I wrote: > I wrote: > > Nick wrote: > > > OK, what do I need to do to build this after an hour of head scratching: > > > > > > checking mbedtls/ssl.h usability... no > > > checking mbedtls/ssl.h presence... yes > > > configure: WARNING: mbedtls/ssl.h: present but cannot be compiled > > > configure: WARNING: mbedtls/ssl.h: check for missing prerequisite > > > headers? configure: WARNING: mbedtls/ssl.h: see the Autoconf > > > documentation configure: WARNING: mbedtls/ssl.h: section "Present > > > But Cannot Be Compiled" configure: WARNING: mbedtls/ssl.h: proceeding > > > with the compiler's result checking for mbedtls/ssl.h... no > > > configure: WARNING: *** mbed TLS 2 not found. Disabling SSL/HTTPS/TLS > > > support. *** > > > > IIRC, Jeremy was the closest we had to an autoconf expert, but he hasn't > > been around. > > > > Is anything interesting in the mbedtls region of the config.log file? > > > > I don't remember ever seeing quite that sort of set of warnings out > > of autoconf before. > > I was able to reproduce the problem by uninstalling mbed tls and then > pointing to it during configuration with CPPFLAGS to the include dir > and LDFLAGS to the lib dir. > > Making the attached changes makes it succeed, although I've only > gotten just that far at the moment and haven't looked into whether > it's an error on their part or what... Their bug: https://github.com/ARMmbed/mbedtls/issues/522

July 3, 2016

an experiment using mbed TLS

by eocene＠gmx.com

I wrote: > Nick wrote: > > OK, what do I need to do to build this after an hour of head scratching: > > > > checking mbedtls/ssl.h usability... no > > checking mbedtls/ssl.h presence... yes > > configure: WARNING: mbedtls/ssl.h: present but cannot be compiled > > configure: WARNING: mbedtls/ssl.h: check for missing prerequisite > > headers? configure: WARNING: mbedtls/ssl.h: see the Autoconf > > documentation configure: WARNING: mbedtls/ssl.h: section "Present > > But Cannot Be Compiled" configure: WARNING: mbedtls/ssl.h: proceeding > > with the compiler's result checking for mbedtls/ssl.h... no > > configure: WARNING: *** mbed TLS 2 not found. Disabling SSL/HTTPS/TLS > > support. *** > > IIRC, Jeremy was the closest we had to an autoconf expert, but he hasn't > been around. > > Is anything interesting in the mbedtls region of the config.log file? > > I don't remember ever seeing quite that sort of set of warnings out > of autoconf before. I was able to reproduce the problem by uninstalling mbed tls and then pointing to it during configuration with CPPFLAGS to the include dir and LDFLAGS to the lib dir. Making the attached changes makes it succeed, although I've only gotten just that far at the moment and haven't looked into whether it's an error on their part or what...

July 3, 2016

an experiment using mbed TLS

by eocene＠gmx.com

Nick wrote: > OK, what do I need to do to build this after an hour of head scratching: > > checking mbedtls/ssl.h usability... no > checking mbedtls/ssl.h presence... yes > configure: WARNING: mbedtls/ssl.h: present but cannot be compiled > configure: WARNING: mbedtls/ssl.h: check for missing prerequisite > headers? configure: WARNING: mbedtls/ssl.h: see the Autoconf > documentation configure: WARNING: mbedtls/ssl.h: section "Present > But Cannot Be Compiled" configure: WARNING: mbedtls/ssl.h: proceeding > with the compiler's result checking for mbedtls/ssl.h... no > configure: WARNING: *** mbed TLS 2 not found. Disabling SSL/HTTPS/TLS > support. *** IIRC, Jeremy was the closest we had to an autoconf expert, but he hasn't been around. Is anything interesting in the mbedtls region of the config.log file? I don't remember ever seeing quite that sort of set of warnings out of autoconf before.

July 3, 2016

an experiment using mbed TLS

by nick＠linicks.net

On Sun, 3 Jul 2016 19:03:42 +0100 Nick Warne <nick at linicks.net> wrote: > On Sun, 3 Jul 2016 16:37:56 +0000 > eocene <eocene at gmx.com> wrote: > > > Jorge wrote: > > > On Mon, Jun 20, 2016 at 10:10:54AM +0200, Johannes Hofmann > > > wrote: > > > > 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. > > > > > > If you both agree it's a better lib than OpenSSL, +1. > > > > All right, then. *commits* > > > > If you need mbed TLS 2.x: https://tls.mbed.org/download > > Ha ha.... that got me. I updated Dillo, and found SSL sites don't > work. So I clicked on the above link... doesn't work as it is SSL :) OK, what do I need to do to build this after an hour of head scratching: checking mbedtls/ssl.h usability... no checking mbedtls/ssl.h presence... yes configure: WARNING: mbedtls/ssl.h: present but cannot be compiled configure: WARNING: mbedtls/ssl.h: check for missing prerequisite headers? configure: WARNING: mbedtls/ssl.h: see the Autoconf documentation configure: WARNING: mbedtls/ssl.h: section "Present But Cannot Be Compiled" configure: WARNING: mbedtls/ssl.h: proceeding with the compiler's result checking for mbedtls/ssl.h... no configure: WARNING: *** mbed TLS 2 not found. Disabling SSL/HTTPS/TLS support. *** 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"

July 3, 2016

an experiment using mbed TLS

by nick＠linicks.net

On Sun, 3 Jul 2016 16:37:56 +0000 eocene <eocene at gmx.com> wrote: > Jorge wrote: > > On Mon, Jun 20, 2016 at 10:10:54AM +0200, Johannes Hofmann wrote: > > > 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. > > > > If you both agree it's a better lib than OpenSSL, +1. > > All right, then. *commits* > > If you need mbed TLS 2.x: https://tls.mbed.org/download Ha ha.... that got me. I updated Dillo, and found SSL sites don't work. So I clicked on the above link... doesn't work as it is SSL :) 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"

July 3, 2016

an experiment using mbed TLS

by eocene＠gmx.com

Jorge wrote: > On Mon, Jun 20, 2016 at 10:10:54AM +0200, Johannes Hofmann wrote: > > 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. > > If you both agree it's a better lib than OpenSSL, +1. All right, then. *commits* If you need mbed TLS 2.x: https://tls.mbed.org/download If you watch the MSGs, you'll see I've turned off the certificate chain printing and instead show a more concise summary at shutdown of which root certificates were used to verify communication with which servers. And at startup it'll tell you how many such certificates you are trusting. By default, I had 174, but I've trimmed them down on this computer to...twenty at the moment because I never need the ones from certificate authorities in China, Turkey, Hungary, etc.

July 3, 2016

valgrind errors

by sgeerken＠dillo.org

On Mi, Jun 22, 2016, eocene wrote: > Another one is containerAllocationState not getting initialized in > OOFPositionedMgr. Fixed, too. Sebastian

June 26, 2016

valgrind errors

by sgeerken＠dillo.org

On Mi, Jun 22, 2016, eocene 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. Fixed. (With one open issue which has been an open issue for a long time.) Sebastian

June 26, 2016

Error message when starting 3.1-dev from xterm

by eocene＠gmx.com

waltdnes wrote: > Changing that line to start with "#" instead of "*" gets rid of the > error. Fixed the typo, and I changed the error msg to print the line number.

June 26, 2016

Error message when starting 3.1-dev from xterm

by waltdnes＠waltdnes.org

On Sat, Jun 25, 2016 at 07:02:13AM +0000, eocene wrote > waltdnes wrote: > > Wnen starting up from an xterm, and then exiting, I get the > > following. > > > > ** ERROR **: prefsparser: Syntax error in dillorc: name="(null)" value="(null)" > > Domain: Default accept. > > dillo_dns_init: Here we go! (threaded) > > Disabling cookies. > > Dillo: normal exit! > > > > I moved my custom dillorc, and copied the generic one, i.e. > > > > /usr/local/dillo/etc/dillo/dillorc > > > > to check that it wasn't something I did. It still gets the same error. > > It looks like dParser_parse_rc_line() does not deal > very well with the case where the line is not empty, > is not a comment, and lacks an '='. BINGO! cd .dillo grep -v "=" dillorc | grep -v "^#" > z.txt .dillo/z.txt contains a bunch of blank lines, plus the line... * HSTS directives are not saved between browser sessions. Changing that line to start with "#" instead of "*" gets rid of the error. -- Walter Dnes <waltdnes at waltdnes.org>

June 25, 2016

Patch: Zero detected HTML errors

by nick＠linicks.net

On Sat, 25 Jun 2016 11:57:06 -0400 Jorge Arellano Cid <jcid at dillo.org> wrote: > On Sat, Jun 25, 2016 at 01:56:14PM +0100, Nick Warne wrote: > > On Fri, 24 Jun 2016 17:13:59 -0400 > > Jorge Arellano Cid <jcid at dillo.org> wrote: > > > > > OK, let's take a look at this one. > > > > > > The idea is to inform that the bug meter detected zero HTML > > > errors, not that the doc is perfect (because the bug meter checks > > > a subset of the syntax/grammar legalese). > > > > > > How is that best expressed in english? > > > > > > > - a_Dialog_msg("Dillo: Valid HTML!", "Zero detected HTML > > > > errors!"); > > > > + a_Dialog_msg("Dillo: Valid HTML!", "Detected no HTML > > > > errors!"); > > > > Well, lets suppose that someone is called 'Zero'. > > > > "Zero detected HTML errors!" > > > > implies that he/she detected errors! > > Thanks. This makes it clear to me. > > > > > What about: "Could not detect any HTML errors!" > > > > which then implies that the current bug meter thinks it's OK (but > > as we know, there _still_ may be HTML errors. > > One more question, why not? > > 1. "No HTML errors detected!" or > > 2. "Zero HTML errors detected!" or > > 3. "Detected zero HTML errors!" > > > ** If I choose by replacing pronouns I'd have: > > 1. "He" detected! > 2. "He" detected! > 3. Dtected him! > > I'd choose 3.- as 1.- and 2.- are wrong. Am I right? OK, why not make it what it is: "Dillo Bug meter: no HTML errors detected" and also: "Dillo Bug meter: HTML errors detected" Pretty trivial stuff, but at least the viewer gets what you see. 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 25, 2016

Patch: Zero detected HTML errors

by jcid＠dillo.org

On Sat, Jun 25, 2016 at 01:56:14PM +0100, Nick Warne wrote: > On Fri, 24 Jun 2016 17:13:59 -0400 > Jorge Arellano Cid <jcid at dillo.org> wrote: > > > OK, let's take a look at this one. > > > > The idea is to inform that the bug meter detected zero HTML errors, > > not that the doc is perfect (because the bug meter checks a subset of > > the syntax/grammar legalese). > > > > How is that best expressed in english? > > > > > - a_Dialog_msg("Dillo: Valid HTML!", "Zero detected HTML > > > errors!"); > > > + a_Dialog_msg("Dillo: Valid HTML!", "Detected no HTML > > > errors!"); > > Well, lets suppose that someone is called 'Zero'. > > "Zero detected HTML errors!" > > implies that he/she detected errors! Thanks. This makes it clear to me. > > What about: "Could not detect any HTML errors!" > > which then implies that the current bug meter thinks it's OK (but as we > know, there _still_ may be HTML errors. One more question, why not? 1. "No HTML errors detected!" or 2. "Zero HTML errors detected!" or 3. "Detected zero HTML errors!" ** If I choose by replacing pronouns I'd have: 1. "He" detected! 2. "He" detected! 3. Dtected him! I'd choose 3.- as 1.- and 2.- are wrong. Am I right? -- Cheers Jorge.-

June 25, 2016

Error message when starting 3.1-dev from xterm

by nick＠linicks.net

On Sat, 25 Jun 2016 07:02:13 +0000 eocene <eocene at gmx.com> wrote: > waltdnes wrote: > > Wnen starting up from an xterm, and then exiting, I get the > > following. > > > > ** ERROR **: prefsparser: Syntax error in dillorc: name="(null)" > > value="(null)" Domain: Default accept. > > dillo_dns_init: Here we go! (threaded) > > Disabling cookies. > > Dillo: normal exit! > > > > I moved my custom dillorc, and copied the generic one, i.e. > > > > /usr/local/dillo/etc/dillo/dillorc > > > > to check that it wasn't something I did. It still gets the same > > error. > > It looks like dParser_parse_rc_line() does not deal > very well with the case where the line is not empty, > is not a comment, and lacks an '='. Strange, I don't get that warning on the default dillorc nor on my $HOME/.dillo/dillorc? 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 25, 2016

Patch: Zero detected HTML errors

by nick＠linicks.net

On Fri, 24 Jun 2016 17:13:59 -0400 Jorge Arellano Cid <jcid at dillo.org> wrote: > OK, let's take a look at this one. > > The idea is to inform that the bug meter detected zero HTML errors, > not that the doc is perfect (because the bug meter checks a subset of > the syntax/grammar legalese). > > How is that best expressed in english? > > > - a_Dialog_msg("Dillo: Valid HTML!", "Zero detected HTML > > errors!"); > > + a_Dialog_msg("Dillo: Valid HTML!", "Detected no HTML > > errors!"); Well, lets suppose that someone is called 'Zero'. "Zero detected HTML errors!" implies that he/she detected errors! What about: "Could not detect any HTML errors!" which then implies that the current bug meter thinks it's OK (but as we know, there _still_ may be HTML errors. 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 25, 2016

Error message when starting 3.1-dev from xterm

by eocene＠gmx.com

waltdnes wrote: > Wnen starting up from an xterm, and then exiting, I get the > following. > > ** ERROR **: prefsparser: Syntax error in dillorc: name="(null)" value="(null)" > Domain: Default accept. > dillo_dns_init: Here we go! (threaded) > Disabling cookies. > Dillo: normal exit! > > I moved my custom dillorc, and copied the generic one, i.e. > > /usr/local/dillo/etc/dillo/dillorc > > to check that it wasn't something I did. It still gets the same error. It looks like dParser_parse_rc_line() does not deal very well with the case where the line is not empty, is not a comment, and lacks an '='.

June 25, 2016

Error message when starting 3.1-dev from xterm

by waltdnes＠waltdnes.org

Wnen starting up from an xterm, and then exiting, I get the following. ** ERROR **: prefsparser: Syntax error in dillorc: name="(null)" value="(null)" Domain: Default accept. dillo_dns_init: Here we go! (threaded) Disabling cookies. Dillo: normal exit! I moved my custom dillorc, and copied the generic one, i.e. /usr/local/dillo/etc/dillo/dillorc to check that it wasn't something I did. It still gets the same error. -- Walter Dnes <waltdnes at waltdnes.org>

June 25, 2016

Patch: Zero detected HTML errors

by jcid＠dillo.org

On Mon, Jun 06, 2016 at 07:23:09PM +0100, Nick Warne wrote: > 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. Just be patient. The devs work on a spare time basis, and tend to allocate their time based on priorities. If somebody posts a patch/comment and it goes unanswered for some time, it's customary to "bump" (i.e. repost, ask again), just in case it got forgotten in the pile of work. It works the same in most projects. -- Cheers Jorge.-

June 24, 2016

Patch: Zero detected HTML errors

by jcid＠dillo.org

On Sun, Jun 05, 2016 at 03:43:20PM +0100, Nick Warne 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. OK, let's take a look at this one. The idea is to inform that the bug meter detected zero HTML errors, not that the doc is perfect (because the bug meter checks a subset of the syntax/grammar legalese). How is that best expressed in english? > - a_Dialog_msg("Dillo: Valid HTML!", "Zero detected HTML errors!"); > + a_Dialog_msg("Dillo: Valid HTML!", "Detected no HTML errors!"); -- Cheers Jorge.-

June 24, 2016

New design of tag nesting cleanup within the parser.

by nick＠linicks.net

On Fri, 24 Jun 2016 11:32:04 -0400 Jorge Arellano Cid <jcid at dillo.org> wrote: > On Thu, Jun 23, 2016 at 05:57:05PM +0100, Nick Warne wrote: > > On Wed, 22 Jun 2016 19:30:51 -0400 > > Jorge Arellano Cid <jcid at dillo.org> wrote: > > > > > Just as a quick and dirty patch so arstecnica, BBC and others > > > may be read before I come with something more structured, you may > > > try: > > > > > > diff -r ca794cd4c182 src/html.cc > > > --- a/src/html.cc Tue Jun 21 18:04:00 2016 -0400 > > > +++ b/src/html.cc Wed Jun 22 19:30:15 2016 -0400 > > > @@ -3735,6 +3735,8 @@ static void Html_stack_cleanup_at_open(D > > > continue; // close > > > } else if (!(Tags[ni].Flags & 1) && !(Tags[ti].Flags & 4)) > > > { // Block element over a NON block container > > > + if (ti == i_A && html->DocTypeVersion >= 5.0f) > > > + break; > > > continue; // close > > > } > > > > > > > Thanks, that works fine. > > Committed. > Thanks Jorge - just in time to view the BBC news site for the best news I have heard in over 50 years :) 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 24, 2016

an experiment using mbed TLS

by jcid＠dillo.org

On Mon, Jun 20, 2016 at 10:10:54AM +0200, Johannes Hofmann wrote: > 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. If you both agree it's a better lib than OpenSSL, +1. -- Cheers Jorge.-

June 24, 2016

New design of tag nesting cleanup within the parser.

by jcid＠dillo.org

On Thu, Jun 23, 2016 at 05:57:05PM +0100, Nick Warne wrote: > On Wed, 22 Jun 2016 19:30:51 -0400 > Jorge Arellano Cid <jcid at dillo.org> wrote: > > > Just as a quick and dirty patch so arstecnica, BBC and others may > > be read before I come with something more structured, you may try: > > > > diff -r ca794cd4c182 src/html.cc > > --- a/src/html.cc Tue Jun 21 18:04:00 2016 -0400 > > +++ b/src/html.cc Wed Jun 22 19:30:15 2016 -0400 > > @@ -3735,6 +3735,8 @@ static void Html_stack_cleanup_at_open(D > > continue; // close > > } else if (!(Tags[ni].Flags & 1) && !(Tags[ti].Flags & 4)) { > > // Block element over a NON block container > > + if (ti == i_A && html->DocTypeVersion >= 5.0f) > > + break; > > continue; // close > > } > > > > Thanks, that works fine. Committed. -- Cheers Jorge.-

June 24, 2016

New design of tag nesting cleanup within the parser.

by jcid＠dillo.org

On Thu, Jun 23, 2016 at 10:10:42AM -0400, Ben Woolley wrote: > > > > On Jun 23, 2016, at 9:00 AM, eocene <eocene at gmx.com> wrote: > > > > Jorge wrote: > >>> On Wed, Jun 22, 2016 at 11:15:36PM +0000, eocene wrote: > >>> Yet another possibility is: "needs to be closed". > >> > >> It also sounds OK to me. > >> > >> Which one is better? > > > > I would choose 'needs'. > > > > It seems that compilers use the word "expected" to connote a > softer tone, like it is just the way that they interpret it. > "Expected <small> to be closed" would be the way to say it in > that way. "Needs" implies that you need to do it in any case, > but "expected" implies that you just need to do it to fix this > particular case. > > However, I do like using "needs" for the bug meter, because it > is a bug meter, not a warning message. It is there to tell you > what to fix. :) Thanks for the feedback. Committed. -- Cheers Jorge.-

June 24, 2016

New design of tag nesting cleanup within the parser.

by jcid＠dillo.org

On Thu, Jun 23, 2016 at 02:57:40PM +0200, Johannes Hofmann wrote: > Hi Jorge, > > it seems to fix too narrow forum posts on > http://forum.xda-developers.com/ - very nice! Good! That's what I was expecting... The parser is tuned for HTML 4.01 now, and as these days I see lots of sites using HTML5, most probably we'll see more cases of improved rendering as the parser is made aware of HTML5-specific rules. The new design is simpler to customize as it has a more definite separation between HTML rules and parsing decisions. -- Cheers Jorge.-

June 24, 2016

New design of tag nesting cleanup within the parser.

by nick＠linicks.net

On Wed, 22 Jun 2016 19:30:51 -0400 Jorge Arellano Cid <jcid at dillo.org> wrote: > Just as a quick and dirty patch so arstecnica, BBC and others may > be read before I come with something more structured, you may try: > > diff -r ca794cd4c182 src/html.cc > --- a/src/html.cc Tue Jun 21 18:04:00 2016 -0400 > +++ b/src/html.cc Wed Jun 22 19:30:15 2016 -0400 > @@ -3735,6 +3735,8 @@ static void Html_stack_cleanup_at_open(D > continue; // close > } else if (!(Tags[ni].Flags & 1) && !(Tags[ti].Flags & 4)) { > // Block element over a NON block container > + if (ti == i_A && html->DocTypeVersion >= 5.0f) > + break; > continue; // close > } > Thanks, that works fine. 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 23, 2016

New design of tag nesting cleanup within the parser.

by tautolog＠gmail.com

> On Jun 23, 2016, at 9:00 AM, eocene <eocene at gmx.com> wrote: > > Jorge wrote: >>> On Wed, Jun 22, 2016 at 11:15:36PM +0000, eocene wrote: >>> Yet another possibility is: "needs to be closed". >> >> It also sounds OK to me. >> >> Which one is better? > > I would choose 'needs'. > It seems that compilers use the word "expected" to connote a softer tone, like it is just the way that they interpret it. "Expected <small> to be closed" would be the way to say it in that way. "Needs" implies that you need to do it in any case, but "expected" implies that you just need to do it to fix this particular case. However, I do like using "needs" for the bug meter, because it is a bug meter, not a warning message. It is there to tell you what to fix. :) > _______________________________________________ > Dillo-dev mailing list > Dillo-dev at dillo.org > http://lists.dillo.org/cgi-bin/mailman/listinfo/dillo-dev

June 23, 2016

New design of tag nesting cleanup within the parser.

by eocene＠gmx.com

Jorge wrote: > On Wed, Jun 22, 2016 at 11:15:36PM +0000, eocene wrote: > > Yet another possibility is: "needs to be closed". > > It also sounds OK to me. > > Which one is better? I would choose 'needs'.

June 23, 2016

New design of tag nesting cleanup within the parser.

by johannes.hofmann＠gmx.de

Hi Jorge, it seems to fix too narrow forum posts on http://forum.xda-developers.com/ - very nice! Cheers, Johannes On Tue, Jun 21, 2016 at 06:18:58PM -0400, Jorge Arellano Cid wrote: > 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.- > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev at dillo.org > http://lists.dillo.org/cgi-bin/mailman/listinfo/dillo-dev

June 23, 2016

New design of tag nesting cleanup within the parser.

by jcid＠dillo.org

On Wed, Jun 22, 2016 at 11:15:36PM +0000, eocene wrote: > Jorge wrote: > > I just don't want the bug meter to sound harsh or pedantic. > > > > This phrase sounds well to me: (*advice*) > > > > "<small> has to be closed before </td>" // *advice* > > > > instead of: > > > > "<small> must be closed before </td>" // *reproach* > > > > > > If that's the correct interpretation of meaning, I'd prefer to > > use the "has to be closed" expression. > > Yet another possibility is: "needs to be closed". It also sounds OK to me. Which one is better? -- Cheers Jorge.-

June 23, 2016

New design of tag nesting cleanup within the parser.

by jcid＠dillo.org

On Wed, Jun 22, 2016 at 03:30:30PM -0400, Jorge Arellano Cid wrote: > 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... OK, we don't yet have HTML5 handling in dillo (besides ad-hoc), but this new design is simpler to tailor to a new set of rules, so that's the way to go. Although it'll take some time, incremental patches will give a better HTML5 experience step by step. Just as a quick and dirty patch so arstecnica, BBC and others may be read before I come with something more structured, you may try: diff -r ca794cd4c182 src/html.cc --- a/src/html.cc Tue Jun 21 18:04:00 2016 -0400 +++ b/src/html.cc Wed Jun 22 19:30:15 2016 -0400 @@ -3735,6 +3735,8 @@ static void Html_stack_cleanup_at_open(D continue; // close } else if (!(Tags[ni].Flags & 1) && !(Tags[ti].Flags & 4)) { // Block element over a NON block container + if (ti == i_A && html->DocTypeVersion >= 5.0f) + break; continue; // close } HTH. -- Cheers Jorge.-

June 22, 2016

New design of tag nesting cleanup within the parser.

by eocene＠gmx.com

Jorge wrote: > I just don't want the bug meter to sound harsh or pedantic. > > This phrase sounds well to me: (*advice*) > > "<small> has to be closed before </td>" // *advice* > > instead of: > > "<small> must be closed before </td>" // *reproach* > > > If that's the correct interpretation of meaning, I'd prefer to > use the "has to be closed" expression. Yet another possibility is: "needs to be closed".

June 22, 2016

New design of tag nesting cleanup within the parser.

by jcid＠dillo.org

On Wed, Jun 22, 2016 at 08:46:28PM +0000, eocene wrote: > 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. I like it! I just don't want the bug meter to sound harsh or pedantic. This phrase sounds well to me: (*advice*) "<small> has to be closed before </td>" // *advice* instead of: "<small> must be closed before </td>" // *reproach* If that's the correct interpretation of meaning, I'd prefer to use the "has to be closed" expression. -- Cheers Jorge.-

June 22, 2016