- Dillo-dev - lists.mailman3.com

keysrc and prefix keys

by corvid＠lavabit.com

Jeremy wrote: > There is one oddity - sometimes Dillo ignores > the Ctrl key so that Ctrl-{Home,End} behave like {Home,End}. This bug > usually disappears after I Ctrl-{Shift,}-tab to some other tab but I > do not know how to consistently cause or resolve the problem. I > suspect that the patch is not the real cause. Does it work to put a check for Home or End with no modifier wherever it makes sense, and then put a breakpoint on that and have a look at the backtrace?

Dec. 16, 2011

keysrc and prefix keys

by onepoint＠starurchin.org

I wrote: > I'll submit the patch for consideration in a few days. OK, here it is. It binds Ctrl-{Home,End} to {first,last}-tab. I find it very useful. There is one oddity - sometimes Dillo ignores the Ctrl key so that Ctrl-{Home,End} behave like {Home,End}. This bug usually disappears after I Ctrl-{Shift,}-tab to some other tab but I do not know how to consistently cause or resolve the problem. I suspect that the patch is not the real cause. Please comment. Regards, Jeremy Henty

Dec. 15, 2011

keysrc and prefix keys

by onepoint＠starurchin.org

Roger wrote: > [...] Jeremy Henty wrote: > >I notice that keys.hh defines KEYS_{FIRST,LAST}_TAB but they are > >not bound to anything. Maybe we could bind them to > >Ctrl-{Home,End}? It seems natural and they could be sensibly > >customised in keysrc without complicating the code. > > What's humorous about all these key binding on Dillo, I rarely ever > use key bindings within a GUI application. At most for Dillo, I use > the mouse buttons and scroll wheel. That may be your style but I use the keyboard a lot to drive Dillo (and like you I use terminal applications a lot). I have a patch to bind KEYS_{FIRST,LAST}_TAB in my local repository and I find it really useful, particularly when I have so many tabs open that they cannot all be displayed in the tab bar. I'll submit the patch for consideration in a few days. Regards, Jeremy Henty

Dec. 14, 2011

keysrc and prefix keys

by rogerx.oss＠gmail.com

> On Tue, Dec 13, 2011 at 03:51:01PM +0000, Jeremy Henty wrote: > >I wrote: > >> So I think we really want a single keyssrc entry that defines the >> modifier keys that bind the 1, 2, 3, ... 9 keys to the "Go to tab" >> commands. But this would significantly complicate the current code. >> Is it worth it? > >@crickets *chirp* > >I'll take that as a "no". :-) > >I notice that keys.hh defines KEYS_{FIRST,LAST}_TAB but they are not >bound to anything. Maybe we could bind them to Ctrl-{Home,End}? It >seems natural and they could be sensibly customised in keysrc without >complicating the code. What's humorous about all these key binding on Dillo, I rarely ever use key bindings within a GUI application. At most for Dillo, I use the mouse buttons and scroll wheel. Once my hands are off the keyboard and on a mouse, it's difficult and time consuming to switch back & forth to a keyboard. And, I mostly use command line applications, for the main reason using a keyboard is faster. (Second reason, less resource intensive.) Making it even more difficult for GUI users, there just isn't any incentive for using the keyboard while in X or GUI, unless one yanks (detaches) the mouse. Then, most users are like (duh), what do I do now -- because there's no method to see key bindings easily. Funny! Hence, key bindings are likely a good fall back method if you have key bindings memorized. -- Roger http://rogerx.freeshell.org/

Dec. 13, 2011

keysrc and prefix keys

by onepoint＠starurchin.org

I wrote: > So I think we really want a single keyssrc entry that defines the > modifier keys that bind the 1, 2, 3, ... 9 keys to the "Go to tab" > commands. But this would significantly complicate the current code. > Is it worth it? @crickets *chirp* I'll take that as a "no". :-) I notice that keys.hh defines KEYS_{FIRST,LAST}_TAB but they are not bound to anything. Maybe we could bind them to Ctrl-{Home,End}? It seems natural and they could be sensibly customised in keysrc without complicating the code. Regards, Jeremy Henty

Dec. 13, 2011

dillo-3.0.2 released

by onepoint＠starurchin.org

corvid wrote: > > It's official! > > http://www.dillo.org/download/dillo-3.0.2.tar.bz2 > http://www.dillo.org/download/dillo-3.0.2.tar.bz2.asc Beyond Linux From Scratch wiki page duly updated: http://wiki.linuxfromscratch.org/blfs/wiki/dillo3 Regards, Jeremy Henty

Dec. 10, 2011

Change "view page source" to use a DPI.

by mailbox＠georgpotthast.de

When I read the "Current Plans" list I thought that the Medium priority items were worked on after the High Priority items were done and overlooked the green button. Since "View page source" works in the current version of Dillo-Win32 Johannes is right and Benjamin had already rewritten that. Considering all the work Benjamin has put into his version I cannot react with <shrugs> on his decision to discontinue. I just hope he may change his mind again. Georg

Dec. 10, 2011

Change "view page source" to use a DPI.

by rogerx.oss＠gmail.com

> On Fri, Dec 09, 2011 at 09:50:18PM +0100, Johannes Hofmann wrote: >On Fri, Dec 09, 2011 at 09:37:28PM +0100, Georg Potthast wrote: >> I work on the Dillo f?r DOS version and I was shocked to read ;-) >> that you plan to use DPI to view the page source. >> >> This will cause the code for DOS not to work anymore. Can you please >> save yourself the time to change this part of the Dillo code? > >If it works now, it will continue to work :-) >View source is done by a dpi already, but I think Benjamin changes >this in his win32 port. I think (Benjamin?) gave up recently on the win32 port because his MS Windows patches were being denied. (See win32 port website. <shrugs>) -- Roger http://rogerx.freeshell.org/

Dec. 10, 2011

Change "view page source" to use a DPI.

by Johannes.Hofmann＠gmx.de

On Fri, Dec 09, 2011 at 09:37:28PM +0100, Georg Potthast wrote: > I work on the Dillo f?r DOS version and I was shocked to read ;-) > that you plan to use DPI to view the page source. > > This will cause the code for DOS not to work anymore. Can you please > save yourself the time to change this part of the Dillo code? If it works now, it will continue to work :-) View source is done by a dpi already, but I think Benjamin changes this in his win32 port. Cheers, Johannes

Dec. 9, 2011

Change "view page source" to use a DPI.

by mailbox＠georgpotthast.de

I work on the Dillo f?r DOS version and I was shocked to read ;-) that you plan to use DPI to view the page source. This will cause the code for DOS not to work anymore. Can you please save yourself the time to change this part of the Dillo code? Georg

Dec. 9, 2011

cookiesrc -> DEFAULT ACCEPT works, while gmail.com ACCEPT doesn't

by corvid＠lavabit.com

Roger wrote: > FYI: For those interested, I'm now able to log into my GMail account with the > following specified cookies enabled and using the following Mobile GMail url > address. > > I believe some previous posters stated they were hacking around to logging into > their GMail accounts due to cookie issues. > > Oh, and I also added .gmail.com to the list within cookiesrc. <shrugs as to > whether this helped or not, logging say not so.> > > DEFAULT DENY > .gmail.com ACCEPT > .google.com ACCEPT > > http://mail.google.com/mail/x/gp?source=mobileproducts&dc=gorganic It may be worth figuring out what set of google hosts you have to accept cookies from, since .google.com subjects you to quite a bit of tracking.

Dec. 8, 2011

cookiesrc -> DEFAULT ACCEPT works, while gmail.com ACCEPT doesn't

by rogerx.oss＠gmail.com

> On Thu, Dec 08, 2011 at 12:49:42AM -0900, Roger wrote: >FYI: For those interested, I'm now able to log into my GMail account with the >following specified cookies enabled and using the following Mobile GMail url >address. > >I believe some previous posters stated they were hacking around to logging into >their GMail accounts due to cookie issues. > >Oh, and I also added .gmail.com to the list within cookiesrc. <shrugs as to >whether this helped or not, logging say not so.> > > DEFAULT DENY > .gmail.com ACCEPT > .google.com ACCEPT > >http://mail.google.com/mail/x/gp?source=mobileproducts&dc=gorganic Again, forgot to further mention I'm using the Kindle's browser agent. (Unknown if changing the browser agent currently helps, but does seem to help formating web pages better within Dillo.) -- Roger http://rogerx.freeshell.org/

Dec. 8, 2011

cookiesrc -> DEFAULT ACCEPT works, while gmail.com ACCEPT doesn't

by rogerx.oss＠gmail.com

FYI: For those interested, I'm now able to log into my GMail account with the following specified cookies enabled and using the following Mobile GMail url address. I believe some previous posters stated they were hacking around to logging into their GMail accounts due to cookie issues. Oh, and I also added .gmail.com to the list within cookiesrc. <shrugs as to whether this helped or not, logging say not so.> DEFAULT DENY .gmail.com ACCEPT .google.com ACCEPT http://mail.google.com/mail/x/gp?source=mobileproducts&dc=gorganic Enjoy. -- Roger http://rogerx.freeshell.org/

Dec. 8, 2011

cookiesrc -> DEFAULT ACCEPT works, while gmail.com ACCEPT doesn't

by rogerx.oss＠gmail.com

>I don't think I clarified myself well enough, I'm performing: > >$ ps ax |grep dpi >$ kill [PID's of all *dpi* related processes] > >At this point, since no *dpi* processes are remaining when doing ps ax, I >safely assume Dillo's cookie dpi is stopped. OK. I'm now converted to using "dpidc stop" instead of issueing `ps ax |grep dpi && kill [pid's]` I did convert my cookiesrc to use the prefix dot to the domain names. I then renamed the top DEFAULT to DENY. Restarted Dillo and am now finding GMail working, although I *know* I tried the above but using the `kill pid's` method and verifying no *dpi* processes were remaining. Yes, and I double double checked for those *dpi processes!

Dec. 8, 2011

cookiesrc -> DEFAULT ACCEPT works, while gmail.com ACCEPT doesn't

by rogerx.oss＠gmail.com

> On Thu, Dec 08, 2011 at 09:14:43AM +0000, corvid wrote: >Roger wrote: >> > On Thu, Dec 08, 2011 at 05:15:19AM +0000, corvid wrote: >> >Roger wrote: >> >> The following cookiesrc file works for GMail: >> >> >> >> $HOME/.dillo/cookiesrc >> >> DEFAULT ACCEPT >> >> >> >> >> >> But this doesn't work for GMail and Google complains cookies are not enabled. >> >> >> >> $HOME/.dillo/cookiesrc >> >> DEFAULT DENY >> >> google.com ACCEPT >> >> >> >> >> >> Making this even more difficult, I found killing dpid and restart dillo was not >> >> effective, I needed to kill Xorg too to prevent loading pages from what looked >> >> like dillo was loading from cache. >> > >> >Did you use "dpidc stop"? >> >> well, killall dpidc and seeing no dpi* processes should do it, correct? > >No. >dpidc is the control program that can tell dpid and the dpis to stop. >And "killall dpidc" isn't going to stop the cookies dpi. I don't think I clarified myself well enough, I'm performing: $ ps ax |grep dpi $ kill [PID's of all *dpi* related processes] At this point, since no *dpi* processes are remaining when doing ps ax, I safely assume Dillo's cookie dpi is stopped. -- Roger http://rogerx.freeshell.org/

Dec. 8, 2011

cookiesrc -> DEFAULT ACCEPT works, while gmail.com ACCEPT doesn't

by corvid＠lavabit.com

Roger wrote: > > On Thu, Dec 08, 2011 at 05:15:19AM +0000, corvid wrote: > >Roger wrote: > >> The following cookiesrc file works for GMail: > >> > >> $HOME/.dillo/cookiesrc > >> DEFAULT ACCEPT > >> > >> > >> But this doesn't work for GMail and Google complains cookies are not enabled. > >> > >> $HOME/.dillo/cookiesrc > >> DEFAULT DENY > >> google.com ACCEPT > >> > >> > >> Making this even more difficult, I found killing dpid and restart dillo was not > >> effective, I needed to kill Xorg too to prevent loading pages from what looked > >> like dillo was loading from cache. > > > >Did you use "dpidc stop"? > > well, killall dpidc and seeing no dpi* processes should do it, correct? No. dpidc is the control program that can tell dpid and the dpis to stop. And "killall dpidc" isn't going to stop the cookies dpi. > >> But after much troubleshooting for the past hour, I've determined the above > >> scenario consistent. As soon as "DEFAULT DENY, google.com ACCEPT" is entered, > >> Google complains cookies are not enabled every time. > > > >How about ".google.com ACCEPT"? Or, better yet, whatever the > >exact hostname is. > > This is weird as I look at dillo's X output. > > I have: > > DEFAULT ACCEPT > google.com ACCEPT > > And I'm seeing behavior (output) similar to "DEFAULT DENY, google.com ACCEPT". > And what I see further, stuff like wikipedia.com cookie denied, and then I see > google.com's cookies accepted. > > Seems as if DEFAULT ACCEPT with nothing following will accept any cookie from > any domain. DEFAULT ACCEPT with additional domain filters will act like > "DEFAULT DENY, some_domain.com ACCEPT". > > Have I explain this well enough? I don't see that behaviour. It could be that you're seeing messages where dillo discards third-party cookies (if a page requests an ad image from a different site and the ad image comes with a cookie, we don't want the cookie). Or maybe everything will clear up after a good dpidc stop. Anyway, like I was wondering before: How about ".google.com ACCEPT"? Or, better yet, whatever the exact hostname is.

Dec. 8, 2011

cookiesrc -> DEFAULT ACCEPT works, while gmail.com ACCEPT doesn't

by rogerx.oss＠gmail.com

> On Thu, Dec 08, 2011 at 05:15:19AM +0000, corvid wrote: >Roger wrote: >> The following cookiesrc file works for GMail: >> >> $HOME/.dillo/cookiesrc >> DEFAULT ACCEPT >> >> >> But this doesn't work for GMail and Google complains cookies are not enabled. >> >> $HOME/.dillo/cookiesrc >> DEFAULT DENY >> google.com ACCEPT >> >> >> Making this even more difficult, I found killing dpid and restart dillo was not >> effective, I needed to kill Xorg too to prevent loading pages from what looked >> like dillo was loading from cache. > >Did you use "dpidc stop"? well, killall dpidc and seeing no dpi* processes should do it, correct? >> But after much troubleshooting for the past hour, I've determined the above >> scenario consistent. As soon as "DEFAULT DENY, google.com ACCEPT" is entered, >> Google complains cookies are not enabled every time. > >How about ".google.com ACCEPT"? Or, better yet, whatever the >exact hostname is. This is weird as I look at dillo's X output. I have: DEFAULT ACCEPT google.com ACCEPT And I'm seeing behavior (output) similar to "DEFAULT DENY, google.com ACCEPT". And what I see further, stuff like wikipedia.com cookie denied, and then I see google.com's cookies accepted. Seems as if DEFAULT ACCEPT with nothing following will accept any cookie from any domain. DEFAULT ACCEPT with additional domain filters will act like "DEFAULT DENY, some_domain.com ACCEPT". Have I explain this well enough? -- Roger http://rogerx.freeshell.org/

Dec. 8, 2011

cookiesrc -> DEFAULT ACCEPT works, while gmail.com ACCEPT doesn't

by corvid＠lavabit.com

Roger wrote: > The following cookiesrc file works for GMail: > > $HOME/.dillo/cookiesrc > DEFAULT ACCEPT > > > But this doesn't work for GMail and Google complains cookies are not enabled. > > $HOME/.dillo/cookiesrc > DEFAULT DENY > google.com ACCEPT > > > Making this even more difficult, I found killing dpid and restart dillo was not > effective, I needed to kill Xorg too to prevent loading pages from what looked > like dillo was loading from cache. Did you use "dpidc stop"? > But after much troubleshooting for the past hour, I've determined the above > scenario consistent. As soon as "DEFAULT DENY, google.com ACCEPT" is entered, > Google complains cookies are not enabled every time. How about ".google.com ACCEPT"? Or, better yet, whatever the exact hostname is.

Dec. 8, 2011

cookiesrc -> DEFAULT ACCEPT works, while gmail.com ACCEPT doesn't

by rogerx.oss＠gmail.com

Forgot to mention I'm logging into Mobile Google GMail http://mail.google.com/mail/x/gp?source=mobileproducts&dc=gorganic -- Roger http://rogerx.freeshell.org/

Dec. 8, 2011

cookiesrc -> DEFAULT ACCEPT works, while gmail.com ACCEPT doesn't

by rogerx.oss＠gmail.com

The following cookiesrc file works for GMail: $HOME/.dillo/cookiesrc DEFAULT ACCEPT But this doesn't work for GMail and Google complains cookies are not enabled. $HOME/.dillo/cookiesrc DEFAULT DENY google.com ACCEPT Making this even more difficult, I found killing dpid and restart dillo was not effective, I needed to kill Xorg too to prevent loading pages from what looked like dillo was loading from cache. But after much troubleshooting for the past hour, I've determined the above scenario consistent. As soon as "DEFAULT DENY, google.com ACCEPT" is entered, Google complains cookies are not enabled every time. -- Roger http://rogerx.freeshell.org/

Dec. 8, 2011

Dillo fails on http://www.google.com/m/. Browser Agent?

by rogerx.oss＠gmail.com

> On Wed, Dec 07, 2011 at 08:44:52PM +0100, Johannes Hofmann wrote: >On Wed, Dec 07, 2011 at 12:53:10PM +0000, corvid wrote: >> Roger wrote: >> > I find Dillo failing on the following simple site, which Elinks and other >> > mobile browsers view just fine: >> > >> > http://www.google.com/m/ >> >> Looks like the same situation as >> http://lists.auriga.wearlab.de/pipermail/dillo-dev/2011-August/008765.html > >Just to make things clear - adding a line like > > http_user_agent="Mozilla" > >to your ~/.dillo/dillorc should fix it. works like a charm! I should update my $HOME/.dillo/dillor with /etc/dillo/dillorc sometime, as the $HOME one didn't have this setting. -- Roger http://rogerx.freeshell.org/

Dec. 8, 2011

Knoppix 3.0.2 - no go

by jcid＠dillo.org

Hi, On Wed, Dec 07, 2011 at 02:54:03PM -0500, jmh5 at nhfn.net wrote: > > Hi Again, > > It appears I spoke too soon. 3.0.2 now works ? > Maybe dpid or some other program was reloaded? > > Also, the older version now works differently !! > > Now I am really interested in how do I make a fully static > version? So I don't have program operation changing unexpectedly? Please subscribe to dillo-dev mailing list if you're interested in following the thread. This email and the previous one were forwarded there. HTH, -- Cheers Jorge.-

Dec. 7, 2011

Dillo fails on http://www.google.com/m/. Browser Agent?

by Johannes.Hofmann＠gmx.de

On Wed, Dec 07, 2011 at 12:53:10PM +0000, corvid wrote: > Roger wrote: > > I find Dillo failing on the following simple site, which Elinks and other > > mobile browsers view just fine: > > > > http://www.google.com/m/ > > Looks like the same situation as > http://lists.auriga.wearlab.de/pipermail/dillo-dev/2011-August/008765.html Just to make things clear - adding a line like http_user_agent="Mozilla" to your ~/.dillo/dillorc should fix it. Cheers, Johannes

Dec. 7, 2011

[jmh5@nhfn.net: Knoppix 3.0.2 - no go]

by jcid＠dillo.org

FYI, -- Cheers Jorge.-

Dec. 7, 2011

Dillo fails on http://www.google.com/m/. Browser Agent?

by corvid＠lavabit.com

Roger wrote: > I find Dillo failing on the following simple site, which Elinks and other > mobile browsers view just fine: > > http://www.google.com/m/ Looks like the same situation as http://lists.auriga.wearlab.de/pipermail/dillo-dev/2011-August/008765.html

Dec. 7, 2011

No subject

by bogus＠does.not.exist.com

cache, or as if there were a stale persistent dpi process still present. At this point, I'll gander it was something with the dpi processes not cleanly exiting due to the kill signal. (I doubt a *dpi* process was hidden from proc.) -- Roger http://rogerx.freeshell.org/

Dec. 7, 2011

Dillo fails on http://www.google.com/m/. Browser Agent?

by rogerx.oss＠gmail.com

I find Dillo failing on the following simple site, which Elinks and other mobile browsers view just fine: http://www.google.com/m/ -- Roger http://rogerx.freeshell.org/

Dec. 7, 2011

tooltip bug

by corvid＠lavabit.com

I just noticed some odd behaviour with <img src=img title="img title" border=1 width=50 height=50><br> <a href=link title="link title">text</a> If I put the cursor over the link and then, when I expect the tooltip to pop up, move quickly up into the image, first the link's tooltip pops up for an instant -- but says "img title" -- and then the image's tooltip pops up -- but says "link title".

Dec. 6, 2011

dillo-3.0.2 released

by corvid＠lavabit.com

It's official! http://www.dillo.org/download/dillo-3.0.2.tar.bz2 http://www.dillo.org/download/dillo-3.0.2.tar.bz2.asc And, for good measure, the sha1sum is still... 1d1258ee7d18c8ca0eabaf100f2f611c6be03f87 as it was for the rc. Thanks everyone!

Dec. 5, 2011

IPv6 and HTTPS (Re: release candidate for dillo-3.0.2)

by Johannes.Hofmann＠gmx.de

On Sun, Dec 04, 2011 at 11:05:15AM -0500, Benjamin Johnson wrote: > Johannes wrote: > > >I doubt it's worth making the current experimental HTTPS plugin > >IPv6 ready. > >We will need a more robust HTTPS solution at some point. > > Cheers, > >Johannes > > Why not just reuse the existing HTTP code? > > *cough* > > http://dillo-win32.sourceforge.net/patches/07-dfcntl.diff > http://dillo-win32.sourceforge.net/patches/08-dsock.diff > http://dillo-win32.sourceforge.net/patches/17-https.diff > > Just add some warning dialogs and you've got everything the plugin > offers, plus greater efficiency, code reuse, IPv6, etc. > > (Not to mention, it's thoroughly tested and quite stable on Linux, > BSD, that other OS with 99% market share, etc. I use it myself > every day.) > > Anyway, all my code's still there if you're interested. Thanks for the offer. Currently the patches don't seem to apply cleanly and they also mix in WIN32 compatibility code. So integration work is needed and also an in depth review of the certificate handling. Cheers, Johannes

Dec. 4, 2011

IPv6 and HTTPS (Re: release candidate for dillo-3.0.2)

by obeythepenguin＠gmail.com

Johannes wrote: > I doubt it's worth making the current experimental HTTPS plugin > IPv6 ready. > We will need a more robust HTTPS solution at some point. > Cheers, > Johannes Why not just reuse the existing HTTP code? *cough* http://dillo-win32.sourceforge.net/patches/07-dfcntl.diff http://dillo-win32.sourceforge.net/patches/08-dsock.diff http://dillo-win32.sourceforge.net/patches/17-https.diff Just add some warning dialogs and you've got everything the plugin offers, plus greater efficiency, code reuse, IPv6, etc. (Not to mention, it's thoroughly tested and quite stable on Linux, BSD, that other OS with 99% market share, etc. I use it myself every day.) Anyway, all my code's still there if you're interested. Cheers, ~Benjamin

Dec. 4, 2011

IPv6 and HTTPS (Re: release candidate for dillo-3.0.2)

by jcid＠dillo.org

On Sat, Dec 03, 2011 at 10:41:50PM +0100, Johannes Hofmann wrote: > On Sat, Dec 03, 2011 at 09:23:41PM +0000, corvid wrote: > > Axel wrote: > > > IPv6 and HTTPS seem both to work independently, but HTTPS over IPv6 > > > does not work. An example host would be the IPv6-only reachable server > > > at https://jumper.deuxchevaux.org/. (Submitted to the bug database as > > > bug #1023.) > > > > > > The same host with just HTTP (http://jumper.deuxchevaux.org/) works > > > fine as well as does a randomly chosen (IPv4 :-) HTTPS website. > > > > > > OTOH with 3.0.1 it looks very similar and doesn't work either with > > > IPv6 + HTTPS, so I think it's "just" a bug in Dillo, but not a > > > regression in 3.0.2. :-) > > > > Is anyone in a sufficiently IPv6-ed environment that they can dig into > > this at some point? > > I doubt it's worth making the current experimental HTTPS plugin > IPv6 ready. > We will need a more robust HTTPS solution at some point. Ditto. -- Cheers Jorge.-

Dec. 4, 2011

IPv6 and HTTPS (Re: release candidate for dillo-3.0.2)

by Johannes.Hofmann＠gmx.de

On Sat, Dec 03, 2011 at 09:23:41PM +0000, corvid wrote: > Axel wrote: > > IPv6 and HTTPS seem both to work independently, but HTTPS over IPv6 > > does not work. An example host would be the IPv6-only reachable server > > at https://jumper.deuxchevaux.org/. (Submitted to the bug database as > > bug #1023.) > > > > The same host with just HTTP (http://jumper.deuxchevaux.org/) works > > fine as well as does a randomly chosen (IPv4 :-) HTTPS website. > > > > OTOH with 3.0.1 it looks very similar and doesn't work either with > > IPv6 + HTTPS, so I think it's "just" a bug in Dillo, but not a > > regression in 3.0.2. :-) > > Is anyone in a sufficiently IPv6-ed environment that they can dig into > this at some point? I doubt it's worth making the current experimental HTTPS plugin IPv6 ready. We will need a more robust HTTPS solution at some point. Cheers, Johannes

Dec. 3, 2011

IPv6 and HTTPS (Re: release candidate for dillo-3.0.2)

by corvid＠lavabit.com

Axel wrote: > IPv6 and HTTPS seem both to work independently, but HTTPS over IPv6 > does not work. An example host would be the IPv6-only reachable server > at https://jumper.deuxchevaux.org/. (Submitted to the bug database as > bug #1023.) > > The same host with just HTTP (http://jumper.deuxchevaux.org/) works > fine as well as does a randomly chosen (IPv4 :-) HTTPS website. > > OTOH with 3.0.1 it looks very similar and doesn't work either with > IPv6 + HTTPS, so I think it's "just" a bug in Dillo, but not a > regression in 3.0.2. :-) Is anyone in a sufficiently IPv6-ed environment that they can dig into this at some point? > Otherwise 3.0.2 RC1 looks fine for me. :-) Thanks :)

Dec. 3, 2011

Dillo temporary directory

by obeythepenguin＠gmail.com

Jorge wrote: > On Sat, Dec 03, 2011 at 09:11:48AM +0100, Georg Potthast wrote: > > I observe that Dillo changes the current directory to "\tmp" when > > running. Why does it do that and what files shall be written into > > this directory? > No files, Dillo tries to work from an unmounted directory. > -- Cheers > Jorge.- But *why* does Dillo work from an unmounted directory? What advantage does this provide, especially if Dillo does not write any files there? (As a side note, /tmp _is_ mounted on many systems, like OpenBSD.) Cheers, ~Benjamin

Dec. 3, 2011

release candidate for dillo-3.0.2

by jcid＠dillo.org

On Fri, Dec 02, 2011 at 09:46:22PM +0000, corvid wrote: > Jorge wrote: > > AFAIR, libpng detection was an issue (not only for us), and it > > took a long time to come with something that worked across all > > the different platforms we were testing. > > What we can glean from good old CVS is: > > > In December 2004, the test changed from > which libpng12-config || which libpng-config || which libpng10-config > to a bunch of separate whiches because > "Fixed a libpng detection problem (e.g., on CYGWIN). BUG#651". > Of course, BUG#651 is long gone, but presumably the problem was the "||". > > > In January 2004, we go from > PNG_CONFIG="`which libpng-config || which libpng12-config`" > to > PNG_CONFIG=`which libpng12-config || which libpng-config || which libpng10-config` > (along with general restructuring) > Then if we follow that to the archive, > http://lists.auriga.wearlab.de/pipermail/dillo-dev/2004-January/001683.html > the libpng talk is of Slackware 3.9, which came out in May, 1999. > A quoted msg from Jorgen doesn't appear to be in the archive. > > Looking at http://slackware.cs.utah.edu/pub/slackware/slackware-3.9/slakware/MANIFEST.… > Slackware 3.9 used libpng-1.0.3, and did not have a png-config of any > sort that I can see. > > Looking at the CHANGES file with my copy of libpng shows that png-config > showed up during the 1.2.x series. > > Earlier in January, > http://lists.auriga.wearlab.de/pipermail/dillo-dev/2004-January/001615.html > says that libpng 1.2.5 needed to be added to the Slackware 3.9 system to > make dillo happy. > > Overall, the messages give every appearance of saying that dillo should > start with trying the libpng-config system but then still work on > systems that predate libpng-config. > > Looking at the change made, yeah, I guess that pre-libpng-config system > mustn't have had libpng stuff in the right places to get by with CPPFLAGS > as they were, hence added code that, if there was no libpng-config at all > and there was png.h, then add in 'LIBPNG_LIBS="-lpng -lm"' ourselves. > > libpng configuration checking was introduced in March 2003. > This leads back to > http://lists.auriga.wearlab.de/pipermail/dillo-dev/2003-March/000390.html > where nothing brought up seems to have bearing on the matter at hand here. > > > Nothing reveals itself in the extant archaeological record suggesting > that the various libpng-configs themselves were an issue. Sorry if my meaning/wording wasn't clear. I meant, "it took some effort to sort the detection code so it finally was able to compile automatically accross all the different platforms we were testing" (some had libpng-config, some not, some had both installed at the same time IIRC). -- Cheers Jorge.-

Dec. 3, 2011

Dillo-dev Digest, Vol 76, Issue 1

by jcid＠dillo.org

On Sat, Dec 03, 2011 at 09:11:48AM +0100, Georg Potthast wrote: > I observe that Dillo changes the current directory to "\tmp" when > running. Why does it do that and what files shall be written into > this directory? No files, Dillo tries to work from an unmounted directory. -- Cheers Jorge.-

Dec. 3, 2011

release candidate for dillo-3.0.2

by jcid＠dillo.org

On Thu, Dec 01, 2011 at 03:18:53AM +0000, corvid wrote: > > I just put up an rc at > http://www.dillo.org/download/dillo-3.0.2-rc1.tar.bz2 > > $ sha1sum dillo-3.0.2-rc1.tar.bz2 > 1d1258ee7d18c8ca0eabaf100f2f611c6be03f87 dillo-3.0.2-rc1.tar.bz2 > > Please test :) I've being using it for a few days and it compiles and works very well on amd64 (x86_64 GNU/Linux). -- Cheers Jorge.-

Dec. 3, 2011

Dillo-dev Digest, Vol 76, Issue 1

by mailbox＠georgpotthast.de

I observe that Dillo changes the current directory to "\tmp" when running. Why does it do that and what files shall be written into this directory? Georg

Dec. 3, 2011

release candidate for dillo-3.0.2

by furaisanjin＠gmail.com

Hi, I tried on FreeBSD 8.2. Compiling is OK and dillo works well. Regards, furaisanjin 2011/12/1 corvid <corvid at lavabit.com>: > > I just put up an rc at > http://www.dillo.org/download/dillo-3.0.2-rc1.tar.bz2 > > $ sha1sum dillo-3.0.2-rc1.tar.bz2 > 1d1258ee7d18c8ca0eabaf100f2f611c6be03f87 ?dillo-3.0.2-rc1.tar.bz2 > > Please test :) > > If all goes well, the idea is to release on Monday... > > > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev at dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev

Dec. 3, 2011

release candidate for dillo-3.0.2

by corvid＠lavabit.com

Jorge wrote: > AFAIR, libpng detection was an issue (not only for us), and it > took a long time to come with something that worked across all > the different platforms we were testing. What we can glean from good old CVS is: In December 2004, the test changed from which libpng12-config || which libpng-config || which libpng10-config to a bunch of separate whiches because "Fixed a libpng detection problem (e.g., on CYGWIN). BUG#651". Of course, BUG#651 is long gone, but presumably the problem was the "||". In January 2004, we go from PNG_CONFIG="`which libpng-config || which libpng12-config`" to PNG_CONFIG=`which libpng12-config || which libpng-config || which libpng10-config` (along with general restructuring) Then if we follow that to the archive, http://lists.auriga.wearlab.de/pipermail/dillo-dev/2004-January/001683.html the libpng talk is of Slackware 3.9, which came out in May, 1999. A quoted msg from Jorgen doesn't appear to be in the archive. Looking at http://slackware.cs.utah.edu/pub/slackware/slackware-3.9/slakware/MANIFEST.… Slackware 3.9 used libpng-1.0.3, and did not have a png-config of any sort that I can see. Looking at the CHANGES file with my copy of libpng shows that png-config showed up during the 1.2.x series. Earlier in January, http://lists.auriga.wearlab.de/pipermail/dillo-dev/2004-January/001615.html says that libpng 1.2.5 needed to be added to the Slackware 3.9 system to make dillo happy. Overall, the messages give every appearance of saying that dillo should start with trying the libpng-config system but then still work on systems that predate libpng-config. Looking at the change made, yeah, I guess that pre-libpng-config system mustn't have had libpng stuff in the right places to get by with CPPFLAGS as they were, hence added code that, if there was no libpng-config at all and there was png.h, then add in 'LIBPNG_LIBS="-lpng -lm"' ourselves. libpng configuration checking was introduced in March 2003. This leads back to http://lists.auriga.wearlab.de/pipermail/dillo-dev/2003-March/000390.html where nothing brought up seems to have bearing on the matter at hand here. Nothing reveals itself in the extant archaeological record suggesting that the various libpng-configs themselves were an issue. > I also recommend not doing this before the release. Yes, agrees.

Dec. 2, 2011

release candidate for dillo-3.0.2

by singpolyma＠singpolyma.net

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Somebody claiming to be Johannes Hofmann wrote: >On Fri, Dec 02, 2011 at 01:01:37PM +0000, corvid wrote: >> I'm not aware of a reason why we can't rip out all of this libpng >> version stuff and make life better, but admittedly I'm not a libpng >> specialist. > >I would suggest we try to get rid of the version check after the >release. Are you just using a pkg-config check, or something uglier? - -- Stephen Paul Weber, @singpolyma See <http://singpolyma.net> for how I prefer to be contacted edition right joseph -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAEBCAAGBQJO2SGhAAoJENEcKRHOUZzewZIP/2LTEN3gs2sLUtzQtrG8mmrR 8iH2uDi/es6FEhgat760jxE89a8mch75oJwcggJTW71ROIQr/MWPyO5TaWHuc+WS snNq5kEyZj6kqkSdP07P/XsgBgLH+Vq6HIH0JNnwGxVuliWPyFcD390wQmTAC15b pzIGXlRL0hgNOZ8fFo8z4r13OCsgOjBPIBnwGCVsXK4ogVRyjkG8JA4s4dbI9wnN SuLfTEkHD/K5xtROIipJpZQ2i+pPZEebZH41Sj3UlXmaksxdG/X6Y2oxW1w9c5qE Qu6B7GFrelA2cDmx/maZNSQOX5RVGrNuIlbVJRbwTy7IMwk3yaykiBQBkhARqRxx ZOL//ofTl2niQnhIMgCQKhKIlhVA4vZpjhgejFv0WGz5Ya8tsxB3DtvU7eDbSiVx dQvaZYPLfYDW27rXT7rsr6zjgyJw+9JnG/GPzjJXGS45oeGlBBPL9gkK93QXrCoU a0IHi4yZbSI86EGMOGZM7FxJO6/ucsJ5i/WNk/GA8fheWO5AfhhDWwiBFlzKUFTS u3QOsj2ukc9HAuMNnDjPI5Zs5W/BortSUPyqaPKktl6BKGLNpfrptkH0lEeHYaTZ rRN8PMVHVKpidGeeilD2y2I3nRu7UMxxvqMRO/0NdbXEfwjtb9R0PjHFJTO9gRc2 qjiZM+9hLrKpiJawU0+A =6u/F -----END PGP SIGNATURE-----

Dec. 2, 2011

release candidate for dillo-3.0.2

by jcid＠dillo.org

On Fri, Dec 02, 2011 at 01:01:37PM +0000, corvid wrote: > Walter wrote: > > checking for zlib.h... yes > > checking for zlibVersion in -lz... yes > > checking for libpng-config... which: no libpng14-config in > > (/root/bin:/root/bin: > > /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/opt/bin:/usr/i686- > > pc-linux-gnu/gcc-bin/4.5.3) > > which: no libpng12-config in > > (/root/bin:/root/bin:/usr/local/sbin:/usr/local/bin > > :/usr/sbin:/usr/bin:/sbin:/bin:/opt/bin:/usr/i686-pc-linux-gnu/gcc-bin/4.5.3) > > /usr/bin/libpng-config > > checking for libpng version... ERROR > > checking openssl/ssl.h usability... yes > > checking openssl/ssl.h presence... yes > > checking for openssl/ssl.h... yes > > > > As near as I can tell, it's looking for either libpng12 or libpng14, > > but I have libpng15. Dillo builds and png support works, i.e. I can > > view png images. Maybe I'm picky, but I wonder about the message. Is > > it significant? > > So far as I know, it should be okay with 1.5. > > The last time I brought up 1.5 was in > http://lists.auriga.wearlab.de/pipermail/dillo-dev/2011-May/008286.html > and no one replied. > > I'm not aware of a reason why we can't rip out all of this libpng > version stuff and make life better, but admittedly I'm not a libpng > specialist. AFAIR, libpng detection was an issue (not only for us), and it took a long time to come with something that worked across all the different platforms we were testing. If somebody is willing to change the detection code and go through the whole testing process of different libpng versions/scripts in old and new distros, so be it. I also recommend not doing this before the release. -- Cheers Jorge.-

Dec. 2, 2011

release candidate for dillo-3.0.2

by Johannes.Hofmann＠gmx.de

On Fri, Dec 02, 2011 at 01:01:37PM +0000, corvid wrote: > Walter wrote: > > checking for zlib.h... yes > > checking for zlibVersion in -lz... yes > > checking for libpng-config... which: no libpng14-config in > > (/root/bin:/root/bin: > > /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/opt/bin:/usr/i686- > > pc-linux-gnu/gcc-bin/4.5.3) > > which: no libpng12-config in > > (/root/bin:/root/bin:/usr/local/sbin:/usr/local/bin > > :/usr/sbin:/usr/bin:/sbin:/bin:/opt/bin:/usr/i686-pc-linux-gnu/gcc-bin/4.5.3) > > /usr/bin/libpng-config > > checking for libpng version... ERROR > > checking openssl/ssl.h usability... yes > > checking openssl/ssl.h presence... yes > > checking for openssl/ssl.h... yes > > > > As near as I can tell, it's looking for either libpng12 or libpng14, > > but I have libpng15. Dillo builds and png support works, i.e. I can > > view png images. Maybe I'm picky, but I wonder about the message. Is > > it significant? > > So far as I know, it should be okay with 1.5. > > The last time I brought up 1.5 was in > http://lists.auriga.wearlab.de/pipermail/dillo-dev/2011-May/008286.html > and no one replied. > > I'm not aware of a reason why we can't rip out all of this libpng > version stuff and make life better, but admittedly I'm not a libpng > specialist. I would suggest we try to get rid of the version check after the release. Cheers, Johannes

Dec. 2, 2011

release candidate for dillo-3.0.2

by Johannes.Hofmann＠gmx.de

On Thu, Dec 01, 2011 at 03:18:53AM +0000, corvid wrote: > > I just put up an rc at > http://www.dillo.org/download/dillo-3.0.2-rc1.tar.bz2 > > $ sha1sum dillo-3.0.2-rc1.tar.bz2 > 1d1258ee7d18c8ca0eabaf100f2f611c6be03f87 dillo-3.0.2-rc1.tar.bz2 > > Please test :) Compiles and runs fine on DragonFly 2.13-DEVELOPMENT Cheers, Johannes

Dec. 2, 2011

release candidate for dillo-3.0.2

by abe＠deuxchevaux.org

Hi, On Thu, Dec 01, 2011 at 03:18:53AM +0000, corvid wrote: > I just put up an rc at > http://www.dillo.org/download/dillo-3.0.2-rc1.tar.bz2 > > $ sha1sum dillo-3.0.2-rc1.tar.bz2 > 1d1258ee7d18c8ca0eabaf100f2f611c6be03f87 dillo-3.0.2-rc1.tar.bz2 > > Please test :) Compiles fine as Debian package. IPv6 and HTTPS seem both to work independently, but HTTPS over IPv6 does not work. An example host would be the IPv6-only reachable server at https://jumper.deuxchevaux.org/. (Submitted to the bug database as bug #1023.) The same host with just HTTP (http://jumper.deuxchevaux.org/) works fine as well as does a randomly chosen (IPv4 :-) HTTPS website. OTOH with 3.0.1 it looks very similar and doesn't work either with IPv6 + HTTPS, so I think it's "just" a bug in Dillo, but not a regression in 3.0.2. :-) Otherwise 3.0.2 RC1 looks fine for me. :-) 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)

Dec. 2, 2011

release candidate for dillo-3.0.2

by corvid＠lavabit.com

Walter wrote: > checking for zlib.h... yes > checking for zlibVersion in -lz... yes > checking for libpng-config... which: no libpng14-config in > (/root/bin:/root/bin: > /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/opt/bin:/usr/i686- > pc-linux-gnu/gcc-bin/4.5.3) > which: no libpng12-config in > (/root/bin:/root/bin:/usr/local/sbin:/usr/local/bin > :/usr/sbin:/usr/bin:/sbin:/bin:/opt/bin:/usr/i686-pc-linux-gnu/gcc-bin/4.5.3) > /usr/bin/libpng-config > checking for libpng version... ERROR > checking openssl/ssl.h usability... yes > checking openssl/ssl.h presence... yes > checking for openssl/ssl.h... yes > > As near as I can tell, it's looking for either libpng12 or libpng14, > but I have libpng15. Dillo builds and png support works, i.e. I can > view png images. Maybe I'm picky, but I wonder about the message. Is > it significant? So far as I know, it should be okay with 1.5. The last time I brought up 1.5 was in http://lists.auriga.wearlab.de/pipermail/dillo-dev/2011-May/008286.html and no one replied. I'm not aware of a reason why we can't rip out all of this libpng version stuff and make life better, but admittedly I'm not a libpng specialist.

Dec. 2, 2011

release candidate for dillo-3.0.2

by waltdnes＠waltdnes.org

On Thu, Dec 01, 2011 at 03:18:53AM +0000, corvid wrote > I just put up an rc at > http://www.dillo.org/download/dillo-3.0.2-rc1.tar.bz2 > > $ sha1sum dillo-3.0.2-rc1.tar.bz2 > 1d1258ee7d18c8ca0eabaf100f2f611c6be03f87 dillo-3.0.2-rc1.tar.bz2 > > Please test :) > > If all goes well, the idea is to release on Monday... Building manually in 32-bit Gentoo. I'm building with a script like so... #!/bin/bash export CFLAGS="-O2 -march=native -mfpmath=sse -fomit-frame-pointer -pipe" ./configure --enable-ssl > log.txt 2>&1 make make install The CFLAGS line is copied straight from my /etc/make.conf. I notice something during the ./configure stage. Here's an excerpt from the ./configure output... checking for zlib.h... yes checking for zlibVersion in -lz... yes checking for libpng-config... which: no libpng14-config in (/root/bin:/root/bin: /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/opt/bin:/usr/i686- pc-linux-gnu/gcc-bin/4.5.3) which: no libpng12-config in (/root/bin:/root/bin:/usr/local/sbin:/usr/local/bin :/usr/sbin:/usr/bin:/sbin:/bin:/opt/bin:/usr/i686-pc-linux-gnu/gcc-bin/4.5.3) /usr/bin/libpng-config checking for libpng version... ERROR checking openssl/ssl.h usability... yes checking openssl/ssl.h presence... yes checking for openssl/ssl.h... yes As near as I can tell, it's looking for either libpng12 or libpng14, but I have libpng15. Dillo builds and png support works, i.e. I can view png images. Maybe I'm picky, but I wonder about the message. Is it significant? -- Walter Dnes <waltdnes at waltdnes.org>

Dec. 2, 2011

release candidate for dillo-3.0.2

by onepoint＠starurchin.org

corvid wrote: > > I just put up an rc at > http://www.dillo.org/download/dillo-3.0.2-rc1.tar.bz2 > > $ sha1sum dillo-3.0.2-rc1.tar.bz2 > 1d1258ee7d18c8ca0eabaf100f2f611c6be03f87 dillo-3.0.2-rc1.tar.bz2 Works well here (Linux-3.1.0). Regards, Jeremy Henty

Dec. 2, 2011

release candidate for dillo-3.0.2

by rogerx.oss＠gmail.com

> On Thu, Dec 01, 2011 at 03:18:53AM +0000, corvid wrote: > >I just put up an rc at >http://www.dillo.org/download/dillo-3.0.2-rc1.tar.bz2 > >$ sha1sum dillo-3.0.2-rc1.tar.bz2 >1d1258ee7d18c8ca0eabaf100f2f611c6be03f87 dillo-3.0.2-rc1.tar.bz2 > >Please test :) > >If all goes well, the idea is to release on Monday... Compiles and executes fine here on P3 x86. No problems yet veiwing pages. -- Roger http://rogerx.freeshell.org/

Dec. 1, 2011