Hi, On Sun, Mar 15, 2009 at 10:34:53PM +0000, Tim Nieradzik wrote:

Hi Jorge,

...

Please send it to me and I'll send you a dillo.org based URL so you can refer to it.

Unfortunately I had already deleted the mail but here are some information from my maildrop log that might be useful for you:

Date: Mon Mar 9 17:00:12 2009 From: dillo-dev-bounces@dillo.org Subj: Your message to Dillo-dev awaits moderator approval Size: 1902

Message found and approved.

By the way, I think I have found three bugs in Dillo. Whenever I visit the site https://oss.gonicus.de/labs/gosa/wiki, it asks me whether I want to accept the certificate about 10 times (probably for each picture and CSS file). A way to solve it would be to remember the selection for all links on this page but this could become to a big security risk as people could misuse this behaviour for phishing sites.

This is BUG#868 in the tracker. The solution is to turn the https dpi into a server (it's a filter now). This is not complex but takes time. I don't want to delay the next release even more so most probably it will be in the release after dillo-2.1.

The other bug appears on http://urldecode.info/ where no pictures are displayed. My vague assumption is that Dillo cannot handle images whose headers contain a "Location" header. Dillo just checks whether the Content-Length header contains anything (this is why it works for 0). It seems to me that Dillo downloads the picture properly but does not show it because it thinks the size is supposed to be 0.

Yes, historically dillo doesn't follow image redirections. Over time this has helped to reduce advertising (most image redirections are advertising).

[...] A possible solution would be to overwrite all headers by the ones from the redirected URL ("Location" header). Or would it be better to delete all available headers when a "Location" headers was found?

For "root" URLs, redirection is working, the same/similar method my be re-used for images. The point is whether it's desirable to do it. For instance, with a load_remote_images pref, it would work, but lot's of advertising would pass too. When disabled, sites as the one you cite won't work. If we let the user toggle this pref from "Tools" it would feel clumsy to do it for a favorite site. Now, we may solve all this with URL filtering. Let's say filtering has higher priority, and we have "allow" and "deny" options (just think of hosts not RE by now to discard performance issues). In the above described case I'd choose to set: allow file content = urldecode.info load_image_redirections = NO meaning that when visiting urldecode.info, remote image redirections will be loaded. The API should allow setting this automatically from the tools menu (e.g. "allow remote images" option with a short dialog: Do you want to enable remote image loading permanently for site xxx.yyy.zzz? [Allow] [Cancel]) URL filtering based on regular expressions is expensive in CPU terms, that's why I like the idea of HOST-based filtering. With it you can deny as a general rule and have some allow exceptions. (BTW, as a last resource if all this is not enough, RE support may be added on top).

The third issue (which only occurs in the Hg tree) looks like a timing bug. When visiting http://www.golem.de/0903/65726.html not all of the pictures are shown but when reloading the page, they are. Interestingly, it works perfectly if I save the page to disk and then view it manually in Dillo.

This needs some ivestigation...

When is the final version planned to be released?

I'll have more time in April, so probably April.

In my opinion we should wait a few weeks because Dillo crashes regularly on my machines (always running the trunk version).

This is strange, I very seldom get a dillo crash. Can you post example URLs, more details of your OS/FLTK-version/settings?

Therefore a release candidate every two would be useful for the users to give feedback and to report further bugs. After all of the major bugs have been fixed, we could announce the final version.

That's the idea.

Is it planned to include the key bindings patch into this version? This should not be a big deal for the users as the configuration files are backward compatible.

No, it's not planned. Now if the patch is simple, clean and straightforward and I can review it before rc1, and behaves well in testing, then it may go in.

What really annoys me is that when Dillo crashes, the CPU usage climbs onto 100%. The only way I can fix this is to kill all Dillo-related processes. This way, I lose my tabs. A session-saver like in Mozilla Firefox would be a useful feature but I am not sure whether it is worth the "bloatage".

AFAIS, one of the main features of Dillo is its stability, so please give us more information on this.

PS: What is the accurate way to find those memory leaks? I remember Jeremy speaking about Valgrind which he used to create his "crash reports".

Valgrind is cetainly a great tool for the job. -- Cheers Jorge.-