- Dillo-dev - lists.mailman3.com

patch: close windows from menubar

by onepoint＠starurchin.org

On Wed, Oct 08, 2008 at 01:09:48PM +0200, Joerg Sonnenberger wrote: > ... why would you want dillo1 and dillo2 at the same time. I don't know. But when you start saying "No-one could *possibly* want to do that, so let's stop supporting it" then you are riding for a fall. Why make ourselves hostages to fortune? Why not make *sure* we avoid the problem rather than gambling that we've second-guessed our entire user base? Murphy's law applies, so play it safe unless there's a compelling reason not to. > ... If there is no such reason, it doesn't make sense to rename the > binary. But we're *not* renaming the binary! We're distributing a new and *different* binary that supports a *different* command line and links to *different* libraries. As far as the OS is concerned that makes them as unlike as chalk and cheese. Therefore we should play it safe by giving them different names. That is the conventional thing to do, and also the safest. Regards, Jeremy Henty

Oct. 8, 2008

patch: close windows from menubar

by francis＠daoine.org

On Wed, Oct 08, 2008 at 02:02:17PM +0000, corvid wrote: > Jorge wrote: > > On Wed, Oct 08, 2008 at 01:09:48PM +0200, Joerg Sonnenberger wrote: > > > On Wed, Oct 08, 2008 at 10:13:23AM +0100, Jeremy Henty wrote: > > > > Of course, dillo2 is not a library package, but I think it should > > > > follow the same convention on the grounds of least surprise. (Unless > > > > there is a compelling reason not to, but I don't think that there is.) > > Everybody: please add your comment in this thread, even if stated > > before. > > I would prefer "dillo". If anybody wants/needs both versions, mv and ln -s > are available to them. I would prefer "dillo2". If anybody builds their own version, it should be easy enough for them to change it to "dillo", "dillorc", etc. at compile time. If a distribution is to package it, unless the new program is a drop-in replacement for the old program, the new program should probably have a different name. I haven't looked at fltk-dillo much, but command-line switches acting differently isn't a sign of a drop-in replacement. Are there any incompatibilities with the content of the rc file? Just my haven't-coded-in-a-while opinion... f -- Francis Daly francis(a)daoine.org

Oct. 8, 2008

patch: close windows from menubar

by Johannes.Hofmann＠gmx.de

On Wed, Oct 08, 2008 at 02:02:17PM +0000, corvid wrote: > Jorge wrote: > > On Wed, Oct 08, 2008 at 01:09:48PM +0200, Joerg Sonnenberger wrote: > > > On Wed, Oct 08, 2008 at 10:13:23AM +0100, Jeremy Henty wrote: > > > > Of course, dillo2 is not a library package, but I think it should > > > > follow the same convention on the grounds of least surprise. (Unless > > > > there is a compelling reason not to, but I don't think that there is.) > > > > > > Does dillo1 offer *anything* over dillo2? E.g. why would you want dillo1 > > > and dillo2 at the same time. If there is no such reason, it doesn't make > > > sense to rename the binary. > > > > Dillo1 is used as an html viewer by sylpheed (claws). I don't > > know the name of the binary they distribute though. Dillo2 doesn't > > provide the required CLI switches yet. > > > > That's it AFAIR. Dillo2 doesn't have these switches: > > > > -x, --xid XID Open first Dillo window in an existing > > GtkSocket which window ID is XID (decimal). > > -v, --version Display version info and exit. > > -h, --help Display this help text and exit. > > -f, --fullwindow Start in full window mode: hide address bar, > > navigation buttons, menu, and status bar. > > -l, --local Don't follow links for this URL(s). > > -g, -geometry GEO Set initial window position where GEO is > > <width>x<height>{+-}<x>{+-}<y> > > -D, --debug-rendering Draw additionaly several lines in a web page, > > representing its structure. For debugging. > > > > Everybody: please add your comment in this thread, even if stated > > before. > > I would prefer "dillo". If anybody wants/needs both versions, mv and ln -s > are available to them. > Me too. Citing from the homepage: "Dillo is following an evolving software-model where every new version of it, should be better than the former one; there's no place for unstable releases, so just keep with the latest one" I would even use dillorc for consistency. Cheers, Johannes

Oct. 8, 2008

patch: close windows from menubar

by corvid＠lavabit.com

Jorge wrote: > On Wed, Oct 08, 2008 at 01:09:48PM +0200, Joerg Sonnenberger wrote: > > On Wed, Oct 08, 2008 at 10:13:23AM +0100, Jeremy Henty wrote: > > > Of course, dillo2 is not a library package, but I think it should > > > follow the same convention on the grounds of least surprise. (Unless > > > there is a compelling reason not to, but I don't think that there is.) > > > > Does dillo1 offer *anything* over dillo2? E.g. why would you want dillo1 > > and dillo2 at the same time. If there is no such reason, it doesn't make > > sense to rename the binary. > > Dillo1 is used as an html viewer by sylpheed (claws). I don't > know the name of the binary they distribute though. Dillo2 doesn't > provide the required CLI switches yet. > > That's it AFAIR. Dillo2 doesn't have these switches: > > -x, --xid XID Open first Dillo window in an existing > GtkSocket which window ID is XID (decimal). > -v, --version Display version info and exit. > -h, --help Display this help text and exit. > -f, --fullwindow Start in full window mode: hide address bar, > navigation buttons, menu, and status bar. > -l, --local Don't follow links for this URL(s). > -g, -geometry GEO Set initial window position where GEO is > <width>x<height>{+-}<x>{+-}<y> > -D, --debug-rendering Draw additionaly several lines in a web page, > representing its structure. For debugging. > > Everybody: please add your comment in this thread, even if stated > before. I would prefer "dillo". If anybody wants/needs both versions, mv and ln -s are available to them.

Oct. 8, 2008

panel_size=tiny have no menu

by jcid＠dillo.org

On Sun, Oct 05, 2008 at 07:50:37PM +0100, higuita wrote: > hi > > i use dillo with panel_size=tiny and now with the tabs, i wanted to > close some of then... but as there is no close button nor tab menu, i was > searching for the shortcut for close tabs... > > i search the mailling list and it points to the menu entry and the > ctr+Q, and at least the last one works fine. > > what i found is that if i setup panel_size=tiny, i have no menu, > in dillo1 there was a F next to the bookmark > > Not that the File menu is very important, but here is the bug > report :) Higuita, Jeremy, and everyone interested: Please test this long patch: http://www.dillo.org/test/file_popup.OK1 I had to use a button and popup menu instead of a menubar. Also switched "show_menubar" for "show_filemenu", and the latter one works! :-) Note: this patch is out of the release (time/size considerations). -- Cheers Jorge.-

Oct. 8, 2008

patch: close windows from menubar

by jcid＠dillo.org

On Wed, Oct 08, 2008 at 01:09:48PM +0200, Joerg Sonnenberger wrote: > On Wed, Oct 08, 2008 at 10:13:23AM +0100, Jeremy Henty wrote: > > Of course, dillo2 is not a library package, but I think it should > > follow the same convention on the grounds of least surprise. (Unless > > there is a compelling reason not to, but I don't think that there is.) > > Does dillo1 offer *anything* over dillo2? E.g. why would you want dillo1 > and dillo2 at the same time. If there is no such reason, it doesn't make > sense to rename the binary. Dillo1 is used as an html viewer by sylpheed (claws). I don't know the name of the binary they distribute though. Dillo2 doesn't provide the required CLI switches yet. That's it AFAIR. Dillo2 doesn't have these switches: -x, --xid XID Open first Dillo window in an existing GtkSocket which window ID is XID (decimal). -v, --version Display version info and exit. -h, --help Display this help text and exit. -f, --fullwindow Start in full window mode: hide address bar, navigation buttons, menu, and status bar. -l, --local Don't follow links for this URL(s). -g, -geometry GEO Set initial window position where GEO is <width>x<height>{+-}<x>{+-}<y> -D, --debug-rendering Draw additionaly several lines in a web page, representing its structure. For debugging. Everybody: please add your comment in this thread, even if stated before. -- Cheers Jorge.-

Oct. 8, 2008

patch: close windows from menubar

by joerg.sonnenberger＠web.de

On Wed, Oct 08, 2008 at 10:13:23AM +0100, Jeremy Henty wrote: > Of course, dillo2 is not a library package, but I think it should > follow the same convention on the grounds of least surprise. (Unless > there is a compelling reason not to, but I don't think that there is.) Does dillo1 offer *anything* over dillo2? E.g. why would you want dillo1 and dillo2 at the same time. If there is no such reason, it doesn't make sense to rename the binary. Joerg

Oct. 8, 2008

patch: close windows from menubar

by onepoint＠starurchin.org

On Tue, Oct 07, 2008 at 04:44:16PM -0400, Jorge Arellano Cid wrote: > binary name: dillo > version : 2.0 > rc file : dillo2rc I think the binary name should be dillo2 . It's consistent with dillo2rc for the rc file. It's also consistent with the established convention for packages like fltk , gtk and gpg where the OS level treats different major versions as entirely different packages (even though the users/developers think of them as merely different versions of the same package). This is critical for library packages which really must support installing multiple versions. For example, I run both fltk and fltk2 applications so it's vital that I can install both major versions and be sure that applications will always link to the right one. This works only because the OS treats the two as entirely different. Of course, dillo2 is not a library package, but I think it should follow the same convention on the grounds of least surprise. (Unless there is a compelling reason not to, but I don't think that there is.) It's like Superman II and The Dark Night, the sequel is better than the original! No need to hide it! Jeremy Henty

Oct. 8, 2008

patch: close windows from menubar

by corvid＠lavabit.com

Johannes wrote: > On Tue, Oct 07, 2008 at 06:12:47PM +0000, corvid wrote: > > Johannes wrote: > > > Excellent. From previous announcements I'd expect the next weekly > > > fltk2 snapshot by friday. > > > Is there anything left we need for the release? > > > What about the binary and config file name? > > > > We have to remember to take clear_double_buffer out before releasing. > > > > I thought we would keep it. > Without it things get awfully slow here with more than 5 windows. > Also all the backBuffer stuff in FltkViewBase would be unnecessary > then. > Are you seeing any problems with clear_double_buffer()? In the course of this thread: http://lists.auriga.wearlab.de/pipermail/dillo-dev/2008-April/004022.html we learned that drawing with antialiased fonts is exceedingly slow for me for some reason with clear_double_buffer.

Oct. 8, 2008

patch: close windows from menubar

by Johannes.Hofmann＠gmx.de

On Tue, Oct 07, 2008 at 06:12:47PM +0000, corvid wrote: > Johannes wrote: > > Excellent. From previous announcements I'd expect the next weekly > > fltk2 snapshot by friday. > > Is there anything left we need for the release? > > What about the binary and config file name? > > We have to remember to take clear_double_buffer out before releasing. > I thought we would keep it. Without it things get awfully slow here with more than 5 windows. Also all the backBuffer stuff in FltkViewBase would be unnecessary then. Are you seeing any problems with clear_double_buffer()? Cheers, Johannes

Oct. 7, 2008

patch: close windows from menubar

by jcid＠dillo.org

On Tue, Oct 07, 2008 at 06:22:20PM +0200, Johannes Hofmann wrote: > On Tue, Oct 07, 2008 at 09:59:20AM -0400, Jorge Arellano Cid wrote: > > On Mon, Oct 06, 2008 at 02:14:19PM +0000, corvid wrote: > > > Jorge wrote: > > > > From: > > > > > > > > 1.- the mini_bug.xpm FLTK2 fix. > > > > 2.- the focused textarea callback issue. > > > > 3.- Alt-X crash in the menu. > > > > 4.- hardcoded 128 tabs. > > > > 5.- leaving-the-window nav_expecting problem. > > > > 6.- redraw storms (TabGroup pager) > > > > 7.- CTRL+q ALT+q don't work from File menu. > > > > > > > > We have: > > > > > > > > 1, 2) have patches (for FLTK), and we could wait for a new release > > > > or code workarounds for them in dillo. > > > > 3) Fixed > > > > 4) Easy to code a 128 limit in dillo and avoid the segfault. > > > > 5) Fixed. > > > > 6) Fixed. > > > > 7) FLTK problem, no patch yet. No CRASH with Dillo. > > > > > > I see that Bill Spitzak has committed (1) and RAW_LABEL. > > > It may be that I had too little faith in the FLTKers... > > > > And the TEXTAREA fix! > > > > http://fltk.org/newsgroups.php?s3559+gfltk.commit+v3568+T0 > > Excellent. From previous announcements I'd expect the next weekly > fltk2 snapshot by friday. Well, maybe Sturday could be a good release day... > Is there anything left we need for the release? > What about the binary and config file name? I think: binary name: dillo version : 2.0 rc file : dillo2rc is OK. Comments? -- Cheers Jorge.-

Oct. 7, 2008

patch: close windows from menubar

by corvid＠lavabit.com

Johannes wrote: > Excellent. From previous announcements I'd expect the next weekly > fltk2 snapshot by friday. > Is there anything left we need for the release? > What about the binary and config file name? We have to remember to take clear_double_buffer out before releasing.

Oct. 7, 2008

patch: close windows from menubar

by Johannes.Hofmann＠gmx.de

On Tue, Oct 07, 2008 at 09:59:20AM -0400, Jorge Arellano Cid wrote: > On Mon, Oct 06, 2008 at 02:14:19PM +0000, corvid wrote: > > Jorge wrote: > > > From: > > > > > > 1.- the mini_bug.xpm FLTK2 fix. > > > 2.- the focused textarea callback issue. > > > 3.- Alt-X crash in the menu. > > > 4.- hardcoded 128 tabs. > > > 5.- leaving-the-window nav_expecting problem. > > > 6.- redraw storms (TabGroup pager) > > > 7.- CTRL+q ALT+q don't work from File menu. > > > > > > We have: > > > > > > 1, 2) have patches (for FLTK), and we could wait for a new release > > > or code workarounds for them in dillo. > > > 3) Fixed > > > 4) Easy to code a 128 limit in dillo and avoid the segfault. > > > 5) Fixed. > > > 6) Fixed. > > > 7) FLTK problem, no patch yet. No CRASH with Dillo. > > > > I see that Bill Spitzak has committed (1) and RAW_LABEL. > > It may be that I had too little faith in the FLTKers... > > And the TEXTAREA fix! > > http://fltk.org/newsgroups.php?s3559+gfltk.commit+v3568+T0 Excellent. From previous announcements I'd expect the next weekly fltk2 snapshot by friday. Is there anything left we need for the release? What about the binary and config file name? Cheers, Johannes

Oct. 7, 2008

panel_size=tiny have no menu

by jcid＠dillo.org

On Mon, Oct 06, 2008 at 12:28:35PM -0400, Jorge Arellano Cid wrote: > Hi, > > On Sun, Oct 05, 2008 at 07:50:37PM +0100, higuita wrote: > > hi > > > > i use dillo with panel_size=tiny and now with the tabs, i wanted to > > close some of then... but as there is no close button nor tab menu, i was > > searching for the shortcut for close tabs... > > > > i search the mailling list and it points to the menu entry and the > > ctr+Q, and at least the last one works fine. > > > > what i found is that if i setup panel_size=tiny, i have no menu, > > in dillo1 there was a F next to the bookmark > > > > Not that the File menu is very important, but here is the bug > > report :) > > Yes, quite sinilar to this thread: > > http://lists.auriga.wearlab.de/pipermail/dillo-dev/2008-September/004952.ht… > > That needs to be fixed. > I'm throwing some lines at it... Well, it's a lot of code, so it will have to wait until after the release to get into CVS. -- Cheers Jorge.-

Oct. 7, 2008

patch: close windows from menubar

by jcid＠dillo.org

On Mon, Oct 06, 2008 at 02:14:19PM +0000, corvid wrote: > Jorge wrote: > > From: > > > > 1.- the mini_bug.xpm FLTK2 fix. > > 2.- the focused textarea callback issue. > > 3.- Alt-X crash in the menu. > > 4.- hardcoded 128 tabs. > > 5.- leaving-the-window nav_expecting problem. > > 6.- redraw storms (TabGroup pager) > > 7.- CTRL+q ALT+q don't work from File menu. > > > > We have: > > > > 1, 2) have patches (for FLTK), and we could wait for a new release > > or code workarounds for them in dillo. > > 3) Fixed > > 4) Easy to code a 128 limit in dillo and avoid the segfault. > > 5) Fixed. > > 6) Fixed. > > 7) FLTK problem, no patch yet. No CRASH with Dillo. > > I see that Bill Spitzak has committed (1) and RAW_LABEL. > It may be that I had too little faith in the FLTKers... And the TEXTAREA fix! http://fltk.org/newsgroups.php?s3559+gfltk.commit+v3568+T0 -- Cheers Jorge.-

Oct. 7, 2008

patch: close windows from menubar

by jcid＠dillo.org

On Mon, Oct 06, 2008 at 02:14:19PM +0000, corvid wrote: > Jorge wrote: > > From: > > > > 1.- the mini_bug.xpm FLTK2 fix. > > 2.- the focused textarea callback issue. > > 3.- Alt-X crash in the menu. > > 4.- hardcoded 128 tabs. > > 5.- leaving-the-window nav_expecting problem. > > 6.- redraw storms (TabGroup pager) > > 7.- CTRL+q ALT+q don't work from File menu. > > > > We have: > > > > 1, 2) have patches (for FLTK), and we could wait for a new release > > or code workarounds for them in dillo. > > 3) Fixed > > 4) Easy to code a 128 limit in dillo and avoid the segfault. > > 5) Fixed. > > 6) Fixed. > > 7) FLTK problem, no patch yet. No CRASH with Dillo. > > I see that Bill Spitzak has committed (1) and RAW_LABEL. > It may be that I had too little faith in the FLTKers... Given the quick response by the FLTK team, it may make sense to wait for the next release and release dillo after that. Meanwhile I could give some time to the File menu issue, and you may give a look at the session cookies. -- Cheers Jorge.-

Oct. 6, 2008

panel_size=tiny have no menu

by jcid＠dillo.org

Hi, On Sun, Oct 05, 2008 at 07:50:37PM +0100, higuita wrote: > hi > > i use dillo with panel_size=tiny and now with the tabs, i wanted to > close some of then... but as there is no close button nor tab menu, i was > searching for the shortcut for close tabs... > > i search the mailling list and it points to the menu entry and the > ctr+Q, and at least the last one works fine. > > what i found is that if i setup panel_size=tiny, i have no menu, > in dillo1 there was a F next to the bookmark > > Not that the File menu is very important, but here is the bug > report :) Yes, quite sinilar to this thread: http://lists.auriga.wearlab.de/pipermail/dillo-dev/2008-September/004952.ht… That needs to be fixed. I'm throwing some lines at it... -- Cheers Jorge.-

Oct. 6, 2008

patch: close windows from menubar

by corvid＠lavabit.com

Jorge wrote: > From: > > 1.- the mini_bug.xpm FLTK2 fix. > 2.- the focused textarea callback issue. > 3.- Alt-X crash in the menu. > 4.- hardcoded 128 tabs. > 5.- leaving-the-window nav_expecting problem. > 6.- redraw storms (TabGroup pager) > 7.- CTRL+q ALT+q don't work from File menu. > > We have: > > 1, 2) have patches (for FLTK), and we could wait for a new release > or code workarounds for them in dillo. > 3) Fixed > 4) Easy to code a 128 limit in dillo and avoid the segfault. > 5) Fixed. > 6) Fixed. > 7) FLTK problem, no patch yet. No CRASH with Dillo. I see that Bill Spitzak has committed (1) and RAW_LABEL. It may be that I had too little faith in the FLTKers...

Oct. 6, 2008

patch: fix the toggle button size

by jcid＠dillo.org

On Sun, Oct 05, 2008 at 06:50:49PM +0200, Johannes Hofmann wrote: > On Sun, Oct 05, 2008 at 12:41:37PM -0400, Jorge Arellano Cid wrote: > > On Sat, Oct 04, 2008 at 12:12:30AM +0000, corvid wrote: > > > If you try setting font_factor to 2, you will see that check/radio buttons > > > are partly overwritten by their accompanying text. > > > > > > I hope there's a clever way to avoid the getFont() that I use in the patch. > > Please try attached patch. Committed! -- Cheers Jorge.-

Oct. 5, 2008

panel_size=tiny have no menu

by higuita7＠yahoo.co.uk

hi i use dillo with panel_size=tiny and now with the tabs, i wanted to close some of then... but as there is no close button nor tab menu, i was searching for the shortcut for close tabs... i search the mailling list and it points to the menu entry and the ctr+Q, and at least the last one works fine. what i found is that if i setup panel_size=tiny, i have no menu, in dillo1 there was a F next to the bookmark Not that the File menu is very important, but here is the bug report :) Thanks higuita -- Naturally the common people don't want war... but after all it is the leaders of a country who determine the policy, and it is always a simple matter to drag the people along, whether it is a democracy, or a fascist dictatorship, or a parliament, or a communist dictatorship. Voice or no voice, the people can always be brought to the bidding of the leaders. That is easy. All you have to do is tell them they are being attacked, and denounce the pacifists for lack of patriotism and exposing the country to danger. It works the same in every country. -- Hermann Goering, Nazi and war criminal, 1883-1946

Oct. 5, 2008

patch: fix the toggle button size

by Johannes.Hofmann＠gmx.de

On Sun, Oct 05, 2008 at 12:41:37PM -0400, Jorge Arellano Cid wrote: > On Sat, Oct 04, 2008 at 12:12:30AM +0000, corvid wrote: > > If you try setting font_factor to 2, you will see that check/radio buttons > > are partly overwritten by their accompanying text. > > > > I hope there's a clever way to avoid the getFont() that I use in the patch. Please try attached patch. Cheers, Johannes

Oct. 5, 2008

patch: fix the toggle button size

by jcid＠dillo.org

On Sat, Oct 04, 2008 at 12:12:30AM +0000, corvid wrote: > If you try setting font_factor to 2, you will see that check/radio buttons > are partly overwritten by their accompanying text. > > I hope there's a clever way to avoid the getFont() that I use in the patch. Committed. -- Cheers Jorge.-

Oct. 5, 2008

patch: print numeric addresses instead of pointer

by 4winter＠informatik.uni-hamburg.de

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jorge Arellano Cid wrote: > Not yet committed, mainly because the feature freeze for release. > (although the small fix went in). > >> The attached patch fixes this and >> also adds the function >> >> void a_DilloHost_to_String(DilloHost *host, char *dst, size_t size) > > If you finally get to a complete fix, please name exported functions > in dns.c with the "a_Dns_" prefix. > e.g. a_Dns_host_to_string Sure thing. Updated patch is attached. > Patches are more than welcomed! And you shall have em ;) While tracking my ipv6 related problems through dillos source files I noticed *a lot* of ENABLE_IPV6 #ifdefs... Is this necessary for portability or do you want to be able to strip ipv6 support from certain builds? If portability at compile time is not the issue I would vote for the removal of those #ifdefs, if there's worry about the executables size, let's see: $ wc --bytes with{,out}/dillo2/src/dillo-fltk 3311349 with/dillo2/src/dillo-fltk 3309974 without/dillo2/src/dillo-fltk Well, IPv6 costs 1375 bytes on my system, I don't see any problem here, but I think this could be reduced. Many of those ipv6 related #ifdefs duplicate quite a lot of code. One tiny little cleanup patch is attached (please note that it depends on the a_Dns_DilloHost_to_String function). Justus -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFI5/zFoPmwNWhsaZYRAiEIAJ9qNt+kRIN0khlpladZ3eD8r3fl6QCdHoCD VpRIfaqp6KA0Z6XgS+2wU2o= =39Iv -----END PGP SIGNATURE-----

Oct. 5, 2008

viewport losing focus?

by jcid＠dillo.org

On Sat, Oct 04, 2008 at 09:39:09PM +0000, corvid wrote: > If I start dillo and open > > <TABLE width=2600> > <TR><TD>text > </TABLE> > > I can press right arrow, but then when I press left arrow, > they stop working and I see the bottom half of "Label" written > over the top of the back and forward buttons, suggesting > that tabs may be involved somehow. Fixed in CVS. -- Cheers Jorge.-

Oct. 5, 2008

patch: fix numeric ipv6 address handling

by 4winter＠informatik.uni-hamburg.de

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hey all :) there were two problems preventing the use of numeric ipv6 literals: 1. splitting the authority in hostname and port the attached patch fixes the handling of numeric ipv6 addresses entered into the url bar. a_Url_hostname got the colons delimiting the 8 groups of hexadecimal digits of an ipv6 address confused with a port number. 2. joining hostname and port for the Host: header a_Http_make_query_str used to build the Host: header by concatenating the url->hostname with the port number in case it's not the default port. Unfortunately this breaks with numeric ipv6 addresses since an ipv6 literal has to be enclosed with square brackets when used in urls and Host: header fields (according to my experiments and my interpretation of rfc 2616 section 14.23 ("Host header") and 3.2.2 ("http URL")). I would therefore suggest to use the original authority string obtained from the url. Patch is attached. Justus -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFI6AEJoPmwNWhsaZYRAkg1AKCMHotNlq93MMe2A4d/mcki3w8ScwCgqUWY 94TggAK4U7NNwLrXC+RPsq8= =Ajfy -----END PGP SIGNATURE-----

Oct. 5, 2008

viewport losing focus?

by corvid＠lavabit.com

If I start dillo and open <TABLE width=2600> <TR><TD>text </TABLE> I can press right arrow, but then when I press left arrow, they stop working and I see the bottom half of "Label" written over the top of the back and forward buttons, suggesting that tabs may be involved somehow.

Oct. 4, 2008

patch: print numeric addresses instead of pointer

by jcid＠dillo.org

On Sat, Oct 04, 2008 at 06:24:05PM +0200, Justus Winter wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi everyone :) > > while debugging ipv6 support I noticed that the debug output of > Dns_server(..) was not very helpful since it printed the pointer to the > address list instead of the addresses. Not yet committed, mainly because the feature freeze for release. (although the small fix went in). > The attached patch fixes this and > also adds the function > > void a_DilloHost_to_String(DilloHost *host, char *dst, size_t size) If you finally get to a complete fix, please name exported functions in dns.c with the "a_Dns_" prefix. e.g. a_Dns_host_to_string Patches are more than welcomed! -- Cheers Jorge.-

Oct. 4, 2008

patch: fix dns to ipv6 resolution

by jcid＠dillo.org

Hi Justus, On Sat, Oct 04, 2008 at 06:19:35PM +0200, Justus Winter wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi everyone :) > > I noticed that ipv6 support in dillo2 is somewhat broken. With this tiny > patch hostnames are properly resolved to ipv6 addresses and browsing > over ipv6 works fine but entering a numeric address does not. Committed. -- Cheers Jorge.-

Oct. 4, 2008

patch: close windows from menubar

by jcid＠dillo.org

On Sat, Oct 04, 2008 at 08:24:00PM +0200, Johannes Hofmann wrote: > On Fri, Oct 03, 2008 at 07:05:47PM -0400, Jorge Arellano Cid wrote: > > On Fri, Oct 03, 2008 at 07:02:47PM +0000, corvid wrote: > > > Jorge wrote: > > > > On Fri, Oct 03, 2008 at 01:07:36PM -0400, Jorge Arellano Cid wrote: > > > > > Hi, > > > > > > > > > > Committed. > > > > > > > > > > On Thu, Oct 02, 2008 at 06:58:25PM +0000, corvid wrote: > > > > > > BTW, I notice that ctrl-Q and alt-Q, listed in the menu, don't do anything. > > > > > > > > > > Yeah. > > > > > Even MenuBar::handle() doesn't see them. > > > > > > > > Seems like an FLTK bug/feature. > > > > > > > > If you try ./menu in FLTK's test/ directory, the CTRL shortcuts > > > > for the "Edit" menu don't work. > > > > > > > > Time to ask or to STR? > > > > > > I see that if I uncomment the > > > // if (widget->active() && widget->test_shortcut(false)) { > > > // setitem(p, menu, item); > > > // lastkey = 0; > > > // goto EXECUTE; > > > // } > > > in MWindow::handle(int event) in Menu_popup.cxx, ctrl-Q and alt-Q work. > > > > OK, it's clear it was deactivated by some reason... > > > > From: > > > > 1.- the mini_bug.xpm FLTK2 fix. > > 2.- the focused textarea callback issue. > > 3.- Alt-X crash in the menu. > > 4.- hardcoded 128 tabs. > > 5.- leaving-the-window nav_expecting problem. > > 6.- redraw storms (TabGroup pager) > > 7.- CTRL+q ALT+q don't work from File menu. > > > > We have: > > > > 1, 2) have patches (for FLTK), and we could wait for a new release > > or code workarounds for them in dillo. > > 3) Fixed > > 4) Easy to code a 128 limit in dillo and avoid the segfault. > > Patch attached. Committed. BTW, I introduced the "WORKAROUND:" tag (akin to "BUG:" and "TODO:"). -- Cheers Jorge.-

Oct. 4, 2008

patch: close windows from menubar

by Johannes.Hofmann＠gmx.de

On Fri, Oct 03, 2008 at 07:05:47PM -0400, Jorge Arellano Cid wrote: > On Fri, Oct 03, 2008 at 07:02:47PM +0000, corvid wrote: > > Jorge wrote: > > > On Fri, Oct 03, 2008 at 01:07:36PM -0400, Jorge Arellano Cid wrote: > > > > Hi, > > > > > > > > Committed. > > > > > > > > On Thu, Oct 02, 2008 at 06:58:25PM +0000, corvid wrote: > > > > > BTW, I notice that ctrl-Q and alt-Q, listed in the menu, don't do anything. > > > > > > > > Yeah. > > > > Even MenuBar::handle() doesn't see them. > > > > > > Seems like an FLTK bug/feature. > > > > > > If you try ./menu in FLTK's test/ directory, the CTRL shortcuts > > > for the "Edit" menu don't work. > > > > > > Time to ask or to STR? > > > > I see that if I uncomment the > > // if (widget->active() && widget->test_shortcut(false)) { > > // setitem(p, menu, item); > > // lastkey = 0; > > // goto EXECUTE; > > // } > > in MWindow::handle(int event) in Menu_popup.cxx, ctrl-Q and alt-Q work. > > OK, it's clear it was deactivated by some reason... > > From: > > 1.- the mini_bug.xpm FLTK2 fix. > 2.- the focused textarea callback issue. > 3.- Alt-X crash in the menu. > 4.- hardcoded 128 tabs. > 5.- leaving-the-window nav_expecting problem. > 6.- redraw storms (TabGroup pager) > 7.- CTRL+q ALT+q don't work from File menu. > > We have: > > 1, 2) have patches (for FLTK), and we could wait for a new release > or code workarounds for them in dillo. > 3) Fixed > 4) Easy to code a 128 limit in dillo and avoid the segfault. Patch attached. Cheers, Johannes

Oct. 4, 2008

Javascript engine

by 4winter＠informatik.uni-hamburg.de

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jorge Arellano Cid wrote: > Disclaimer: I'm a newbie on JavaScript. JavaScript is a very cool language. Don't believe anyone telling you otherwise ;) > Does anybody know about a lightweight javascript engine we > can use with dillo? > > From what I've seen, SEE (Simple ECMAScript Engine), looks > like a good candidate. This depends entirely on your criteria :) SEE spidermonkey google v8 sloc ~31000 ~91000 ~77000 language c c c++/c license bsd {m,g,lg}pl bsd 100000 objects / s 5.6 0.4 0.2 1000000 objects / s ? 3.3 1.3 Slocs counted via sloccount, tests run on my laptop (core2duo 1.6GHz) run multiple times and averaged using a quick glance. Test script for 1000000 objects attached. see-shell didn't complete the 1000000 object run within 5 minutes of burning my cpu so I killed it. And there are some more things to consider like feature completeness. The mozilla guys are doing some sexy stuff like E4X and JavaScript 1.7 comes with syntactic sugar like array comprehension. The SEE site specifies that they are JavaScript 1.5 compliant, and although it seems actively maintained (latest 3.0 snapshot is dated 2008-02-10) I am not sure if they can keep up with the latest developments. Googles V8 does some interesting tricks like avoiding costly property lookups and generating native machine code, but this reduces portability (not sure if code generation is necessary or an add-on). The site states that it runs on "Windows XP and Vista, Mac OS X 10.5 (Leopard), and Linux systems that use IA-32 or ARM". I built an 32bit executable on linux/x86_64 that worked fine. I would suggest to pick one engine based on the ease of embedding and to develop a clean interface for scripting languages while integrating the chosen engine into dillo. If this is doable (not sure it is, but one can hope) it should be relatively easy to use the very same interface for other implementations and or languages. How cool would it be to hand configure parameters like --with-language javascript:spidermonkey - --with-language lua --with-language python :) And who knows what the next big thing of the web 3.0 will be? Grusszeugs, Justus -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFI57OToPmwNWhsaZYRAhtDAJ41dDSliA6jcKSUhw+k2/OrhY1QTgCdFtAD BnM+CV8oujgZLHz7NjY9fqw= =D1fS -----END PGP SIGNATURE-----

Oct. 4, 2008

patch: print numeric addresses instead of pointer

by 4winter＠informatik.uni-hamburg.de

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi everyone :) while debugging ipv6 support I noticed that the debug output of Dns_server(..) was not very helpful since it printed the pointer to the address list instead of the addresses. The attached patch fixes this and also adds the function void a_DilloHost_to_String(DilloHost *host, char *dst, size_t size) to dns.{c,h}. Justus -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFI55iloPmwNWhsaZYRAmP9AJ4/6msoDF59IMdpzWh0dZQhIqFgEACcDbBC wiaiHuwdsbOhU8o0ViA7a6M= =m7XD -----END PGP SIGNATURE-----

Oct. 4, 2008

patch: fix dns to ipv6 resolution

by 4winter＠informatik.uni-hamburg.de

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi everyone :) I noticed that ipv6 support in dillo2 is somewhat broken. With this tiny patch hostnames are properly resolved to ipv6 addresses and browsing over ipv6 works fine but entering a numeric address does not. Justus -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFI55eXoPmwNWhsaZYRAoCbAJ41ZA66N5zDWetCia5r4OUZmLfwngCfc0WT i2J3z0qscSGR1tuitxAX254= =GJLN -----END PGP SIGNATURE-----

Oct. 4, 2008

patch: close windows from menubar

by jcid＠dillo.org

On Sat, Oct 04, 2008 at 12:37:34AM +0000, corvid wrote: > Jorge wrote: > > From: > > > > 1.- the mini_bug.xpm FLTK2 fix. > > 2.- the focused textarea callback issue. > > 3.- Alt-X crash in the menu. > > 4.- hardcoded 128 tabs. > > 5.- leaving-the-window nav_expecting problem. > > 6.- redraw storms (TabGroup pager) > > 7.- CTRL+q ALT+q don't work from File menu. > > > > We have: > > > > 1, 2) have patches (for FLTK), and we could wait for a new release > > or code workarounds for them in dillo. > > 3) Fixed > > 4) Easy to code a 128 limit in dillo and avoid the segfault. > > 5) Fixed. > > 6) Fixed. > > 7) FLTK problem, no patch yet. No CRASH with Dillo. > > Also I'm seeing that findbar problem. > Load a page. ^F to open the findbar. Click in the viewport. Try to click in > the findbar again. Can't type in it. (Works fine if you use ^F to return > to it, though.) Fixed in CVS. > > What do we do? > > > > a) Contact FLTK developers and wait for a patched release, then > > workaround the rest (if any) in dillo and release. > > b) Workaround in dillo and release. > > > > Comments? > > Trying to get them to fix bugs and apply those that Johannes has > given them is good, but at the same time I think I would act as if > nothing will come of it -- working around what can be worked around > easily and preparing for release. I'd hate to wait while nothing > happens...and nothing happens...and nothing continues to happen. > > And, if it becomes necessary, a patched FLTK2 snapshot can be placed > on dillo.org until they fix the official one. Could be. I'd like to provide a patched FLTK2 tarball from our site, just to keep workarounds out of dillo tree, but some people may want to try dillo2 with their distro-provided FLTK2. In that case we may provide a dillo2 tarball for our patched FLTK2, and also a dillo-workarounds patch for the official FLTK2. Anyway, it'd be good to ask the FLTK team... -- Cheers Jorge.-

Oct. 4, 2008

patch: close windows from menubar

by corvid＠lavabit.com

Jorge wrote: > From: > > 1.- the mini_bug.xpm FLTK2 fix. > 2.- the focused textarea callback issue. > 3.- Alt-X crash in the menu. > 4.- hardcoded 128 tabs. > 5.- leaving-the-window nav_expecting problem. > 6.- redraw storms (TabGroup pager) > 7.- CTRL+q ALT+q don't work from File menu. > > We have: > > 1, 2) have patches (for FLTK), and we could wait for a new release > or code workarounds for them in dillo. > 3) Fixed > 4) Easy to code a 128 limit in dillo and avoid the segfault. > 5) Fixed. > 6) Fixed. > 7) FLTK problem, no patch yet. No CRASH with Dillo. Also I'm seeing that findbar problem. Load a page. ^F to open the findbar. Click in the viewport. Try to click in the findbar again. Can't type in it. (Works fine if you use ^F to return to it, though.) > What do we do? > > a) Contact FLTK developers and wait for a patched release, then > workaround the rest (if any) in dillo and release. > b) Workaround in dillo and release. > > Comments? Trying to get them to fix bugs and apply those that Johannes has given them is good, but at the same time I think I would act as if nothing will come of it -- working around what can be worked around easily and preparing for release. I'd hate to wait while nothing happens...and nothing happens...and nothing continues to happen. And, if it becomes necessary, a patched FLTK2 snapshot can be placed on dillo.org until they fix the official one.

Oct. 4, 2008

patch: fix the toggle button size

by corvid＠lavabit.com

If you try setting font_factor to 2, you will see that check/radio buttons are partly overwritten by their accompanying text. I hope there's a clever way to avoid the getFont() that I use in the patch.

Oct. 4, 2008

patch: close windows from menubar

by jcid＠dillo.org

On Fri, Oct 03, 2008 at 07:02:47PM +0000, corvid wrote: > Jorge wrote: > > On Fri, Oct 03, 2008 at 01:07:36PM -0400, Jorge Arellano Cid wrote: > > > Hi, > > > > > > Committed. > > > > > > On Thu, Oct 02, 2008 at 06:58:25PM +0000, corvid wrote: > > > > BTW, I notice that ctrl-Q and alt-Q, listed in the menu, don't do anything. > > > > > > Yeah. > > > Even MenuBar::handle() doesn't see them. > > > > Seems like an FLTK bug/feature. > > > > If you try ./menu in FLTK's test/ directory, the CTRL shortcuts > > for the "Edit" menu don't work. > > > > Time to ask or to STR? > > I see that if I uncomment the > // if (widget->active() && widget->test_shortcut(false)) { > // setitem(p, menu, item); > // lastkey = 0; > // goto EXECUTE; > // } > in MWindow::handle(int event) in Menu_popup.cxx, ctrl-Q and alt-Q work. OK, it's clear it was deactivated by some reason... From: 1.- the mini_bug.xpm FLTK2 fix. 2.- the focused textarea callback issue. 3.- Alt-X crash in the menu. 4.- hardcoded 128 tabs. 5.- leaving-the-window nav_expecting problem. 6.- redraw storms (TabGroup pager) 7.- CTRL+q ALT+q don't work from File menu. We have: 1, 2) have patches (for FLTK), and we could wait for a new release or code workarounds for them in dillo. 3) Fixed 4) Easy to code a 128 limit in dillo and avoid the segfault. 5) Fixed. 6) Fixed. 7) FLTK problem, no patch yet. No CRASH with Dillo. What do we do? a) Contact FLTK developers and wait for a patched release, then workaround the rest (if any) in dillo and release. b) Workaround in dillo and release. Comments? -- Cheers Jorge.-

Oct. 4, 2008

patch: close windows from menubar

by corvid＠lavabit.com

Jorge wrote: > On Fri, Oct 03, 2008 at 01:07:36PM -0400, Jorge Arellano Cid wrote: > > Hi, > > > > Committed. > > > > On Thu, Oct 02, 2008 at 06:58:25PM +0000, corvid wrote: > > > BTW, I notice that ctrl-Q and alt-Q, listed in the menu, don't do anything. > > > > Yeah. > > Even MenuBar::handle() doesn't see them. > > Seems like an FLTK bug/feature. > > If you try ./menu in FLTK's test/ directory, the CTRL shortcuts > for the "Edit" menu don't work. > > Time to ask or to STR? I see that if I uncomment the // if (widget->active() && widget->test_shortcut(false)) { // setitem(p, menu, item); // lastkey = 0; // goto EXECUTE; // } in MWindow::handle(int event) in Menu_popup.cxx, ctrl-Q and alt-Q work.

Oct. 3, 2008

what crashes remain?

by jcid＠dillo.org

On Fri, Oct 03, 2008 at 06:32:50PM +0000, corvid wrote: > Jorge wrote: > > On Wed, Oct 01, 2008 at 10:47:45PM +0000, corvid wrote: > > > Jorge wrote: > > > > On Wed, Oct 01, 2008 at 09:46:06PM +0000, corvid wrote: > > > > > Jorge wrote: > > > > > > On Wed, Oct 01, 2008 at 02:48:10PM +0000, corvid wrote: > > > > > > > Also, I found out why loading was sometimes randomly disabled (as mentioned > > > > > > > yesterday). You know how leaving the window sometimes causes an extra > > > > > > > Nav_open_url()? > > > > > > > > > > > > No, I don't know. > > > > > > How is it triggered? > > > > > > > > > > Really? I've gotten them often throughout this whole fltk era. > > > > > Taking out my fix, here's a breakpoint on Nav_open_url, > > > > > triggered by leaving the window: > > > > > > > > > > Breakpoint 1, Nav_open_url (bw=0x81b18e8, url=0x81c3998, offset=0) at nav.c:201 > > > > > 201 MSG("Nav_open_url: new url='%s'\n", URL_STR_(url)); > > > > > #0 Nav_open_url (bw=0x81b18e8, url=0x81c3998, offset=0) at nav.c:201 > > > > > #1 0x0805cd4d in a_Nav_push (bw=0x81b18e8, url=0x81c3998) at nav.c:350 > > > > > #2 0x080554ae in a_UIcmd_open_urlstr (vbw=0x81b18e8, urlstr=0x81c44b8 "http://www.dillo.org") at uicmd.cc:323 > > > > > #3 0x08053c12 in location_cb (wid=0x816c6a8, data=0x815c2d8) at ui.cc:245 > > > > > #4 0x08055fa7 in fltk::Widget::do_callback (this=0x816c6a8) at ../fltk/Widget.h:127 > > > > > #5 0x080e093c in call_pending_if_not (i=0x0) at run.cxx:804 > > > > > #6 0x080e124c in fltk::focus (o=0x0) at run.cxx:868 > > > > > #7 0x080e56f4 in fix_focus () at run.cxx:108 > > > > > #8 0x080e676f in fltk::handle () at x11/run.cxx:1603 > > > > > #9 0x080e7520 in do_queued_events () at x11/run.cxx:399 > > > > > #10 0x080e784c in fl_wait (time_to_wait=1.00000002e+20) at x11/run.cxx:459 > > > > > #11 0x080e78e7 in fltk::wait (time_to_wait=1.00000002e+20) at run.cxx:463 > > > > > #12 0x080e79fe in fltk::run () at run.cxx:399 > > > > > #13 0x0804efab in main (argc=1, argv=0xbffffb34) at dillo.cc:127 > > > > > > > > From the bt it's clear it happens, But how do I trigger/reproduce it. > > > > I've tried moving the mouse pointer out of the window, focusing another > > > > window, etc. With no luck. > > > > > > The reliable way that I'm using > > > (haven't checked how many of these steps/precautions are strictly necessary) > > > - type an url into the Location CustInput and press enter. > > > - don't touch the mouse > > > - when the page has finished loading completely > > > - move the mouse out of the window > > > > > > In case there's some WM interaction, I have fvwm. > > > > OK, I can see the bug with fvwm. > > > > Please check the CVS code. > > It solves the problem here. > > It's working! Form inputs were also checked and FltkEntryResource::setText() calls value() which is a wrapper for text(). -- Cheers Jorge.-

Oct. 3, 2008

what crashes remain?

by corvid＠lavabit.com

Jorge wrote: > On Wed, Oct 01, 2008 at 10:47:45PM +0000, corvid wrote: > > Jorge wrote: > > > On Wed, Oct 01, 2008 at 09:46:06PM +0000, corvid wrote: > > > > Jorge wrote: > > > > > On Wed, Oct 01, 2008 at 02:48:10PM +0000, corvid wrote: > > > > > > Also, I found out why loading was sometimes randomly disabled (as mentioned > > > > > > yesterday). You know how leaving the window sometimes causes an extra > > > > > > Nav_open_url()? > > > > > > > > > > No, I don't know. > > > > > How is it triggered? > > > > > > > > Really? I've gotten them often throughout this whole fltk era. > > > > Taking out my fix, here's a breakpoint on Nav_open_url, > > > > triggered by leaving the window: > > > > > > > > Breakpoint 1, Nav_open_url (bw=0x81b18e8, url=0x81c3998, offset=0) at nav.c:201 > > > > 201 MSG("Nav_open_url: new url='%s'\n", URL_STR_(url)); > > > > #0 Nav_open_url (bw=0x81b18e8, url=0x81c3998, offset=0) at nav.c:201 > > > > #1 0x0805cd4d in a_Nav_push (bw=0x81b18e8, url=0x81c3998) at nav.c:350 > > > > #2 0x080554ae in a_UIcmd_open_urlstr (vbw=0x81b18e8, urlstr=0x81c44b8 "http://www.dillo.org") at uicmd.cc:323 > > > > #3 0x08053c12 in location_cb (wid=0x816c6a8, data=0x815c2d8) at ui.cc:245 > > > > #4 0x08055fa7 in fltk::Widget::do_callback (this=0x816c6a8) at ../fltk/Widget.h:127 > > > > #5 0x080e093c in call_pending_if_not (i=0x0) at run.cxx:804 > > > > #6 0x080e124c in fltk::focus (o=0x0) at run.cxx:868 > > > > #7 0x080e56f4 in fix_focus () at run.cxx:108 > > > > #8 0x080e676f in fltk::handle () at x11/run.cxx:1603 > > > > #9 0x080e7520 in do_queued_events () at x11/run.cxx:399 > > > > #10 0x080e784c in fl_wait (time_to_wait=1.00000002e+20) at x11/run.cxx:459 > > > > #11 0x080e78e7 in fltk::wait (time_to_wait=1.00000002e+20) at run.cxx:463 > > > > #12 0x080e79fe in fltk::run () at run.cxx:399 > > > > #13 0x0804efab in main (argc=1, argv=0xbffffb34) at dillo.cc:127 > > > > > > From the bt it's clear it happens, But how do I trigger/reproduce it. > > > I've tried moving the mouse pointer out of the window, focusing another > > > window, etc. With no luck. > > > > The reliable way that I'm using > > (haven't checked how many of these steps/precautions are strictly necessary) > > - type an url into the Location CustInput and press enter. > > - don't touch the mouse > > - when the page has finished loading completely > > - move the mouse out of the window > > > > In case there's some WM interaction, I have fvwm. > > OK, I can see the bug with fvwm. > > Please check the CVS code. > It solves the problem here. It's working!

Oct. 3, 2008

patch: close windows from menubar

by jcid＠dillo.org

On Fri, Oct 03, 2008 at 01:07:36PM -0400, Jorge Arellano Cid wrote: > Hi, > > Committed. > > On Thu, Oct 02, 2008 at 06:58:25PM +0000, corvid wrote: > > BTW, I notice that ctrl-Q and alt-Q, listed in the menu, don't do anything. > > Yeah. > Even MenuBar::handle() doesn't see them. Seems like an FLTK bug/feature. If you try ./menu in FLTK's test/ directory, the CTRL shortcuts for the "Edit" menu don't work. Time to ask or to STR? -- Cheers Jorge.-

Oct. 3, 2008

patch: close windows from menubar

by jcid＠dillo.org

Hi, Committed. On Thu, Oct 02, 2008 at 06:58:25PM +0000, corvid wrote: > BTW, I notice that ctrl-Q and alt-Q, listed in the menu, don't do anything. Yeah. Even MenuBar::handle() doesn't see them. -- Cheers Jorge.-

Oct. 3, 2008

what crashes remain?

by jcid＠dillo.org

On Wed, Oct 01, 2008 at 10:47:45PM +0000, corvid wrote: > Jorge wrote: > > On Wed, Oct 01, 2008 at 09:46:06PM +0000, corvid wrote: > > > Jorge wrote: > > > > On Wed, Oct 01, 2008 at 02:48:10PM +0000, corvid wrote: > > > > > Also, I found out why loading was sometimes randomly disabled (as mentioned > > > > > yesterday). You know how leaving the window sometimes causes an extra > > > > > Nav_open_url()? > > > > > > > > No, I don't know. > > > > How is it triggered? > > > > > > Really? I've gotten them often throughout this whole fltk era. > > > Taking out my fix, here's a breakpoint on Nav_open_url, > > > triggered by leaving the window: > > > > > > Breakpoint 1, Nav_open_url (bw=0x81b18e8, url=0x81c3998, offset=0) at nav.c:201 > > > 201 MSG("Nav_open_url: new url='%s'\n", URL_STR_(url)); > > > #0 Nav_open_url (bw=0x81b18e8, url=0x81c3998, offset=0) at nav.c:201 > > > #1 0x0805cd4d in a_Nav_push (bw=0x81b18e8, url=0x81c3998) at nav.c:350 > > > #2 0x080554ae in a_UIcmd_open_urlstr (vbw=0x81b18e8, urlstr=0x81c44b8 "http://www.dillo.org") at uicmd.cc:323 > > > #3 0x08053c12 in location_cb (wid=0x816c6a8, data=0x815c2d8) at ui.cc:245 > > > #4 0x08055fa7 in fltk::Widget::do_callback (this=0x816c6a8) at ../fltk/Widget.h:127 > > > #5 0x080e093c in call_pending_if_not (i=0x0) at run.cxx:804 > > > #6 0x080e124c in fltk::focus (o=0x0) at run.cxx:868 > > > #7 0x080e56f4 in fix_focus () at run.cxx:108 > > > #8 0x080e676f in fltk::handle () at x11/run.cxx:1603 > > > #9 0x080e7520 in do_queued_events () at x11/run.cxx:399 > > > #10 0x080e784c in fl_wait (time_to_wait=1.00000002e+20) at x11/run.cxx:459 > > > #11 0x080e78e7 in fltk::wait (time_to_wait=1.00000002e+20) at run.cxx:463 > > > #12 0x080e79fe in fltk::run () at run.cxx:399 > > > #13 0x0804efab in main (argc=1, argv=0xbffffb34) at dillo.cc:127 > > > > From the bt it's clear it happens, But how do I trigger/reproduce it. > > I've tried moving the mouse pointer out of the window, focusing another > > window, etc. With no luck. > > The reliable way that I'm using > (haven't checked how many of these steps/precautions are strictly necessary) > - type an url into the Location CustInput and press enter. > - don't touch the mouse > - when the page has finished loading completely > - move the mouse out of the window > > In case there's some WM interaction, I have fvwm. OK, I can see the bug with fvwm. Please check the CVS code. It solves the problem here. -- Cheers Jorge.-

Oct. 3, 2008

an experiment regarding cross site request forgery

by corvid＠lavabit.com

I wrote: > Johannes wrote: > > On Wed, Oct 01, 2008 at 09:33:09PM +0000, corvid wrote: > > > Justus wrote: > > > > Johannes Hofmann wrote: > > > > > Perhaps we should be more careful when to send out a cookie. > > > > > What about not sending cookies with image requests, if the host of > > > > > the image url is different from the one in the main page? > > > > > What do other browser do about this? > > > > > > > > Yes, I think this is the way to go. One need to decide when to send out > > > > authentication credentials (legitimate session) and when to strip them > > > > (CSRF attempt). Martin Johns and I developed a firefox extension [0] > > > > that does exactly this. Please see [1] pages 29 - 37 or [2] for more > > > > information. [1] is also a pretty good introduction to CSRF. Please note > > > > that the browser independent proxy solution is deprecated (but should > > > > work unless the twisted framework changed its api too much) and the > > > > firefox extension is somewhat unmaintained at the moment... > > > > > > Having done some reading now: > > > So for an HTTP redirect or an image request, A->B, > > > I gather up the cookies that I would send when asking for B > > > and discard those that I would not send if I were asking for A? > > > > Sounds good. In which cases this will not discard all cookies? > I should also mention that it does have the virtue of being easy to implement, so it wouldn't take much to be able to try it out. RFC 2965 mentioned not accepting the cookies that you get back from an untrusted request either, which is an interesting thought.

Oct. 3, 2008

an experiment regarding cross site request forgery

by corvid＠lavabit.com

Johannes wrote: > On Wed, Oct 01, 2008 at 09:33:09PM +0000, corvid wrote: > > Justus wrote: > > > Johannes Hofmann wrote: > > > > Perhaps we should be more careful when to send out a cookie. > > > > What about not sending cookies with image requests, if the host of > > > > the image url is different from the one in the main page? > > > > What do other browser do about this? > > > > > > Yes, I think this is the way to go. One need to decide when to send out > > > authentication credentials (legitimate session) and when to strip them > > > (CSRF attempt). Martin Johns and I developed a firefox extension [0] > > > that does exactly this. Please see [1] pages 29 - 37 or [2] for more > > > information. [1] is also a pretty good introduction to CSRF. Please note > > > that the browser independent proxy solution is deprecated (but should > > > work unless the twisted framework changed its api too much) and the > > > firefox extension is somewhat unmaintained at the moment... > > > > Having done some reading now: > > So for an HTTP redirect or an image request, A->B, > > I gather up the cookies that I would send when asking for B > > and discard those that I would not send if I were asking for A? > > Sounds good. In which cases this will not discard all cookies? Well... if we had two johannes.de cookies and one had the Secure attribute, then if http://johannes.de redirected to https://johannes.de, we'd send one cookie, even though the server will probably expect both, and it's not an uncommon sort of redirect, so it might be bad. But at undergraduates.uni-johannes.de, I lean toward not wanting to trust the requester more than I am really forced to. For that matter, I think the rules let you make cookies for a domain as wide as .uni-johannes.de ..or .co.uk... I don't know. Maybe what cookies do is fundamentally a hard problem, but sometimes it feels like they were quickly hacked together without much concern for anything. Or perhaps the controlling bodies had ad revenue in mind more than anything else.

Oct. 3, 2008

feature freeze

by jcid＠dillo.org

On Thu, Oct 02, 2008 at 10:18:42PM +0100, Jeremy Henty wrote: > On Thu, Oct 02, 2008 at 08:01:58PM +0200, Johannes Hofmann wrote: > > > 6.- redraw storms related to the MenuTabPager (noticed by Jeremy) > > [...] > > 6: Using the ShrinkTabPager avoids the problem > > Here's a (tiny) patch to use the ShrinkTabPager. Committed as workaround for redraw storms. -- Cheers Jorge.-

Oct. 3, 2008

an experiment regarding cross site request forgery

by corvid＠lavabit.com

Justus wrote: > corvid wrote: > > Justus wrote: > >> Johannes Hofmann wrote: > >>> Perhaps we should be more careful when to send out a cookie. > >>> What about not sending cookies with image requests, if the host of > >>> the image url is different from the one in the main page? > >>> What do other browser do about this? > >> Yes, I think this is the way to go. One need to decide when to send out > >> authentication credentials (legitimate session) and when to strip them > >> (CSRF attempt). Martin Johns and I developed a firefox extension [0] > >> that does exactly this. Please see [1] pages 29 - 37 or [2] for more > >> information. [1] is also a pretty good introduction to CSRF. Please note > >> that the browser independent proxy solution is deprecated (but should > >> work unless the twisted framework changed its api too much) and the > >> firefox extension is somewhat unmaintained at the moment... > > > > Having done some reading now: > > So for an HTTP redirect or an image request, A->B, > > I gather up the cookies that I would send when asking for B > > and discard those that I would not send if I were asking for A? > I am not sure I understand your question. > > The basic csrf scenario is the following: > > 1. you log in to some web application hosted at good.org > 2. with the same browser instance using another window or tab (or you > just forget to log out and reused the same window) you visit evil.org > 3. evil.org hosts an html page that triggers an request to good.org, > either using an image/script/style/object/whatever tag in case of an GET > request or using an form and javascript / css to submit the form > 4. your browser sends any authentication credentials like cookies along > with the request since they are associated with the target host thus > allowing evil.org to change the state of your good.org account on your > behalf > > The proper thing to do is to fix this on the server side, but since csrf > isn't as widely known as xss many web applications are vulnerable to > this problem. I understand that there's a distinction between - dillo making the request on the user's behalf because he clicked a link or pressed a button or whatever, knowing the url. This request is made with the user's privileges. - dillo making the request on behalf of some code that caused a redirect or loaded an image (auth, css, javascript, etc. being implemented would result in further cases)... This request is sometimes made with some privileges depending on whether the requesting code has that privilege... So I want to be sure that I understand under what conditions the cookies can be sent. It seems that if the requesting url meets the conditions that would cause me to send it a cookie, then I either _did_ send it that cookie earlier, or it just gave it to me, so I would be (sort of) okay in sending that cookie in a request on its behalf. I see that rfc2965 also has some dot-based rules about "unverifiable transactions"... A bit of looking around the web gives me the impression that all of the various dot things that surround cookies have been an awful mess that don't map well to real-world trust boundaries. (This opera guy, for instance http://my.opera.com/yngve/blog/index.dml/tag/HTTP) Hmm...

Oct. 3, 2008

an experiment regarding cross site request forgery

by Johannes.Hofmann＠gmx.de

On Wed, Oct 01, 2008 at 09:33:09PM +0000, corvid wrote: > Justus wrote: > > Johannes Hofmann wrote: > > > Perhaps we should be more careful when to send out a cookie. > > > What about not sending cookies with image requests, if the host of > > > the image url is different from the one in the main page? > > > What do other browser do about this? > > > > Yes, I think this is the way to go. One need to decide when to send out > > authentication credentials (legitimate session) and when to strip them > > (CSRF attempt). Martin Johns and I developed a firefox extension [0] > > that does exactly this. Please see [1] pages 29 - 37 or [2] for more > > information. [1] is also a pretty good introduction to CSRF. Please note > > that the browser independent proxy solution is deprecated (but should > > work unless the twisted framework changed its api too much) and the > > firefox extension is somewhat unmaintained at the moment... > > Having done some reading now: > So for an HTTP redirect or an image request, A->B, > I gather up the cookies that I would send when asking for B > and discard those that I would not send if I were asking for A? Sounds good. In which cases this will not discard all cookies? Cheers, Johannes

Oct. 3, 2008

feature freeze

by jcid＠dillo.org

On Thu, Oct 02, 2008 at 11:51:31PM +0100, Jeremy Henty wrote: > On Thu, Oct 02, 2008 at 03:20:02PM -0700, Kelson Vibber wrote: > > > [snip: excellent summary of the purpose of the HttpOnly cookie attr] > > > > So long as Dillo doesn't have client-side scripting, the attribute > > can just be ignored. > > OK, patch attached. (NB: the patch context depends on my previous > MSG-enhancing patch, but I think it will apply with a little fuzz even > without it.) Committed as: - MSG("Cookie contains illegal attribute!\n"); + MSG("Cookie contains unknown attribute: '%s'\n", attr); -- Cheers Jorge.-

Oct. 3, 2008

an experiment regarding cross site request forgery

by 4winter＠informatik.uni-hamburg.de

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 corvid wrote: > Justus wrote: >> Johannes Hofmann wrote: >>> Perhaps we should be more careful when to send out a cookie. >>> What about not sending cookies with image requests, if the host of >>> the image url is different from the one in the main page? >>> What do other browser do about this? >> Yes, I think this is the way to go. One need to decide when to send out >> authentication credentials (legitimate session) and when to strip them >> (CSRF attempt). Martin Johns and I developed a firefox extension [0] >> that does exactly this. Please see [1] pages 29 - 37 or [2] for more >> information. [1] is also a pretty good introduction to CSRF. Please note >> that the browser independent proxy solution is deprecated (but should >> work unless the twisted framework changed its api too much) and the >> firefox extension is somewhat unmaintained at the moment... > > Having done some reading now: > So for an HTTP redirect or an image request, A->B, > I gather up the cookies that I would send when asking for B > and discard those that I would not send if I were asking for A? I am not sure I understand your question. The basic csrf scenario is the following: 1. you log in to some web application hosted at good.org 2. with the same browser instance using another window or tab (or you just forget to log out and reused the same window) you visit evil.org 3. evil.org hosts an html page that triggers an request to good.org, either using an image/script/style/object/whatever tag in case of an GET request or using an form and javascript / css to submit the form 4. your browser sends any authentication credentials like cookies along with the request since they are associated with the target host thus allowing evil.org to change the state of your good.org account on your behalf The proper thing to do is to fix this on the server side, but since csrf isn't as widely known as xss many web applications are vulnerable to this problem. Justus -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFI5h9woPmwNWhsaZYRAiGUAJ42ZuicB6aYGYkrjDZj2lSRpB6h1QCcCJ38 +zhCOeq1aO0Q747/tfeAQoU= =4QtQ -----END PGP SIGNATURE-----

Oct. 3, 2008