August 2011 - Dillo-dev - lists.mailman3.com

valgrind still unhappy despite expect changes

by jcid＠dillo.org

On Tue, Aug 09, 2011 at 01:39:53AM +0000, corvid wrote: > > http://starurchin.org/dillo/valgrind/7ea9fc809376ddf7dde2908e2ecf999aea2741… I can't reproduce this with valgrind-3.6.1 on wheezy. No valgrind error report before or after these debug messages: a_Nav_cancel_expect_if_eq:: calling a_Nav_cancel_expect Dillo: normal exit! I tested by pushing a remote URL on CLI and closing the window before the page data starts flowing (i.e. to cancel the "expect"), and also with the cancelled download code path. Neither one produced an error. -- Cheers Jorge.-

Aug. 9, 2011

moveToWidget

by jcid＠dillo.org

On Tue, Aug 09, 2011 at 04:16:13AM +0000, corvid wrote: > > It seems that things still aren't quite right. Yes. > With my original example that went > > <div> > <a href="http://www.dillo.org">I am a link. How exciting!</a> > > <div>a div. Move down here and the link url is still shown.</div> > Ordinary text outside of the div. Status output is blanked when moving down he > re. > </div> > > the problem is now that I move up to the link, and the status output is > shown, then I move down into the child div, and the status is correctly > cleared, then I move up into the link again, and the status is still blank. The example shows clearly the situation is much more complex than what was anticipated; and this explains why there were redundant workaround-code calls sprinkled in different parts, instead of a clean solution. AFAIS, the new moveToWidget() implementation has helped to get closer to a "clean" way of handling it. The situation is this: .----------------------------. | TextBlock (tb1) | | .-------------------. | | | TextBlock (tb2) | | | | | | | '-------------------' | '----------------------------' When going from tb2 to tb1 with tb1 as the common ancestor, tb1 is not "enterNotified()" because it was already entered. Fortunately in the case of an elder common ancestor, the just-entered textblock gets the enterNotify() call, so it seems adding this corner case to the dispatcher may be the solution. My thus patched tree works OK, so a commit will go soon. It looks like only testing will tell us whether there're other corner cases lurking around. -- Cheers Jorge.-

Aug. 9, 2011

moveToWidget

by corvid＠lavabit.com

It seems that things still aren't quite right. With my original example that went <div> <a href="http://www.dillo.org">I am a link. How exciting!</a> <div>a div. Move down here and the link url is still shown.</div> Ordinary text outside of the div. Status output is blanked when moving down he re. </div> the problem is now that I move up to the link, and the status output is shown, then I move down into the child div, and the status is correctly cleared, then I move up into the link again, and the status is still blank.

Aug. 9, 2011

Tab close button gets clobbered by tabs

by corvid＠lavabit.com

Rob wrote: > 2) From a practical standpoint, the old tabs seemed to behave a little > nicer, in that they would adjust their size a little bit to show more > of the title of the page opened in it. As it stands with Dillo 3, you > can't see much of the title text before it gets an ellipsis. I, too, would prefer titles that were not so short and that didn't have their descenders clipped.

Aug. 9, 2011

valgrind still unhappy despite expect changes

by corvid＠lavabit.com

http://starurchin.org/dillo/valgrind/7ea9fc809376ddf7dde2908e2ecf999aea2741…

Aug. 9, 2011

Tab close button gets clobbered by tabs

by obeythepenguin＠gmail.com

On Mon, 08 Aug 2011 18:52:40 -0400, Rob S <mr_semantics(a)hotmail.com> wrote: > Hello all, > > This evening I discovered that if I open too many tabs, the close tab > 'X' at the top right of the browser gets clobbered out of sight, until > I close some tabs (with CTRL-w). On the old Dillo (2.x), you could > open a fair amount of tabs, and the x would never be clobbered, but > instead a new instance of Dillo would start, after (I presume) a > predetermined amount of tabs were opened. Offhand I think *that's* because we got rid of the close button for a while, and the "new instance" code went with it... > On another note, while fiddling with the tabs on Dillo 3 and 2.x, I > got comparing the two, and I think I like the look of the old version > better. I have two reasons: ...and *that's* because of some technical difference between FLTK 2.x and 1.3 (I seem to remember Dillo implementing a custom tab widget). I may be completely wrong on both points, of course, since I haven't been following dillo3 too closely. > 1) I think the old version tabs look nicer (I realize not everyone > will think like me), and more like the tabs you would see in other > browsers. > 2) From a practical standpoint, the old tabs seemed to behave a little > nicer, in that they would adjust their size a little bit to show more > of the title of the page opened in it. As it stands with Dillo 3, you > can't see much of the title text before it gets an ellipsis. I agree whole-heartedly on both points. The "bubble" tabs are kind of cute, but I'd prefer a more understated, traditional look. Cheers, ~Benjamin

Aug. 9, 2011

Tab close button gets clobbered by tabs

by mr_semantics＠hotmail.com

Hello all, This evening I discovered that if I open too many tabs, the close tab 'X' at the top right of the browser gets clobbered out of sight, until I close some tabs (with CTRL-w). On the old Dillo (2.x), you could open a fair amount of tabs, and the x would never be clobbered, but instead a new instance of Dillo would start, after (I presume) a predetermined amount of tabs were opened. On another note, while fiddling with the tabs on Dillo 3 and 2.x, I got comparing the two, and I think I like the look of the old version better. I have two reasons: 1) I think the old version tabs look nicer (I realize not everyone will think like me), and more like the tabs you would see in other browsers. 2) From a practical standpoint, the old tabs seemed to behave a little nicer, in that they would adjust their size a little bit to show more of the title of the page opened in it. As it stands with Dillo 3, you can't see much of the title text before it gets an ellipsis. Regards, Rob

Aug. 9, 2011

dillo3-pre does not display images

by itsme_410＠yahoo.com

----- Original Message ----- From: Jorge Arellano Cid <jcid(a)dillo.org> To: dillo-dev(a)dillo.org Cc: Sent: Sunday, August 7, 2011 1:23 PM Subject: Re: [Dillo-dev] dillo3-pre does not display images On Sun, Aug 07, 2011 at 08:36:59AM -0700, Globe Trotter wrote: > > > > ________________________________ > From: Axel Beckert <abe(a)deuxchevaux.org> > To: dillo-dev(a)dillo.org > Sent: Sunday, August 7, 2011 9:53 AM > Subject: Re: [Dillo-dev] dillo3-pre does not display images > > Hi, > > On Sun, Aug 07, 2011 at 07:39:05AM -0700, Globe Trotter wrote: > > Trying www.nytimes.com or www.huffingtonpost.com or > > www.politico.com. While the frames are all messed up (as in Dillo > > 2.2), now even the images do not get displayed. ? Images show here. ? Weird, I don't know what it may be... ? BTW, you have a preferences file full of non-dillo keywords (at least not ours). Try: ? ? mv ~/.dillo/dillorc ~/.dillo/dillorc.BAK ? and see what hapopens by starting with the defaults Thanks, Jorge. I have been using this file since the time I started using dillo. Anyway, your suggested change did not produce any appreciable effect. $dillo paths: Using /usr/local/etc/dillo/dillorc paths: Using /usr/local/etc/dillo/keysrc dillo_dns_init: Here we go! (threaded) Enabling cookies as from cookiesrc... Nav_open_url: new url='about:splash' Nav_open_url: new url='http://www.dillo.org/' Dns_server [0]: www.dillo.org is 134.102.206.165 Nav_open_url: new url='dpi:/bm/' Nav_open_url: new url='http://www.nytimes.com' Dns_server [0]: www.nytimes.com is 170.149.173.130 Connecting to 170.149.173.130 Capi_filters_test: DENY from 'www.nytimes.com' to 'css.nyt.com' Capi_filters_test: DENY from 'www.nytimes.com' to 'i1.nyt.com' Capi_filters_test: ALLOW from 'www.nytimes.com' to 'graphics8.nytimes.com' Capi_filters_test: ALLOW from 'www.nytimes.com' to 'graphics8.nytimes.com' Capi_filters_test: DENY from 'www.nytimes.com' to 'ad.doubleclick.net' Capi_filters_test: ALLOW from 'www.nytimes.com' to 'graphics8.nytimes.com' Capi_filters_test: ALLOW from 'www.nytimes.com' to 'graphics8.nytimes.com' Capi_filters_test: ALLOW from 'www.nytimes.com' to 'graphics8.nytimes.com' Capi_filters_test: DENY from 'www.nytimes.com' to 'i1.nyt.com' Capi_filters_test: ALLOW from 'www.nytimes.com' to 'graphics8.nytimes.com' Capi_filters_test: ALLOW from 'www.nytimes.com' to 'graphics8.nytimes.com' Capi_filters_test: DENY from 'www.nytimes.com' to 'i1.nyt.com' Capi_filters_test: ALLOW from 'www.nytimes.com' to 'graphics8.nytimes.com' Capi_filters_test: DENY from 'www.nytimes.com' to 'i1.nyt.com' Capi_filters_test: DENY from 'www.nytimes.com' to 'i1.nyt.com' Capi_filters_test: DENY from 'www.nytimes.com' to 'i1.nyt.com' Capi_filters_test: DENY from 'www.nytimes.com' to 'i1.nyt.com' Capi_filters_test: DENY from 'www.nytimes.com' to 'i1.nyt.com' Capi_filters_test: DENY from 'www.nytimes.com' to 'i1.nyt.com' Capi_filters_test: ALLOW from 'www.nytimes.com' to 'graphics8.nytimes.com' Capi_filters_test: ALLOW from 'www.nytimes.com' to 'graphics8.nytimes.com' Capi_filters_test: ALLOW from 'www.nytimes.com' to 'graphics8.nytimes.com' Capi_filters_test: ALLOW from 'www.nytimes.com' to 'graphics8.nytimes.com' Capi_filters_test: ALLOW from 'www.nytimes.com' to 'graphics8.nytimes.com' Capi_filters_test: ALLOW from 'www.nytimes.com' to 'graphics8.nytimes.com' Capi_filters_test: ALLOW from 'www.nytimes.com' to 'graphics8.nytimes.com' Capi_filters_test: ALLOW from 'www.nytimes.com' to 'graphics8.nytimes.com' Capi_filters_test: ALLOW from 'www.nytimes.com' to 'graphics8.nytimes.com' Capi_filters_test: ALLOW from 'www.nytimes.com' to 'graphics8.nytimes.com' Capi_filters_test: ALLOW from 'www.nytimes.com' to 'graphics8.nytimes.com' Capi_filters_test: ALLOW from 'www.nytimes.com' to 'graphics8.nytimes.com' Capi_filters_test: ALLOW from 'www.nytimes.com' to 'graphics8.nytimes.com' Capi_filters_test: DENY from 'www.nytimes.com' to 'i1.nyt.com' Capi_filters_test: DENY from 'www.nytimes.com' to 'i1.nyt.com' Capi_filters_test: DENY from 'www.nytimes.com' to 'i1.nyt.com' Capi_filters_test: DENY from 'www.nytimes.com' to 'i1.nyt.com' Capi_filters_test: DENY from 'www.nytimes.com' to 'i1.nyt.com' Capi_filters_test: DENY from 'www.nytimes.com' to 'i1.nyt.com' Capi_filters_test: DENY from 'www.nytimes.com' to 'i1.nyt.com' Capi_filters_test: ALLOW from 'www.nytimes.com' to 'graphics8.nytimes.com' Capi_filters_test: ALLOW from 'www.nytimes.com' to 'graphics8.nytimes.com' Capi_filters_test: ALLOW from 'www.nytimes.com' to 'graphics8.nytimes.com' Capi_filters_test: ALLOW from 'www.nytimes.com' to 'graphics8.nytimes.com' Capi_filters_test: ALLOW from 'www.nytimes.com' to 'graphics8.nytimes.com' Capi_filters_test: ALLOW from 'www.nytimes.com' to 'graphics8.nytimes.com' Capi_filters_test: ALLOW from 'www.nytimes.com' to 'graphics8.nytimes.com' Capi_filters_test: ALLOW from 'www.nytimes.com' to 'www.nytimes.com' Capi_filters_test: ALLOW from 'www.nytimes.com' to 'graphics8.nytimes.com' Capi_filters_test: ALLOW from 'www.nytimes.com' to 'up.nytimes.com' Capi_filters_test: ALLOW from 'www.nytimes.com' to 'wt.o.nytimes.com' HTTP warning: 'http://www.nytimes.com/adx/bin/clientside/a06de63Q2Fomz6hZoiQ7C6ZKOQ7CV-miZ…' cannot be displayed as image; has media type 'text/html' Dns_server [0]: graphics8.nytimes.com is 65.126.84.42 65.126.84.41 Dns_server [2]: wt.o.nytimes.com is 66.150.117.24 Dns_server [1]: up.nytimes.com is 107.20.222.53 Is this also what you get? Someone wrote to me privately the following may work (though for Dillo 2.2.1). However, I am using dillo3-pre (on linux). Offhand, I know some sites now use a trick called "lazy loading" where they default to a blank image, then load the "real" ones with JavaScript.? It's supposed to help page load times by forcing the text to load before images, but breaks non-JavaScript enabled browsers. I've got a patch that works around one common version: ? http://dillo-win32.sourceforge.net/files/10-dillo-r1819.lazy_load.diff What might also help is adding to your dillorc: ? http_user_agent="Mozilla/4.0 (compatible; Dillo 2.2.1)" That tells sites that check your user agent to use simpler, Netscape 4.x-friendly code, which is much closer to what Dillo currently supports.? I've made that the default in the Windows port, since sites like Google Images are almost completely unusable otherwise. By the way, www.nytimes.com, www.huffingtonpost.com, and www.politico.com all work fine here -- I'm running dillo-win32-20110630 (more or less 2.2.1 with some compatibility patches). Thanks again!

Aug. 8, 2011

dillo3-pre does not display images

by jcid＠dillo.org

On Sun, Aug 07, 2011 at 08:36:59AM -0700, Globe Trotter wrote: > > > > ________________________________ > From: Axel Beckert <abe(a)deuxchevaux.org> > To: dillo-dev(a)dillo.org > Sent: Sunday, August 7, 2011 9:53 AM > Subject: Re: [Dillo-dev] dillo3-pre does not display images > > Hi, > > On Sun, Aug 07, 2011 at 07:39:05AM -0700, Globe Trotter wrote: > > Trying www.nytimes.com or www.huffingtonpost.com or > > www.politico.com. While the frames are all messed up (as in Dillo > > 2.2), now even the images do not get displayed. Images show here. Weird, I don't know what it may be... BTW, you have a preferences file full of non-dillo keywords (at least not ours). Try: mv ~/.dillo/dillorc ~/.dillo/dillorc.BAK and see what hapopens by starting with the defaults -- Cheers Jorge.-

Aug. 7, 2011

dillo3-pre does not display images

by itsme_410＠yahoo.com

________________________________ From: Axel Beckert <abe(a)deuxchevaux.org> To: dillo-dev(a)dillo.org Sent: Sunday, August 7, 2011 9:53 AM Subject: Re: [Dillo-dev] dillo3-pre does not display images Hi, On Sun, Aug 07, 2011 at 07:39:05AM -0700, Globe Trotter wrote: > Trying www.nytimes.com or www.huffingtonpost.com or > www.politico.com. While the frames are all messed up (as in Dillo > 2.2), now even the images do not get displayed. For me that sounds like that discussion in this thread from a few days ago: http://lists.auriga.wearlab.de/pipermail/dillo-dev/2011-August/008704.html ??? ??? Kind regards, Axel The DENYs went away but no images. Thanks! -- /~\? Plain Text Ribbon Campaign? ? ? ? ? ? ? ? ? | Axel Beckert \ /? Say No to HTML in E-Mail and News? ? ? ? ? ? | abe(a)deuxchevaux.org? (Mail) X? See http://www.asciiribbon.org/? ? ? ? ? ? ? | abe(a)noone.org (Mail+Jabber) / \? I love long mails: http://email.is-not-s.ms/ | http://noone.org/abe/ (Web) _______________________________________________ Dillo-dev mailing list Dillo-dev(a)dillo.org http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev

Aug. 7, 2011