- Dillo-dev - lists.mailman3.com

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