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

URL field / Loading page images / Refreshing DNS cache

by jcid＠dillo.org

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! Thanks for taking the time to express this! > 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? This is interesting. > 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. Wow, it's good to know it can last that long. What you describe here is very interesting, in a way I've come to suspect most users don't have the slightest clue. I mean, everyone of us (as dillo users) have *different* use cases. There's no way we can guess what other people are doing outside of our awareness realm. Now, you're not only a casual user, but one that uses dillo *a lot*, and appreciate it as an everyday tool. That being stated, we are very interested in knowing your use case, and all the details of it. There's potentially a lot we can learn from it, and also improve yours/and-the-generic user experience as a result of this learning. So please elaborate on why you like to have it running for that long time, what do you do with it, how you do it, what problem does it solve that other tools don't, why is it your choice. What you'd wish it had. Some things may be possible, others not, a few may be solved in different ways, etc. Just learning about those key tasks, or improving a single one, would be a big gain for all of us. Your feedback as a dillo power-user is not only welcomed, it's asked for! > Thanks again for all your hard work! Ack! @all: if you're a dillo power-user, let us know about it! -- Cheers Jorge.-

July 8, 2016

CSS files downloaded only after reloading page

by nick＠linicks.net

On Thu, 7 Jul 2016 22:20:01 +0000 eocene <eocene at gmx.com> wrote: > 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. Interesting - here is another example of the issue that I discovered today: https://bz.apache.org/bugzilla/show_bug.cgi?id=59333 Great work going on with Dillo anyhow - thanks to 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"

July 8, 2016

URL field / Loading page images / Refreshing DNS cache

by jcid＠dillo.org

On Fri, Jul 08, 2016 at 05:22:48PM +0200, Johannes Hofmann wrote: > 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. Thanks for the patch Johannes. Under the current workload, I guess I'll look at it in a couple of days. BTW, different use cases are very interesting. We usually asume our use case is generic. Dillo has thaught me several times that's not the case. I for instance, really avoid flushing the DNS cache as it is one of the slowest parts of my web browsing experience. Sometimes the ISP DNS server takes more time to answer than the page to load! I use another DNS but it's very noticeable, and the sites I usually browse seldom change their IPs (I've even thought of caching to disk, go figure! ;) So I'd like to know what's the use case behind this need. There's surely something on it (e.g. some site may want to distribute workload between different servers by changing IP, etc). One thing I know DNS queries are abused for is for tracking users. On the old dialup days, the DNS was very quick to answer, so I suspect something fishy going on when it takes so much time here on broadband... -- Cheers Jorge.-

July 8, 2016

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