[Dillo-dev] URL field / Loading page images / Refreshing DNS cache

[John Gaffney]

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!


_______________________________________________
Dillo-dev mailing list
Dill...@dillo.org
http://lists.dillo.org/cgi-bin/mailman/listinfo/dillo-dev

[Johannes Hofmann]

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

[Johannes Hofmann]

Firefox has an option to configure the DNS cache expiration
(network.dnsCacheExpiration).
Attached patch implements a similar feature for Dillo.

Cheers,
Johannes

[John Gaffney]

Johannes Hofmann <johannes...@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.

[Jorge Arellano Cid]

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

[Jorge Arellano Cid]

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

[John Gaffney]

Jorge Arellano Cid <jc...@dillo.org> writes:

[...]

I had been using Firefox (and still do, for trusted sites that require
javascript), but looked around for another browser when the option to
turn off javascript was removed from the preferences dialog -- when
javascript is so often the vulnerability behind exploits, I didn't
want a browser hoisting in javascript from all over the Internet at
its own discretion. (It is still possible to turn javascript off in
Firefox if one starts from a script that invokes a prefs.js with a
legacy `user_pref("javascript.enabled", false);', or from the internal
about:config page, but:) Dillo was one of the few browsers without
javascript, and when I checked it out, I found that I agreed very much
with Dillo's stated philosophy. And it has been my principal browser
ever since. In fact, along with an xterm and Emacs, it's one of the
three apps always running on my machine.

Things I like about Dillo:

Dillo doesn't even include javascript. (I cringe a bit when there is
talk on the list about the possibility of including it -- if it is
included at some point, I hope that there will be a #define to exclude
that code at compile time.)

Dillo is small and fast, which is nice not only for general browsing,
but when invoking it through, e.g., Emacs to open a link.

Dillo let's me configure things the way I like, and when it doesn't do
something I want, the code base is accessible enough that I can modify
it to do so. (I had in fact already implemented the suggestions I
made, but didn't share any patches because, even beyond being an
amateur, my hacks tend to be on the ugly side -- the loading of images
per page, for example, required adding #include "html.hh" to ui.cc,
indicating that I am certainly violating some logic of organization
and encapsulation.)

Dillo isn't phoning home or doing anything else behind my back, and it
let's me easily block ad and other such sites in domainrc.

Dillo doesn't try to do all sorts of exotic things, or invoke external
apps to do them, with all of the potential security risks. With other
browsers, you have to do a lot of work to try to prevent this sort of
automagical behavior, and even if it's possible, you aren't left
feeling at all confident about having prevented it.

Like you, I like that Dillo caches DNS lookups, but of course IP
addresses change from time to time for legitimate reasons, so there
does need to be a way to flush the cache. Johannes's patch is a good
one, but I also still like the idea of using the cache until I need it
to refresh. Of course, one could simply start a new instance of
Dillo, but I also like that it caches pages in a way that allows me to
open a link to a previously visited page off-line, without trying to
reconnect and reload it. And -- possibly a unique personal
idiosyncrasy -- I like to see links I have visited displayed as
visited. Other than that, there really isn't any reason not to be
firing up a fresh instance of Dillo whenever it is needed.

And probably a lot of other virtues in Dillo that just aren't coming
to mind right now.

> 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!

[Johannes Hofmann]

true

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

Searching for "getaddrinfo ttl" gives some interesting information
about the topic.
The general opinion seems to be that DNS caching should be handled
by e.g. nscd(8) as the TTL value is available there and responses
can be cached over process restarts of individual apps.
That also seems to be the reason why getaddrinfo() doesn't give
access to the TTL value (to avoid that all sorts of applications
implement their own DNS caching scheme).
Nevertheless I think that for the special case of web browsers some
DNS caching is helpful.
And e.g. Firefox does that too.
Having a configuration option for the DNS cache expiration time one
can have everything from no caching at all to caching forever.

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