I notice that redirection defeats --local. You go to www.dillo.org and images aren't loaded. You go to dillo.org, it redirects to www.dillo.org, and images are loaded.
On Wed, Dec 17, 2014 at 06:30:30PM +0000, eocene wrote:
I notice that redirection defeats --local. You go to www.dillo.org and images aren't loaded. You go to dillo.org, it redirects to www.dillo.org, and images are loaded.
Oh, yes. Originally, --local was meant for local files only. To allow safe displaying of HTML email in sylpheed (IIRC). Now, from the console help given by dillo, it seems like it should work with non-local URLs too. It makes sense to me, although I haven't found a compelling use case for that. Maybe for opening news site without the images... Attached is a brief patch. Please test and send feedback. -- Cheers Jorge.-
Jorge wrote:
On Wed, Dec 17, 2014 at 06:30:30PM +0000, eocene wrote:
I notice that redirection defeats --local. You go to www.dillo.org and images aren't loaded. You go to dillo.org, it redirects to www.dillo.org, and images are loaded.
Oh, yes.
Originally, --local was meant for local files only. To allow safe displaying of HTML email in sylpheed (IIRC).
Now, from the console help given by dillo, it seems like it should work with non-local URLs too. It makes sense to me, although I haven't found a compelling use case for that. Maybe for opening news site without the images...
Attached is a brief patch. Please test and send feedback.
It appears to fix the case that I mentioned, but then I tried a local file like <head> <meta http-equiv="refresh" content="0; url=http://example.com/"> </head> <body> text </body> and the redirection is followed.
On Sat, Dec 20, 2014 at 01:09:04AM +0000, eocene wrote:
Jorge wrote:
On Wed, Dec 17, 2014 at 06:30:30PM +0000, eocene wrote:
I notice that redirection defeats --local. You go to www.dillo.org and images aren't loaded. You go to dillo.org, it redirects to www.dillo.org, and images are loaded.
Oh, yes.
Originally, --local was meant for local files only. To allow safe displaying of HTML email in sylpheed (IIRC).
Now, from the console help given by dillo, it seems like it should work with non-local URLs too. It makes sense to me, although I haven't found a compelling use case for that. Maybe for opening news site without the images...
Attached is a brief patch. Please test and send feedback.
It appears to fix the case that I mentioned, but then I tried a local file like
<head> <meta http-equiv="refresh" content="0; url=http://example.com/"> </head> <body> text </body>
and the redirection is followed.
Please try the attached patch. -- Cheers Jorge.-
Jorge wrote:
On Sat, Dec 20, 2014 at 01:09:04AM +0000, eocene wrote:
Jorge wrote:
On Wed, Dec 17, 2014 at 06:30:30PM +0000, eocene wrote:
I notice that redirection defeats --local. You go to www.dillo.org and images aren't loaded. You go to dillo.org, it redirects to www.dillo.org, and images are loaded.
Oh, yes.
Originally, --local was meant for local files only. To allow safe displaying of HTML email in sylpheed (IIRC).
Now, from the console help given by dillo, it seems like it should work with non-local URLs too. It makes sense to me, although I haven't found a compelling use case for that. Maybe for opening news site without the images...
Attached is a brief patch. Please test and send feedback.
It appears to fix the case that I mentioned, but then I tried a local file like
<head> <meta http-equiv="refresh" content="0; url=http://example.com/"> </head> <body> text </body>
and the redirection is followed.
Please try the attached patch.
Looks like it works properly...
On Sat, Dec 20, 2014 at 08:58:16PM +0000, eocene wrote:
Jorge wrote:
On Sat, Dec 20, 2014 at 01:09:04AM +0000, eocene wrote:
Jorge wrote:
On Wed, Dec 17, 2014 at 06:30:30PM +0000, eocene wrote:
I notice that redirection defeats --local. You go to www.dillo.org and images aren't loaded. You go to dillo.org, it redirects to www.dillo.org, and images are loaded.
Oh, yes.
Originally, --local was meant for local files only. To allow safe displaying of HTML email in sylpheed (IIRC).
Now, from the console help given by dillo, it seems like it should work with non-local URLs too. It makes sense to me, although I haven't found a compelling use case for that. Maybe for opening news site without the images...
Attached is a brief patch. Please test and send feedback.
It appears to fix the case that I mentioned, but then I tried a local file like
<head> <meta http-equiv="refresh" content="0; url=http://example.com/"> </head> <body> text </body>
and the redirection is followed.
Please try the attached patch.
Looks like it works properly...
Committed. You may want to update the splash page and Changelog. -- Cheers Jorge.-
On Sat, Dec 20, 2014 at 10:55:29PM +0000, eocene wrote:
Done. We've gathered enough improvements now that we could've called this 3.0.5 :)
Sorry to comment here, but could you _please_ just get an official version out that supports fltk 1.3.3? This issue is pending way too long in my opinion. v4hn
On Sun, Dec 21, 2014 at 12:07:04AM +0100, v4hn wrote:
On Sat, Dec 20, 2014 at 10:55:29PM +0000, eocene wrote:
Done. We've gathered enough improvements now that we could've called this 3.0.5 :)
Sorry to comment here, but could you _please_ just get an official version out that supports fltk 1.3.3? This issue is pending way too long in my opinion.
You can always pack the last repo. There's no need to wait for an official release, unless you're packaging for a distro and have to follow policy. If that's the case, I'd like to know what distro you're using, because it looks quite on the edge, and I may also consider giving it a look/try! On the release side of things, that's the normal procedure. Produce a stable repo, then the RCs, test, rinse&repeat. Boring, but much better than to have to hurry-patch a bogus release. If nobody reports problems today, tomorrow there'll be another rc tarball for the usual tests. Let's hope it can become final. -- Cheers Jorge.-
On Sun, Dec 21, 2014 at 04:46:46PM -0300, Jorge Arellano Cid wrote:
On Sun, Dec 21, 2014 at 12:07:04AM +0100, v4hn wrote:
Sorry to comment here, but could you _please_ just get an official version out that supports fltk 1.3.3? This issue is pending way too long in my opinion.
You can always pack the last repo. There's no need to wait for an official release, unless you're packaging for a distro and have to follow policy.
If that's the case, I'd like to know what distro you're using, because it looks quite on the edge, and I may also consider giving it a look/try!
I'm one of the maintainers of lunar-linux(.org), which basically is an automated LFS with some bash scripts for package management. We try to stay "on the edge" these days, although this introduces problems like the fltk<->dillo incompatibility every now and then. But we also explicitly feature vanilla software, so we only introduce distribution specific patches if absolutely required (unlike basically all other distributions I know). So yes, if this takes much longer, it's probably better to package the RC than to keep a broken dillo module around.
On the release side of things, that's the normal procedure. Produce a stable repo, then the RCs, test, rinse&repeat. Boring, but much better than to have to hurry-patch a bogus release.
Sure, but imho eocene is completely right with what he wrote earlier: This was supposed to be version 3.0.4.1 to address the fltk problem quickely and some patches even were rejected for this release because they would change too much for such a release. By now this feels much more like 3.0.5 and it could probably also include the dicache fixes eocene mentioned on the list...
If nobody reports problems today, tomorrow there'll be another rc tarball for the usual tests. Let's hope it can become final.
As always, thanks for dillo, v4hn
participants (3)
-
eocene＠gmx.com -
jcid＠dillo.org -
me＠v4hn.de