- Dillo-dev - lists.mailman3.com

border space

by corvid＠lavabit.com

Globe Trotter wrote: > same story with http://www.nytimes.com as well as http://www.huffingtonpost.com, for instance. The last is pretty much unreadable on dillo as a result. Is this a result of frames? These don't look worse than usual to me. I wonder whether you have some unusual settings.

Sept. 23, 2011

Fwd: Bug#642391: dillo: sane default for http redirects [origin: debian-bts@unpopularminds.org]

by corvid＠lavabit.com

Axel wrote: > there's probably > need for an at least a little bit more fine grained redirect/image > blocking configuration. Here's some code that experiments with letting you list a bunch of filter_auto_requests options in dillorc (same_domain, allow_redirect, allow_image, allow_stylesheet, allow_all), somewhat similar to search_url. Or we could turn it into three boolean preferences. Whatever.

Sept. 23, 2011

border space

by itsme_410＠yahoo.com

--- On Wed, 9/21/11, corvid <corvid at lavabit.com> wrote: > From: corvid <corvid at lavabit.com> > Subject: Re: [Dillo-dev] border space > To: dillo-dev at dillo.org > Date: Wednesday, September 21, 2011, 4:53 PM > higuita wrote: > > ??? Sometimes i find sites where the > right or left border space doesnt > > exist and the text is "touching" the window border, > making it difficult to > > read...??? Example: > > > > http://blog.pfsense.org/ > > http://karidawn.wordpress.com/ > > > > ??? these two are wordpress blogs, so > maybe its also a wordpress theme > > problem, but i think that adding a few pixels to both > borders would help > > a lot... if not hard to do, of course, as there is the > workaround to > > disable CSS to remove the text from the borders > > It might be partly a matter of pages expecting floats to > work, so that there's > something between the text and the window border. same story with http://www.nytimes.com as well as http://www.huffingtonpost.com, for instance. The last is pretty much unreadable on dillo as a result. Is this a result of frames? > > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev at dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev >

Sept. 23, 2011

Fwd: Bug#642391: dillo: sane default for http redirects [origin: debian-bts@unpopularminds.org]

by abe＠deuxchevaux.org

Hi corvid, On Thu, Sep 22, 2011 at 01:13:55PM +0000, corvid wrote: > Axel wrote: > > One easy way to do so would to display the content of the redirect > > page which usually contains a link to the redirect target. > > That's an interesting idea! I should be sleeping, but Hehe. > how does the attached work for you? Exactly as I expected, i.e. fine, only that way less redirection services than expected include links in the 30x page itself. I just clicked through the first 10 pages of my identi.ca home feed and checked all redirection services I found in use plus a standard Apache redirect (Apache 2.2.29 as on Debianb Lenny): OK: Apache 2.2.9 (tested http://blosxom.net/) NO CONTENTS: is.gd (tested: http://is.gd/dLoEoo) OK: identi.ca/url (tested: http://identi.ca/url/53842451) NO CONTENTS: ub0.cc (tested: http://ub0.cc/xm/97) OK: deb.li (tested: http://deb.li/7s0l) NO LINK: ur1.ca (tested: http://ur1.ca/54dz0) NO CONTENTS: lallus.net (tested: http://lallus.net/852) NO CONTENTS: t.co (tested: http://t.co/viemv5qx) OK: goo.gl (tested: http://goo.gl/dzbq8) OK: feedproxy.google.com (tested: http://feedproxy.google.com/~r/OmMalik/~3/Co-kep24E68/) OK: bit.ly (tested: http://bit.ly/njgxiQ) NO CONTENTS: tinyurl.com (tested: http://tinyurl.com/3fg22d8) So I recommend to add the patch anyway, as it makes things way better even if someone wants to filter these redirects, but there's probably need for an at least a little bit more fine grained redirect/image blocking configuration. Kind regards, Axel -- /~\ Plain Text Ribbon Campaign | Axel Beckert \ / Say No to HTML in E-Mail and News | abe at deuxchevaux.org (Mail) X See http://www.asciiribbon.org/ | abe at noone.org (Mail+Jabber) / \ I love long mails: http://email.is-not-s.ms/ | http://noone.org/abe/ (Web)

Sept. 23, 2011

release candidate for dillo-3.0.1 ready for testing

by abe＠deuxchevaux.org

Hi, On Thu, Sep 22, 2011 at 05:49:44PM +0200, Axel Beckert wrote: > > > http://www.dillo.org/download/dillo-3.0.1-rc1.tar.bz2 > > > is available for download now and want's to be tested. > > > Please give it a try and report back. If everything goes smoothly, > > > this will become dillo-3.0.1.tar.bz2 on Friday. > > > > Works OK here (Debian testing amd64). > > Haven't found time for testing the Debian package build yet, but plan > do so later today, [...] Works fine when being build as package on Debian Unstable, too. Kind regards, Axel -- /~\ Plain Text Ribbon Campaign | Axel Beckert \ / Say No to HTML in E-Mail and News | abe at deuxchevaux.org (Mail) X See http://www.asciiribbon.org/ | abe at noone.org (Mail+Jabber) / \ I love long mails: http://email.is-not-s.ms/ | http://noone.org/abe/ (Web)

Sept. 22, 2011

Fwd: Bug#642391: dillo: sane default for http redirects [origin: debian-bts@unpopularminds.org]

by corvid＠lavabit.com

Rogut?s wrote: > Benjamin Johnson (2011-09-22 14:47): > > On Thu, 22 Sep 2011 08:18:21 -0400, Axel Beckert > > <abe at deuxchevaux.org> wrote: > > > > >Hi, > > > > > >this bug report came in for dillo 3.0 in Debian Unstable/Testing, see > > >also http://bugs.debian.org/642391 > > > > > >See below for my thoughts. > > > > > > ... snip... > > > > > >Until now I noticed the effects of filter_auto_requests just for > > >images and was quite happy with it. But with images you can click on > > >them and they will be loaded. This does not seem to work for > > >cross-domain redirects. And as annoying as URL shorteners are, I > > >usually do like to follow those redirects. > > > > > >Is it possible to separate the settings for images and redirects? Or > > >is it possible to allow those redirect on a case-by-case base? > > > > > >One easy way to do so would to display the content of the redirect > > >page which usually contains a link to the redirect target. > > > > > > Kind regards, Axel > > > > You know, this may be the first time I've agreed with one of > > Debian's patches. Dillo's default setting breaks many major web > > sites, including Wikipedia, Google Images, and every photo hosting > > site. This hurts Dillo's usability, particularly for new and/or > > less technically knowledgeable users. The average user isn't going > > to stop and think "oh, these images aren't loading because they're > > hosted on a different domain"; he's going to think "Dillo is broken > > because this site doesn't work," and probably switch to a different > > browser. > > > > (Keep in mind, dillo-dev probably represents a small minority of > > users -- those who are both technically knowledgeable and interested > > enough to subscribe and participate. But good software can't be > > designed just for the minority. Firefox isn't popular only for its > > technical merits, but also because it's easy for people to install > > and use.) > > > > Granted, I like Axel's suggestions -- allow more fine-grained > > control, and display redirect links. They're much better than the > > current all-or-nothing approach. I'm just saying while we're at it, > > maybe we should also reconsider Dillo's IMHO overly paranoid > > defaults. A lot more people would probably stick with Dillo if it > > just behaved like they expect it to. > > I, for example, use Firefox with 'permissions.default.image=1', which > makes it show the link to 3rd party images instead of loading them. The > only place where I really missed images was Wikipedia, for which I added > an exception through an add-on. Once upon a time, back before the filter era, I experimented with something more fine-grained that understood adblock syntax http://lists.auriga.wearlab.de/pipermail/dillo-dev/2008-December/005573.html but it wasn't received very positively -- I think due to not being simple enough.

Sept. 22, 2011

Fwd: Bug#642391: dillo: sane default for http redirects [origin: debian-bts@unpopularminds.org]

by rogutes＠googlemail.com

Benjamin Johnson (2011-09-22 14:47): > On Thu, 22 Sep 2011 08:18:21 -0400, Axel Beckert > <abe at deuxchevaux.org> wrote: > > >Hi, > > > >this bug report came in for dillo 3.0 in Debian Unstable/Testing, see > >also http://bugs.debian.org/642391 > > > >See below for my thoughts. > > > > ... snip... > > > >Until now I noticed the effects of filter_auto_requests just for > >images and was quite happy with it. But with images you can click on > >them and they will be loaded. This does not seem to work for > >cross-domain redirects. And as annoying as URL shorteners are, I > >usually do like to follow those redirects. > > > >Is it possible to separate the settings for images and redirects? Or > >is it possible to allow those redirect on a case-by-case base? > > > >One easy way to do so would to display the content of the redirect > >page which usually contains a link to the redirect target. > > > > Kind regards, Axel > > You know, this may be the first time I've agreed with one of > Debian's patches. Dillo's default setting breaks many major web > sites, including Wikipedia, Google Images, and every photo hosting > site. This hurts Dillo's usability, particularly for new and/or > less technically knowledgeable users. The average user isn't going > to stop and think "oh, these images aren't loading because they're > hosted on a different domain"; he's going to think "Dillo is broken > because this site doesn't work," and probably switch to a different > browser. > > (Keep in mind, dillo-dev probably represents a small minority of > users -- those who are both technically knowledgeable and interested > enough to subscribe and participate. But good software can't be > designed just for the minority. Firefox isn't popular only for its > technical merits, but also because it's easy for people to install > and use.) > > Granted, I like Axel's suggestions -- allow more fine-grained > control, and display redirect links. They're much better than the > current all-or-nothing approach. I'm just saying while we're at it, > maybe we should also reconsider Dillo's IMHO overly paranoid > defaults. A lot more people would probably stick with Dillo if it > just behaved like they expect it to. I, for example, use Firefox with 'permissions.default.image=1', which makes it show the link to 3rd party images instead of loading them. The only place where I really missed images was Wikipedia, for which I added an exception through an add-on. -- -- Rogut?s Sparnuotos

Sept. 22, 2011

Fwd: Bug#642391: dillo: sane default for http redirects [origin: debian-bts@unpopularminds.org]

by obeythepenguin＠gmail.com

On Thu, 22 Sep 2011 08:18:21 -0400, Axel Beckert <abe at deuxchevaux.org> wrote: > Hi, > > this bug report came in for dillo 3.0 in Debian Unstable/Testing, see > also http://bugs.debian.org/642391 > > See below for my thoughts. > > ... snip... > > Until now I noticed the effects of filter_auto_requests just for > images and was quite happy with it. But with images you can click on > them and they will be loaded. This does not seem to work for > cross-domain redirects. And as annoying as URL shorteners are, I > usually do like to follow those redirects. > > Is it possible to separate the settings for images and redirects? Or > is it possible to allow those redirect on a case-by-case base? > > One easy way to do so would to display the content of the redirect > page which usually contains a link to the redirect target. > > Kind regards, Axel You know, this may be the first time I've agreed with one of Debian's patches. Dillo's default setting breaks many major web sites, including Wikipedia, Google Images, and every photo hosting site. This hurts Dillo's usability, particularly for new and/or less technically knowledgeable users. The average user isn't going to stop and think "oh, these images aren't loading because they're hosted on a different domain"; he's going to think "Dillo is broken because this site doesn't work," and probably switch to a different browser. (Keep in mind, dillo-dev probably represents a small minority of users -- those who are both technically knowledgeable and interested enough to subscribe and participate. But good software can't be designed just for the minority. Firefox isn't popular only for its technical merits, but also because it's easy for people to install and use.) Granted, I like Axel's suggestions -- allow more fine-grained control, and display redirect links. They're much better than the current all-or-nothing approach. I'm just saying while we're at it, maybe we should also reconsider Dillo's IMHO overly paranoid defaults. A lot more people would probably stick with Dillo if it just behaved like they expect it to. ~Benjamin

Sept. 22, 2011

release candidate for dillo-3.0.1 ready for testing

by abe＠deuxchevaux.org

Hi, On Thu, Sep 22, 2011 at 12:46:00PM -0300, Jorge Arellano Cid wrote: > > due to some important privacy fixes we decided to make a > > bugfix release. > > http://www.dillo.org/download/dillo-3.0.1-rc1.tar.bz2 > > is available for download now and want's to be tested. > > Please give it a try and report back. If everything goes smoothly, > > this will become dillo-3.0.1.tar.bz2 on Friday. > > Works OK here (Debian testing amd64). Haven't found time for testing the Debian package build yet, but plan do so later today, including corvid's patch for the redirect filtering issue. Kind regards, Axel -- /~\ Plain Text Ribbon Campaign | Axel Beckert \ / Say No to HTML in E-Mail and News | abe at deuxchevaux.org (Mail) X See http://www.asciiribbon.org/ | abe at noone.org (Mail+Jabber) / \ I love long mails: http://email.is-not-s.ms/ | http://noone.org/abe/ (Web)

Sept. 22, 2011

release candidate for dillo-3.0.1 ready for testing

by jcid＠dillo.org

On Wed, Sep 21, 2011 at 07:48:31PM +0200, Johannes Hofmann wrote: > Hi, > > due to some important privacy fixes we decided to make a > bugfix release. > http://www.dillo.org/download/dillo-3.0.1-rc1.tar.bz2 > is available for download now and want's to be tested. > Please give it a try and report back. If everything goes smoothly, > this will become dillo-3.0.1.tar.bz2 on Friday. Works OK here (Debian testing amd64). -- Cheers Jorge.-

Sept. 22, 2011