- Dillo-dev - lists.mailman3.com

Browser tracking

by eocene＠gmx.com

Jorge wrote: > This site is interesting. It gives kind of a score of web browser > trackability. [1] > > @corvid, I thought you'd like to give it a look (AFAIR, you have submitted > some standardizing to our HTTP querying in the past). It looks like > our HTTP_ACCEPT and "User Agent" are the most vulnerable to tracking. > > It looks simple to provide some less unique alternatives in dillorc. Yes, this site was part of the impetus to work on the headers in March to make dillo resemble firefox more closely, and add deflate decompression and add keepalive. User-agent is a little misleading in that I have a current firefox user-agent string, and panopticlick says that's one in 2701.57 browsers, but no doubt it's rather more common among the visitors in September 2014 specifically. Somewhat related, I've been working on SSL in the browser, and https://www.ssllabs.com/ssltest/viewMyClient.html shows some more ways for browsers to reveal what they are. > DISCLAIMER: this is just on little aspect of the privacy chain. > Most probably this is moot unless you're behind a TOR ring. YMMV. Indeed. > > [1] https://panopticlick.eff.org/

Sept. 9, 2014

Browser tracking

by jcid＠dillo.org

On Mon, Sep 08, 2014 at 09:42:06PM +0200, Sebastian Geerken wrote: > On Mo, Sep 08, 2014, Jorge Arellano Cid wrote: > [...] > > DISCLAIMER: this is just on little aspect of the privacy chain. > > Most probably this is moot unless you're behind a TOR ring. YMMV. > > For what I've understood, TOR wouldn't help. I mean: usually an IP and a time window is all you need. Unless the site is being accessed in parallel from the same IP, there's almost no way to avoid session tracking. That's were TOR helps (AFAIU). -- Cheers Jorge.-

Sept. 9, 2014

Browser tracking

by andreas＠kemnade.info

Hi, On Mon, 8 Sep 2014 16:15:53 -0300 Jorge Arellano Cid <jcid at dillo.org> wrote: > Hi, > > This site is interesting. It gives kind of a score of web browser > trackability. [1] > > @corvid, I thought you'd like to give it a look (AFAIR, you have submitted > some standardizing to our HTTP querying in the past). It looks like > our HTTP_ACCEPT and "User Agent" are the most vulnerable to tracking. > > It looks simple to provide some less unique alternatives in dillorc. > The User Agent string of dillo does not have that many version numbers like the ones of other browsers. I compared the table with iceweasel and chromium. dillo was the least unique browser of them. But there is of course much more to improve. Greetings Andreas Kemnade

Sept. 8, 2014

Browser tracking

by sgeerken＠dillo.org

On Mo, Sep 08, 2014, Jorge Arellano Cid wrote: > Hi, > > This site is interesting. It gives kind of a score of web browser > trackability. [1] > > @corvid, I thought you'd like to give it a look (AFAIR, you have submitted > some standardizing to our HTTP querying in the past). It looks like > our HTTP_ACCEPT and "User Agent" are the most vulnerable to tracking. > > It looks simple to provide some less unique alternatives in dillorc. > > [1] https://panopticlick.eff.org/ I once started to read the paper (stopped where the math gets too complcated ;-) ); I remember that it is relatively simple to track a browser even if the browser fingerprint, which consists of numerous attributes, changes slightly when only few attributes (e. g. browser version) change. This gave me a vague idea to randomize these attributes exactly in a way to break re-detection. Dillo could perhaps be a good testbed for this. > DISCLAIMER: this is just on little aspect of the privacy chain. > Most probably this is moot unless you're behind a TOR ring. YMMV. For what I've understood, TOR wouldn't help. Sebastian

Sept. 8, 2014

Browser tracking

by jcid＠dillo.org

Hi, This site is interesting. It gives kind of a score of web browser trackability. [1] @corvid, I thought you'd like to give it a look (AFAIR, you have submitted some standardizing to our HTTP querying in the past). It looks like our HTTP_ACCEPT and "User Agent" are the most vulnerable to tracking. It looks simple to provide some less unique alternatives in dillorc. DISCLAIMER: this is just on little aspect of the privacy chain. Most probably this is moot unless you're behind a TOR ring. YMMV. [1] https://panopticlick.eff.org/ -- Cheers Jorge.-

Sept. 8, 2014

duckduckgo

by james.from.wellington＠gmail.com

Google also redirects through itself. The rationale is to avoid leaking your search terms to the found site, in the referring URL field that Dillo doesn't populate. The reasons will include using that to create a market for analytics and attempting to measure whether the search delivers people's preconceptions. On the DDG parameters page: https://duckduckgo.com/params there is a redirect parameter: kd=-1 for off With casual testing, this search url in dillorc seems to work for me, and not to generate a second round-trip through ddg: search_url="dd DuckDuckGo https://duckduckgo.com/lite/?kp=-1&kd=-1&kh=1&q=%s" but I can't see the redirect even if I turn it on, so that's not very conclusive. On 9/6/14, eocene <eocene at gmx.com> wrote: > > Just tried searching for something using duckduckgo with midori, using > the standard search, not the light one. I copied the link URL and saw > that they're doing the same thing that google does -- the link URL shown > at the bottom of the screen is what you expect, but the link is really > a redirection through duckduckgo. > > Doesn't look like dillo does that -- maybe something to do with > javascript, didn't matter why to me. > > Anyway, I didn't exactly like ddg behaving this way, and I believe I > will try using startpage more often instead. (Although I have to turn > off CSS to get a next button on startpage results...) > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev at dillo.org > http://lists.dillo.org/cgi-bin/mailman/listinfo/dillo-dev >

Sept. 8, 2014

url display in location bar

by Johannes.Hofmann＠gmx.de

On Sat, Sep 06, 2014 at 07:40:19PM +0000, eocene wrote: > > I often wish that dillo would show the beginning of the URL instead > of the end. ("Where am I in this tab?") > > diff -r b28e4a47d4a1 src/ui.cc > --- a/src/ui.cc Sat Sep 06 16:56:22 2014 +0000 > +++ b/src/ui.cc Sat Sep 06 19:33:36 2014 +0000 > @@ -816,7 +816,7 @@ > { > if (!str) str = ""; > Location->value(str); > - Location->position(strlen(str)); > + Location->position((Fl::focus() == Location) ? strlen(str) : 0); > } > > /* > Looks good to me. Johannes

Sept. 7, 2014

url display in location bar

by eocene＠gmx.com

I often wish that dillo would show the beginning of the URL instead of the end. ("Where am I in this tab?") diff -r b28e4a47d4a1 src/ui.cc --- a/src/ui.cc Sat Sep 06 16:56:22 2014 +0000 +++ b/src/ui.cc Sat Sep 06 19:33:36 2014 +0000 @@ -816,7 +816,7 @@ { if (!str) str = ""; Location->value(str); - Location->position(strlen(str)); + Location->position((Fl::focus() == Location) ? strlen(str) : 0); } /*

Sept. 6, 2014

duckduckgo

by eocene＠gmx.com

Just tried searching for something using duckduckgo with midori, using the standard search, not the light one. I copied the link URL and saw that they're doing the same thing that google does -- the link URL shown at the bottom of the screen is what you expect, but the link is really a redirection through duckduckgo. Doesn't look like dillo does that -- maybe something to do with javascript, didn't matter why to me. Anyway, I didn't exactly like ddg behaving this way, and I believe I will try using startpage more often instead. (Although I have to turn off CSS to get a next button on startpage results...)

Sept. 5, 2014

configure.in errors

by csoren＠isd.net

> Chris wrote: > > This is from a fresh hg pull, running autogen.sh (or > > aclocal): > > > > configure.in:472: error: AC_SUBST: `src doc' is not a > > valid shell variable name > > configure.in:472: the top level > > autom4te: /usr/bin/m4 failed with exit status: 1 > > aclocal: autom4te failed with exit status: 1 > > > > changing the line AC_SUBST(src doc) to two lines of > > AC_SUBST(src) and AC_SUBST(doc) fixes it. > > That's odd. configure.in moved to configure.ac in late > 2012... > Bad hg syntax on my part, sorry! I fixed it with 'hg update -C`

Aug. 30, 2014

configure.in errors

by csoren＠isd.net

This is from a fresh hg pull, running autogen.sh (or aclocal): configure.in:472: error: AC_SUBST: `src doc' is not a valid shell variable name configure.in:472: the top level autom4te: /usr/bin/m4 failed with exit status: 1 aclocal: autom4te failed with exit status: 1 changing the line AC_SUBST(src doc) to two lines of AC_SUBST(src) and AC_SUBST(doc) fixes it.

Aug. 30, 2014

Last hg tip

by jcid＠dillo.org

Hi Sebastian, I'm following closely our hg tip and some things are improving. OTOH the last tip sometimes drops the horizontal scroller bar leaving content out of reach. e.g. [1] [1] http://lwn.net/Articles/609892/#Comments -- Cheers Jorge.-

Aug. 30, 2014

Rendering of illegal widths (incl "px", which used to be legal)

by james.from.wellington＠gmail.com

Hello All, The row of three pictures on this web-page: http://www.avrprojects.net/index.php?view=article&id=61 renders badly in dillo, and differently from Chrome and firefox, because two of them have: width="180px" which the source-code for dillo 3.0.4 (html.cc at about line 1450) tells me used to be legal html, but isn't anymore. Dillo: - reports this as a web bug (with which I agree) - sets the length to auto (which I think means using the default width) To minimise the damage from illegal pages, without hiding the problem, I propose to assume that the numbers in all widths are sensible, and to complain about, but ignore, the trailing garbage. I also discovered that the bug message and another, suppressed, message had type problems, which I have addressed in a way that looks reasonable on osx. My proposed patch is below. Please be aware that Jorge and I started a conversation about whether this was the right thing to do, which wedged. I tested this proposed change by hacking up saved copies of the web-page in various ways. One of them, which makes a mess of the bug message, is attached, but they are not really a clean test-case. I am not aware of any automated test into which this change should be added. If someone can point me toward one, then I will think about how to test it cleanly. Regards, James. ----------------------- $ diff html.cc.orig html.cc 1483,1485c1483,1488 < if (*end && !isspace (*end)) { < BUG_MSG("Garbage after length: %s\n", attr); < l = CSS_CREATE_LENGTH(0.0, CSS_LENGTH_TYPE_AUTO); --- > while (end && isspace(*end)) > ++end; > if (end && *end) { > BUG_MSG("Garbage after length: '%s'; " > "ignoring garbage; using %g (possibly in pixels)\n", > attr, CSS_LENGTH_VALUE(l)); 1489c1492 < _MSG("a_Html_parse_length: \"%s\" %d\n", attr, CSS_LENGTH_VALUE(l)); --- > _MSG("a_Html_parse_length: \"%s\" %g\n", attr, CSS_LENGTH_VALUE(l)); ----------------------- ps I am contemplating getting involved in other trivial rendering problems, and thinking about the todos in dpid/main.c:204 and dpid/main.c:297. My interest in the todos is that dillo functions with gmail, but keeps (de facto) logging me out by discarding my session cookie. Could someone please point me to generic advice about: - which source tree I should be building (Jorge mentioned GROWS, but I don't know what that means) - how to use mercurial to develop multiple patches in parallel and keep them separate, while running a built program that includes all of them ?

Aug. 25, 2014

Stretched out images

by fusionfile＠gmail.com

On 2014-08-10 14:34, Sebastian Geerken wrote: > Nearly correct: all changes to <http://flpsed.org/hgweb/dillo_grows> > are now in the main repository <http://hg.dillo.org/dillo>; the former > is not up to date and misses some fixes, so please use the latter one. > > Keeping aspect ratio of images should work now; if not, this is a bug > to be fixed. Thanks for your effort, Sebastian. I just updated the source to the latest revision (3877) and recompiled Dillo but the problem remains; a Google image search still shows horizontally stretched out images. Any clues? -- August

Aug. 10, 2014

Stretched out images

by sgeerken＠dillo.org

On Sun, Aug 10, 2014, higuita wrote: > Hi > > > make them look *really* ugly. For instance if I do a Google image > > search all images are stretched out horizontally: > (...) > > How can we fix this? > > AFAIK, this is a due missing features in the CSS support. > Current support for floats and grows seems fix this, but is still > incomplete in the main dillo. Try this one with more complete support > until its merged back: > > http://flpsed.org/hgweb/dillo_grows > > It works fine for me using this one. Nearly correct: all changes to <http://flpsed.org/hgweb/dillo_grows> are now in the main repository <http://hg.dillo.org/dillo>; the former is not up to date and misses some fixes, so please use the latter one. Keeping aspect ratio of images should work now; if not, this is a bug to be fixed. Sebastian

Aug. 10, 2014

Stretched out images

by higuita7＠yahoo.co.uk

Hi > make them look *really* ugly. For instance if I do a Google image > search all images are stretched out horizontally: (...) > How can we fix this? AFAIK, this is a due missing features in the CSS support. Current support for floats and grows seems fix this, but is still incomplete in the main dillo. Try this one with more complete support until its merged back: http://flpsed.org/hgweb/dillo_grows It works fine for me using this one. Best regards, 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

Aug. 9, 2014

Stretched out images

by fusionfile＠gmail.com

In the current development version of Dillo (rev. 3873) images are sometimes scaled in a way that doesn't preserve the aspect ratio which make them look *really* ugly. For instance if I do a Google image search all images are stretched out horizontally: http://www.google.com/search?q=test How can we fix this? Regards, August

Aug. 9, 2014

dillo slower than iceweasel on some pages

by eocene＠gmx.com

Andreas wrote: > Hi, > > I made a shocking experience when visiting pages like > http://www.wetteronline.de/wetter/berlin > > hg tip dillo takes 45 seconds. > > The last release takes a few seconds. > Starting a fresh iceweasel I need around 17 seconds. I hope there is > still much room to optimize and there is a possibility to have a fast > browser even with floats. For those times when we just need to get our information quickly -- to fill in the gap while floats/grows are being optimised -- I just copied over the changes since 3.0.4 that don't involve floats or grows into http://flpsed.org/hgweb/eocene_persistent_connections/ I didn't try to be exceedingly careful when doing this, but it appears to be working so far.

Aug. 6, 2014

Dillo on the BLFS wiki

by onepoint＠starurchin.org

eocene wrote: > It could perhaps mention cookiesrc, style.css, domainrc... OK, I revamped the configuration sections to to describe these. Any other suggstions? http://wiki.linuxfromscratch.org/blfs/wiki/dillo3 Regards, Jeremy Henty

Aug. 6, 2014

Dillo 3.1 to be expected when? (was: Re: dillo slower than iceweasel on some pages)

by abe＠deuxchevaux.org

Hi, On Sat, Aug 02, 2014 at 02:38:31PM +0200, Sebastian Geerken wrote: > the next release 3.1 should be as fast as you'd expect. When can this release be expected? Is there a chance that a reasonably stable version is available before November? Background: The freeze for the next Debian Stable release will be in November and Dillo 3.1 needs to be uploaded to Debian Unstable beforehand to become part of Debian's next Stable release. :-) 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.nonhtmlmail.org/campaign.html | abe at noone.org (Mail+Jabber) / \ I love long mails: http://email.is-not-s.ms/ | http://noone.org/abe/ (Web)

Aug. 2, 2014

dillo slower than iceweasel on some pages

by sgeerken＠dillo.org

Hi Andreas, On Sat, Aug 02, 2014, Andreas Kemnade wrote: > I made a shocking experience when visiting pages like > http://www.wetteronline.de/wetter/berlin > > hg tip dillo takes 45 seconds. > > The last release takes a few seconds. > Starting a fresh iceweasel I need around 17 seconds. I hope there is > still much room to optimize and there is a possibility to have a fast > browser even with floats. Yes, the current development version has still performance issues (mainly due to floats). We are working on this; the next release 3.1 should be as fast as you'd expect. Sebastian

Aug. 2, 2014

dillo slower than iceweasel on some pages

by andreas＠kemnade.info

Hi, I made a shocking experience when visiting pages like http://www.wetteronline.de/wetter/berlin hg tip dillo takes 45 seconds. The last release takes a few seconds. Starting a fresh iceweasel I need around 17 seconds. I hope there is still much room to optimize and there is a possibility to have a fast browser even with floats. Greetings Andreas Kemnade

Aug. 2, 2014

abort failed queries

by eocene＠gmx.com

I wanted to inform the user when a query failed by showing a message and greying out the stop icon instead of letting them wait forever and wonder. Patch attached. Examples: starurchin.org (Connection refused at present, anyway. Fails immediately.) auriga.wearlab.de (no server there, of course. Takes a minute or so.) dillo.asdfgh (leaves the DNS error msgs alone and greys the stop icon.)

July 31, 2014

Dillo on the BLFS wiki

by eocene＠gmx.com

It could perhaps mention cookiesrc, style.css, domainrc...

July 28, 2014

Dillo on the BLFS wiki

by onepoint＠starurchin.org

I have updated the Dillo page on the Beyond Linux From Scratch (BLFS) project wiki [1] to version 3.0.4 . Are there any other changes I should make? Perhaps the description of CSS support needs updating - it has come a long way since that part of the page was written. Are there any new configuration files to describe? Please suggest changes and I'll update the page with them. Regards, Jeremy Henty [1]: http://wiki.linuxfromscratch.org/blfs/wiki/dillo3

July 27, 2014

x11 icon name

by eocene＠gmx.com

On fvwm, there's a pager showing the different windows on the different desktops, and usually the (beginning of the) title of the window is written on the little depiction of the window. But with Dillo, the depiction frequently had no title written on it. And I'd ignored this for a long time. Yesterday, I noticed that it had "O" when I was reading something with a window title of "Dillo: Chapter 7. I/O" and I'm like, "Slashes. It doesn't like slashes..." It seems that fvwm is displaying an "icon name". In Fl_Window::label(), if you don't set an icon name, it takes the label and runs it through fl_filename_name(name) for...some reason, thereby trimming everything up to the final slash. I just tried the attached patch, and the icon name was shown properly. Or maybe it should just be set to "Dillo" and left that way. I don't know whether there are any strong conventions here. Does your window mgr like to use the "icon name" at all?

July 22, 2014

diilo in a cpu loop

by sgeerken＠dillo.org

On Tue, Jul 22, 2014, higuita wrote: > Still, after some browsering i found that http://www.sapo.pt crash > the dillo_grows :) At least this one was simple to fix. Sebastian

July 22, 2014

diilo in a cpu loop

by higuita7＠yahoo.co.uk

> > http://aventar.eu/2014/07/11/a-historia-do-banco-do-meu-avo/ > You may try the version from <http://flpsed.org/hgweb/dillo_grows>, > which is already quite stable. thanks, it's much better (still have a cpu spike loading the page, but it ends). Still, after some browsering i found that http://www.sapo.pt crash the dillo_grows :) Again, thanks for the help 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

July 22, 2014

diilo in a cpu loop

by sgeerken＠dillo.org

On Tue, Jul 22, 2014, higuita wrote: > Hi! > > I'm using the latest dillo mercurial version and when trying to > see this page, dillo uses all cpu and keep using it: > > http://aventar.eu/2014/07/11/a-historia-do-banco-do-meu-avo/ You may try the version from <http://flpsed.org/hgweb/dillo_grows>, which is already quite stable. I guess this has to do with floats, but work on this will only happen in the dillo_grows repository. Sebastian

July 22, 2014

diilo in a cpu loop

by higuita7＠yahoo.co.uk

Hi! I'm using the latest dillo mercurial version and when trying to see this page, dillo uses all cpu and keep using it: http://aventar.eu/2014/07/11/a-historia-do-banco-do-meu-avo/ Thanks for dillo 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

July 21, 2014

build fails on CentOS 7

by rdt＠cs.queensu.ca

>| >|I've just pushed a possible fix to <http://hg.dillo.org/dillo>, please >| >|test it. Or apply the attached patch to dillo 3.0.4, if you want to >| >|install a stable version. >| >|The available automake isn't version 1.14 so I can't test >|it. I installed automake-1.14.1 from Fedora 21 and the patched dillo-3.0.4 builds successfully. Thanks. Best, Bob T.

July 12, 2014

build fails on CentOS 7

by rdt＠cs.queensu.ca

>|I've just pushed a possible fix to <http://hg.dillo.org/dillo>, please >|test it. Or apply the attached patch to dillo 3.0.4, if you want to >|install a stable version. The available automake isn't version 1.14 so I can't test it. But as a workaround, I deleted test from the SUBDIRS list in the global Makefile and all works well, as far as I can tell. Bob T.

July 12, 2014

build fails on CentOS 7

by sgeerken＠dillo.org

On Sa, Jul 12, 2014, Bob Tennent wrote: > : > Making all in test > make[2]: Entering directory `/home/rdt/src/dillo-3.0.4/test' > g++ -DHAVE_CONFIG_H -I. -I.. -I.. -I/usr/local/include -I/usr/include/freetype2 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_THREAD_SAFE -D_REENTRANT -g -O2 -Wall -W -Wno-unused-parameter -fno-rtti -fno-exceptions -MT dw_anchors_test.o -MD -MP -MF .deps/dw_anchors_test.Tpo -c -o dw_anchors_test.o dw_anchors_test.cc > mv -f .deps/dw_anchors_test.Tpo .deps/dw_anchors_test.Po > g++ -I/usr/include/freetype2 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_THREAD_SAFE -D_REENTRANT -g -O2 -Wall -W -Wno-unused-parameter -fno-rtti -fno-exceptions -L/usr/local/lib -o dw-anchors-test dw_anchors_test.o ../dw/libDw-widgets.a ../dw/libDw-fltk.a ../dw/libDw-core.a ../lout/liblout.a -Wl,-z,relro -lfltk > /bin/ld: ../dw/libDw-fltk.a(libDw_fltk_a-fltkviewbase.o): undefined reference to symbol 'XCreatePixmap' > /bin/ld: note: 'XCreatePixmap' is defined in DSO /lib64/libX11.so.6 so try adding it to the linker command line > /lib64/libX11.so.6: could not read symbols: Invalid operation > collect2: error: ld returned 1 exit status > make[2]: *** [dw-anchors-test] Error 1 > make[2]: Leaving directory `/home/rdt/src/dillo-3.0.4/test' I've just pushed a possible fix to <http://hg.dillo.org/dillo>, please test it. Or apply the attached patch to dillo 3.0.4, if you want to install a stable version. Sebastian

July 12, 2014

build fails on CentOS 7

by rdt＠cs.queensu.ca

: Making all in test make[2]: Entering directory `/home/rdt/src/dillo-3.0.4/test' g++ -DHAVE_CONFIG_H -I. -I.. -I.. -I/usr/local/include -I/usr/include/freetype2 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_THREAD_SAFE -D_REENTRANT -g -O2 -Wall -W -Wno-unused-parameter -fno-rtti -fno-exceptions -MT dw_anchors_test.o -MD -MP -MF .deps/dw_anchors_test.Tpo -c -o dw_anchors_test.o dw_anchors_test.cc mv -f .deps/dw_anchors_test.Tpo .deps/dw_anchors_test.Po g++ -I/usr/include/freetype2 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_THREAD_SAFE -D_REENTRANT -g -O2 -Wall -W -Wno-unused-parameter -fno-rtti -fno-exceptions -L/usr/local/lib -o dw-anchors-test dw_anchors_test.o ../dw/libDw-widgets.a ../dw/libDw-fltk.a ../dw/libDw-core.a ../lout/liblout.a -Wl,-z,relro -lfltk /bin/ld: ../dw/libDw-fltk.a(libDw_fltk_a-fltkviewbase.o): undefined reference to symbol 'XCreatePixmap' /bin/ld: note: 'XCreatePixmap' is defined in DSO /lib64/libX11.so.6 so try adding it to the linker command line /lib64/libX11.so.6: could not read symbols: Invalid operation collect2: error: ld returned 1 exit status make[2]: *** [dw-anchors-test] Error 1 make[2]: Leaving directory `/home/rdt/src/dillo-3.0.4/test' Bob T.

July 12, 2014

HTTP persistent connections / keep-alive

by eocene＠gmx.com

I wrote, three months ago: > I have been experimenting with persistent connections for http, and > wanted to see what your thoughts were. > > This has been working well enough for me: > http://flpsed.org/hgweb/eocene_persistent_connections/ > > Why? To be a good internet citizen, tcp slow-start, etc. > > Johannes gave it a try and said it performed well. [snip] So I've been using it for three months and I like it. I haven't noticed any problems with it, and I'm planning to merge it in next week -- maybe around the 17th. To enjoy persistent connections, you would have to put http_persistent_conns=YES in dillorc.

July 12, 2014

general uri handler

by dennisn＠dennisn.linuxd.org

On Sat, 5 Jul 2014 12:27:54 +0200, Johannes Hofmann wrote: > On Sat, Jun 28, 2014 at 07:58:20AM -0400, Dennis New wrote: > > How are you guys handling non-builtin uris, like ed2k:, mailto:, > > magnet:, etc? I hacked a general purpose handler (that calls a shell > > script) from dpi/hello.c, but surely something this useful should > > ship with dillo? > > > > It seems that this has been a popular request for a long time :P... > > > > http://lists.dillo.org/pipermail/dillo-dev/2004-October/002403.html > > I mostly use "Copy link location" from the popup menu. > Can you make the source of your general purpose handler availble > somewhere? It was a tiny hack of dpi/hello.c, I also got rid of the dialog box and changed the html output a bit, and didn't bother doing escape character filtering... + Dstr *cmd_arg = dStr_new(""); if (cmd && url) { - child_cmd = dStrdup("date -R"); + dStr_sprintfa(cmd_arg, "dillo-urihandler \"%s\"", url); + child_cmd = dStrdup(cmd_arg->str); MSG("[%s]\n", child_cmd); To make compilation easier, I didn't bother renaming "hello.filter.dpi". And I had to add an entry for each protocol that I wanted to handle in dpidrc... +proto.magnet=bla/hello.filter.dpi +proto.mailto=bla/hello.filter.dpi

July 5, 2014

general uri handler

by Johannes.Hofmann＠gmx.de

On Sat, Jun 28, 2014 at 07:58:20AM -0400, Dennis New wrote: > How are you guys handling non-builtin uris, like ed2k:, mailto:, > magnet:, etc? I hacked a general purpose handler (that calls a shell > script) from dpi/hello.c, but surely something this useful should ship > with dillo? > > It seems that this has been a popular request for a long time :P... > > http://lists.dillo.org/pipermail/dillo-dev/2004-October/002403.html I mostly use "Copy link location" from the popup menu. Can you make the source of your general purpose handler availble somewhere? Cheers, Johannes

July 5, 2014

general uri handler

by dennisn＠dennisn.linuxd.org

How are you guys handling non-builtin uris, like ed2k:, mailto:, magnet:, etc? I hacked a general purpose handler (that calls a shell script) from dpi/hello.c, but surely something this useful should ship with dillo? It seems that this has been a popular request for a long time :P... http://lists.dillo.org/pipermail/dillo-dev/2004-October/002403.html

June 28, 2014

Dicache work

by johannes.hofmann＠gmx.de

Hi Jorge, On Tue, Jun 24, 2014 at 08:32:11AM -0400, Jorge Arellano Cid wrote: > Hi there, > > There're three new dicache patches in the repo. These have > beeen tested/checked with valgrind and gcc's address sanitizer. > > Given the last memory usage reports, and a very necessary > cleanup that was pending for a long time, this patch set tries to > tackle the issue. > > There's also some decompressed image caching enabled (read the > verbose changelog) that will make dillo feel faster. Nice. It really helps especially with the CSS-triggered repushes where we previously were re-decoding the images. Cheers, Johannes

June 25, 2014

Dicache work

by jcid＠dillo.org

Hi there, There're three new dicache patches in the repo. These have beeen tested/checked with valgrind and gcc's address sanitizer. Given the last memory usage reports, and a very necessary cleanup that was pending for a long time, this patch set tries to tackle the issue. There's also some decompressed image caching enabled (read the verbose changelog) that will make dillo feel faster. Please test and send feedback. BTW, I found ways to crash dillo without the patches and wonder whether some of you also experimented image-related crashes. -- Cheers Jorge.-

June 24, 2014

Experimental repository "dillo_grows"

by sgeerken＠dillo.org

Hi! At <http://flpsed.org/hgweb/dillo_grows>, you'll find a version of dillo with some changes in how widget sizes are handled (GROWS stands for Grand Redesign Of Widget Sizes). There is also some doxygen documentation in doc/dw-grows.doc, or html/dw-grows.html. Work on floats is currently stalled since most recent bugs related to floats seem to result from problems addressed in GROWS. Sebastian

June 19, 2014

dicache valgrind log entries

by jcid＠dillo.org

On Fri, May 30, 2014 at 10:28:05AM -0400, Jorge Arellano Cid wrote: > On Fri, May 30, 2014 at 05:19:10AM +0000, eocene wrote: > > > > Jeremy's logs have been showing lots of dicache > > entries in recent days. > > Thanks. I'm working in the dicache now and there plenty > of things to iron out... Besides the "lost" blocks, valgrind also detected an "invalid read" for which I just committed a fix. The interesting part is that commit #3669 didn't introduce it, but just exposed it. -- Cheers Jorge.-

June 8, 2014

dicache valgrind log entries

by jcid＠dillo.org

On Fri, May 30, 2014 at 10:28:05AM -0400, Jorge Arellano Cid wrote: > On Fri, May 30, 2014 at 05:19:10AM +0000, eocene wrote: > > > > Jeremy's logs have been showing lots of dicache > > entries in recent days. > > Thanks. I'm working in the dicache now and there plenty > of things to iron out... Well, it turned out to be much less than it seemed. Just a simple bug in the new code I was working on. On current tree, valgrind reports "definitely lost" DICacheEntry blocks created by Dicache_entry_new(), but in fact, they're not lost. e.g. running: $valgrind --tool=memcheck --leak-check=yes --log-file=valg3678.out \ ./dillo http://lwn.net/ and exiting dillo after the page is fully loaded, reports lost blocks from Dicache_entry_new() (one per image). Now, if you run the same command, wait until the page is fully loaded, then switch to bookmarks and exit, there's no lost block reported. The point is: bookmarks has no images, and once it loads the dicache cleans previous images (from lwn.net) hence valgrind, sees no leaks. There're ways to fine tune valgrind with specific parameters for leak detection, but I don't know them in the necessary depth to chose the correct ones. -- Cheers Jorge.-

June 7, 2014

Dillo Buildroot package

by rogerx.oss＠gmail.com

> On Tue, Jun 03, 2014 at 09:28:31PM +0200, Johannes Hofmann wrote: >Hi, > >thanks to Peter Seiderer there now is a Dillo Buildroot [1] >package [2] available. > >Cheers, >Johannes I do something similar here using Gentoo, setting up a Gentoo Linux distribution on a 64 bit quad core for cross-compiling Gentoo based packages for my slower 32 bit Pentium3 boxes. If I had embedded 32 bit platforms, I likely could now easily build from source for the embedded platforms. Works seemingly flawlessly so far, aside from the effect of using the slow & heavy Python scripting used within Gentoo's (Portage) package management system. -- Roger http://rogerx.freeshell.org/

June 4, 2014

Dillo Buildroot package

by Johannes.Hofmann＠gmx.de

Hi, thanks to Peter Seiderer there now is a Dillo Buildroot [1] package [2] available. Cheers, Johannes [1] http://buildroot.net [2] http://git.buildroot.net/buildroot/commit/?id=65b47530229b1ebaa4e2d40ff7656…

June 3, 2014

dicache valgrind log entries

by jcid＠dillo.org

On Fri, May 30, 2014 at 05:19:10AM +0000, eocene wrote: > > Jeremy's logs have been showing lots of dicache > entries in recent days. Thanks. I'm working in the dicache now and there plenty of things to iron out... -- Cheers Jorge.-

May 30, 2014

dicache valgrind log entries

by eocene＠gmx.com

Jeremy's logs have been showing lots of dicache entries in recent days.

May 30, 2014

[hughsient@gmail.com: Please create an AppData file for Dillo]

by Johannes.Hofmann＠gmx.de

On Wed, May 28, 2014 at 01:22:38PM -0400, Jorge Arellano Cid wrote: > Hi, > > Does somebody have experience with this? I got the exact same mail for another small project as well. I think it's some sort of mass-mailing to get more projects to provide these AppData files. Cheers, Johannes > > -- > Cheers > Jorge.- > Date: Wed, 28 May 2014 11:26:33 +0100 > From: Richard Hughes <hughsient at gmail.com> > To: jcid at dillo.org > Subject: Please create an AppData file for Dillo > > Please consider writing and installing an AppData file with the > application description and some screenshots, else Dillo looks really > bad in the GNOME and KDE Software Centers. We'd love to showcase more > applications, but without the extra data file we can't. See > http://people.freedesktop.org/~hughsient/appdata/ for details; thanks! > > Richard > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev at dillo.org > http://lists.dillo.org/cgi-bin/mailman/listinfo/dillo-dev

May 29, 2014

[hughsient@gmail.com: Please create an AppData file for Dillo]

by rogerx.oss＠gmail.com

BTW, I use DWM or Dynamic Window Manager from suckless.org. ;-) -- Roger http://rogerx.freeshell.org/

May 28, 2014

[hughsient@gmail.com: Please create an AppData file for Dillo]

by rogerx.oss＠gmail.com

> On Wed, May 28, 2014 at 01:22:38PM -0400, Jorge Arellano Cid wrote: >Hi, > > Does somebody have experience with this? > >-- > Cheers > Jorge.- >Subject: Please create an AppData file for Dillo >Date: Wed, 28 May 2014 11:26:33 +0100 >From: Richard Hughes <hughsient at gmail.com> >To: jcid at dillo.org > >Please consider writing and installing an AppData file with the >application description and some screenshots, else Dillo looks really >bad in the GNOME and KDE Software Centers. We'd love to showcase more >applications, but without the extra data file we can't. See >http://people.freedesktop.org/~hughsient/appdata/ for details; thanks! > >Richard > http://people.freedesktop.org/~hughsient/appdata/ What happens if I don't ship this file? The GNOME Software Center currently shows a nag message that the upstream project doesn't ship the additional data. Additionally, we will penalize apps that do not ship the extra metadata by showing them lower in the search results. -- Roger http://rogerx.freeshell.org/

May 28, 2014