- Dillo-dev - lists.mailman3.com

SSL in the browser
by eocene＠gmx.com Oct. 26, 2014

Oct. 26, 2014

My code for SSL in the browser hasn't been giving me any problems in recent days, so it would be nice to give it some wider use. http://www.dillo.org/test/ssl_in_browser.diff

5 8

subscripts and superscripts
by dennisn＠dennisn.linuxd.org Sept. 27, 2014

Sept. 27, 2014

Multi-level subscripts or superscripts don't render properly -- it only renders the first level. Eg: 2<sup>2<sup>2</sup></sup> Will appear as 2^22 instead of 2^2^2 :p.

1 0

Dillo and Irix
by diegel＠work.de Sept. 24, 2014

Sept. 24, 2014

Hello, I just started another attempt to port dillo to Irix. With gcc 4.7 it compiles without any serious warnings. It starts and about:splash shows up correctly, But if you want to use it something goes wrong: ftp works without problems. files show up if the path is very short (less than 32 bytes). If you browse directories and you want to change from /tmp to /tmp/x for example. I changes to /x http doesn't work at all. If you go to a non existing url. For example: http://test.yy you get the following console output, but nothing happens in the dollo window: Nav_open_url: new url='http:test.yy' a_Capi_ccc : OpStart [2B] Info=10262fa8 Flags=0 a_Dpi_ccc : OpStart [2B] Info=10262da0 Flags=0 a_IO_ccc : OpStart [2B] Info=10262e90 Flags=0 a_Capi_ccc : OpStart [1B] Info=10262eb8 Flags=0 a_Http_ccc : OpStart [1B] Info=10262f80 Flags=0 a_IO_ccc : OpStart [1B] Info=10262e40 Flags=0 Http_must_use_proxy: http:test.yy NO DNS error: HOST_NOT_FOUND Dns_server [0]: is (nil) a_IO_ccc : OpAbort [1B] Info=10262e40 Flags=0 a_Capi_ccc : OpAbort [1F] Info=10262eb8 Flags=0 a_Capi_ccc : OpAbort [2B] Info=10262fa8 Flags=0 a_Dpi_ccc : OpAbort [2B] Info=10262da0 Flags=0 a_IO_ccc : OpAbort [2B] Info=10262e90 Flags=0 If you are opening an existing url like dillo.org it puts out: Nav_open_url: new url='http://www.dillo.org/' a_Capi_ccc : OpStart [2B] Info=10262fd0 Flags=0 a_Dpi_ccc : OpStart [2B] Info=10262f08 Flags=0 a_IO_ccc : OpStart [2B] Info=10262e68 Flags=0 a_Capi_ccc : OpStart [1B] Info=10262ee0 Flags=0 a_Http_ccc : OpStart [1B] Info=10262e90 Flags=0 a_IO_ccc : OpStart [1B] Info=10262f30 Flags=0 Http_must_use_proxy: http://www.dillo.org/ NO Dns_server [0]: www.dillo.org is 85.214.105.140 Connecting to 85.214.105.140 a_IO_ccc : OpSend [1B] Info=10262f30 Flags=0 a_Capi_ccc : OpSend [1F] Info=10262ee0 Flags=0 a_Capi_ccc : OpSend [2B] Info=10262fd0 Flags=0 a_Dpi_ccc : OpSend [2B] Info=10262f08 Flags=0 a_IO_ccc : OpSend [2B] Info=10262e68 Flags=0 http, referer='Referer: http://www.dillo.org/ ' Query: {GE} a_IO_ccc : OpSend [1B] Info=10262f30 Flags=0 and after some seconds: a_IO_ccc : OpEnd [2F] Info=10262e68 Flags=0 a_Dpi_ccc : OpEnd [2F] Info=10262f08 Flags=0 a_Capi_ccc : OpEnd [2F] Info=10262fd0 Flags=0 a_Capi_ccc : OpEnd [1B] Info=10262ee0 Flags=0 a_Http_ccc : OpEnd [1B] Info=10262e90 Flags=0 a_IO_ccc : OpEnd [1B] Info=10262f30 Flags=0 but nothing happens in the dillo window. I would be very happy to get any hint what is going wrong here. Thanks you, Jan

5 21

background images and --local/URL_SpamSafe
by eocene＠gmx.com Sept. 23, 2014

Sept. 23, 2014

It looks like --local/URL_SpamSafe doesn't have any effect on background images.

2 1

Dillo and Irix
by csoren＠isd.net Sept. 19, 2014

Sept. 19, 2014

I stand corrected! 0_o Thanks guys... :) > > The gcc on my machine is the nekoware gcc 4.7.1 > compiled by shadeofblue. It is the standard gcc > for Irix currently. If __sgi is true it is really > a SGI system. > > > > > eocene wrote: > > > > > > > > Chris wrote: > > > #if defined(__sgi) > > > > > > This will work with the MIPSPro compiler but > > > I'm pretty sure the GNU compilers do not > > > #define __sgi > > > > > > > On Jan's machine, > > > > ./cpp --version > > cpp (GCC) 4.7.1 > > > > ./cpp -dM |grep __sgi > > #define __sgi 1 > > #define __sgi__ 1 > >

1 0

Dillo and Irix
by csoren＠isd.net Sept. 19, 2014

Sept. 19, 2014

> > > > #if defined(__sgi) > > This will work with the MIPSPro compiler but I'm pretty sure the GNU compilers do not #define __sgi

3 2

Problems tackling a bug
by sgeerken＠dillo.org Sept. 17, 2014

Sept. 17, 2014

Hi! I noticed that the current tip of dillo hangs in most cases when displaying <http://www.dillo.org/>. I succeeded to reproduce this bug in gdb, but get many "<optimized out>" values. So I tried to reduce optimization, but unfortunately had problems reproducing this bug: - "-O2" (standard): reproducable both stand-alone and in gdb; - "-O1": reproducable stand-alone, but not in gdb; - "-O0": not reproducable at all. Versions envolved: $ gcc --version gcc (Debian 4.7.2-5) 4.7.2 $ gdb --version GNU gdb (GDB) 7.4.1-debian Any ideas? Sebastian

2 2

Dillo and Irix
by csoren＠isd.net Sept. 16, 2014

Sept. 16, 2014

> > > > There might even be some builtin support for this check > > in autoconf as the issue is mentioned in [1]. > > > > I looked a bit yesterday and didn't get the impression > that there was anything. > There is an autoconf m4 macro for snprintf, with some IRIX specific checks, here: http://www.jhweiss.de/software/snprintf.html According to that page versions of IRIX all the way up to the present (6.5.30) don't adhere to the standard. For what it's worth this is the IRIX online manual page for snprintf(): http://techpubs.sgi.com/library/tpl/cgi-bin/getdoc.cgi?coll=0650&db=man&fna…

1 0

Browser tracking
by jcid＠dillo.org Sept. 16, 2014

Sept. 16, 2014

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.-

5 6

Patch: suppress duplicate Fl_Printer::class_id
by james.from.wellington＠gmail.com Sept. 16, 2014

Sept. 16, 2014

Hello All, Building commit 317f010 (two days ago) of dillo, I got a duplicate symbol on OSX 10.6.8 with gcc 4.2.1. Here is the diff that suppresses it. ---------------- $ hg diff diff -r c09473fb7311 dw/fltkplatform.cc --- a/dw/fltkplatform.cc Sat Sep 13 09:46:28 2014 +0000 +++ b/dw/fltkplatform.cc Sat Sep 13 23:49:26 2014 +1200 @@ -37,10 +37,10 @@ * any need for currently. This stub prevents that. */ class FL_EXPORT Fl_Printer : public Fl_Paged_Device { public: - static const char *class_id; +// static const char *class_id; Fl_Printer(void) {}; }; -const char *Fl_Printer::class_id = "Fl_Printer"; +//const char *Fl_Printer::class_id = "Fl_Printer"; /* Tooltips */ static Fl_Menu_Window *tt_window = NULL; --------------- I have no idea what it will turn out that I've broken. If having this as a pull request will help, then I will try to work out how. Regards, James.

2 2

dillo crash when dpid missing and view source used
by eocene＠gmx.com Sept. 16, 2014

Sept. 16, 2014

...it happens at least as far back as 3.0.4 release.

2 1

Implementing </div> closing <span>, and friends
by james.from.wellington＠gmail.com Sept. 15, 2014

Sept. 15, 2014

Hello all, [Sorry if this is a dup; gmail may be playing tricks on me.] This page displays, with distortions, in dillo 3.0.4, but the image does not display after commit 317f010: https://medium.com/@verynicetweets/getting-out-of-the-house-is-so-hard-thes… A partially cleaned-up and stripped version is attached, where the comment block shows a suppression of the problem. The page is illegal: two unclosed <span>s interfere with a </div> and the following <div>. There is code around html.cc:1355, which is intended to implement heuristics to close unclosed tags but, in the cases where it is triggered, no tags are closed. Here is a patch which I think implements the intent of the heuristics: ----------------- $ hg diff diff -r 26378f85c4ea src/html.cc --- a/src/html.cc Sun Sep 14 09:56:22 2014 +0000 +++ b/src/html.cc Mon Sep 15 18:13:21 2014 +1200 @@ -1355,7 +1355,9 @@ i_SELECT = a_Html_tag_index("select"), i_TEXTAREA = a_Html_tag_index("textarea"); int w3c_mode = !prefs.w3c_plus_heuristics; - int stack_idx, tag_idx, matched = 0, expected = 0; + // TODO: If there was a clean way of never having a tag index zero, + // (it's currently <a>), then expected_idx could be prettier. + int stack_idx, tag_idx, matched = 0, expected_idx = -1, skipped = 0; TagInfo new_tag = Tags[new_idx]; /* Look for the candidate tag to close */ @@ -1368,26 +1370,42 @@ break; } else if (Tags[tag_idx].EndTag == 'O') { /* skip an optional tag */ + ++skipped; continue; } else if ((new_idx == i_BUTTON && html->InFlags & IN_BUTTON) || (new_idx == i_SELECT && html->InFlags & IN_SELECT) || (new_idx == i_TEXTAREA && html->InFlags & IN_TEXTAREA)) { /* let these elements close tags inside them */ + ++skipped; continue; } else if (w3c_mode || Tags[tag_idx].TagLevel >= new_tag.TagLevel) { /* this is the tag that should have been closed */ - expected = 1; - break; + /* skip it as if it were optional, but complain */ + ++skipped; + if (-1 == expected_idx) { + // ie this is the first thing we're unwinding + expected_idx = tag_idx; + } + continue; } } + // Either or both matched and expected_idx could now be set + + // TODO: decide whether to carry line numbers in the parser state stack, + // in order to report them here. + if (matched) { + if (-1 != expected_idx) { + BUG_MSG("Unexpected closing tag: </%s> -- expected </%s>", + new_tag.name, Tags[expected_idx].name); + } + Html_tag_cleanup_to_idx(html, stack_idx); - } else if (expected) { - BUG_MSG("Unexpected closing tag: </%s> -- expected </%s>.", - new_tag.name, Tags[tag_idx].name); } else { - BUG_MSG("Unexpected closing tag: </%s>.", new_tag.name); + BUG_MSG("Unexpected closing tag: </%s>" + " -- explored %d layer(s) and not closed.", + new_tag.name, skipped); } } ----------------- Closing tags that match no opening tag (I used </area>, which is illegal) do not cause catastrophic failure. So far, it has not broken on my usual workload. Gmail is noisy, so I wonder if something's going wrong there, but it looks fairly normal. I have no good idea what a general test suite for this code looks like. If someone wants to point me toward related tests, then I will think about extending them. Regards, James.

1 0

dillo can't handle strings
by mail＠gabucino.hu Sept. 14, 2014

Sept. 14, 2014

See the issue on IRIX: http://lists.dillo.org/pipermail/dillo-dev/ 2014-April/010079.html Well, the same applies to PowerPC (OS X). "ftp://" works, "http://" doesn't. Somewhere there's a huge bug. Does anybody care? -- G

3 7

I'd like to add you to my professional network on LinkedIn
by acassis＠gmail.com Sept. 11, 2014

Sept. 11, 2014

Hi, I'd like to include you in my network to share updates and stay in touch. - Alan Accept: http://www.linkedin.com/blink?simpleRedirect=0Ue30PdjcNej0OdPgVe3sRcjARfkh9… You are receiving Invitation emails. Unsubscribe here: http://www.linkedin.com/blink?simpleRedirect=1DsCZ5cylLr6NFp30Q9npBp2RLr6NF… Learn why we included this at the following link: http://www.linkedin.com/blink?simpleRedirect=3wUdPgZp4BBr6dFt79x9DhPpnlDnSl… © 2014, LinkedIn Corporation. 2029 Stierlin Ct. Mountain View, CA 94043, USA

1 1

Problems tackling a bug
by eocene＠gmx.com Sept. 10, 2014

Sept. 10, 2014

Sebastian wrote: > I noticed that the current tip of dillo hangs in most cases when > displaying <http://www.dillo.org/>. I succeeded to reproduce this bug > in gdb, but get many "<optimized out>" values. So I tried to reduce > optimization, but unfortunately had problems reproducing this bug: > > - "-O2" (standard): reproducable both stand-alone and in gdb; > - "-O1": reproducable stand-alone, but not in gdb; > - "-O0": not reproducable at all. > > Versions envolved: > > $ gcc --version > gcc (Debian 4.7.2-5) 4.7.2 > $ gdb --version > GNU gdb (GDB) 7.4.1-debian > > Any ideas? I have the same gcc and gdb, and dillo doesn't seem to want to hang for me. Does it depend on your dillorc options?

3 2

duckduckgo
by eocene＠gmx.com Sept. 8, 2014

Sept. 8, 2014

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...)

2 1

url display in location bar
by eocene＠gmx.com Sept. 7, 2014

Sept. 7, 2014

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); } /*

2 1

configure.in errors
by csoren＠isd.net Aug. 30, 2014

Aug. 30, 2014

> 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`

1 0

configure.in errors
by csoren＠isd.net Aug. 30, 2014

Aug. 30, 2014

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.

1 0

Last hg tip
by jcid＠dillo.org Aug. 30, 2014

Aug. 30, 2014

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.-

1 0

Rendering of illegal widths (incl "px", which used to be legal)
by james.from.wellington＠gmail.com Aug. 25, 2014

Aug. 25, 2014

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 ?

1 0

Stretched out images
by fusionfile＠gmail.com Aug. 10, 2014

Aug. 10, 2014

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

3 3

dillo slower than iceweasel on some pages
by andreas＠kemnade.info Aug. 6, 2014

Aug. 6, 2014

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

4 3

Dillo on the BLFS wiki
by onepoint＠starurchin.org Aug. 6, 2014

Aug. 6, 2014

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

2 2

abort failed queries
by eocene＠gmx.com July 31, 2014

July 31, 2014

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.)

1 0

x11 icon name
by eocene＠gmx.com July 22, 2014

July 22, 2014

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?

1 0

diilo in a cpu loop
by higuita7＠yahoo.co.uk July 22, 2014

July 22, 2014

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

2 3

build fails on CentOS 7
by rdt＠cs.queensu.ca July 12, 2014

July 12, 2014

: 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.

2 3

HTTP persistent connections / keep-alive
by eocene＠gmx.com July 12, 2014

July 12, 2014

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. Initially I let FDs stick around even if I didn't immediately have new queries for them. When the server closed it, I'd get EPIPE on the write side and... I think it was ECONNRESET on the read side, send the OpEnd around ccc, and that worked all right and wasn't too messy. But then I wanted to handle the case where a FD sits idle and we try to reuse it and it fails. Sending the notifications around and getting everything back in a state where we could try again with a new connection was looking like it would be very messy. So I trimmed it all down so that, when we have our full reply, we reuse the FD if we already have something queued that can use it, and if not we just close the connection.

1 1

general uri handler
by dennisn＠dennisn.linuxd.org July 5, 2014

July 5, 2014

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

2 2

Dicache work
by jcid＠dillo.org June 25, 2014

June 25, 2014

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.-

2 1

Experimental repository "dillo_grows"
by sgeerken＠dillo.org June 19, 2014

June 19, 2014

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

1 0

dicache valgrind log entries
by eocene＠gmx.com June 8, 2014

June 8, 2014

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

2 3

Dillo Buildroot package
by Johannes.Hofmann＠gmx.de June 4, 2014

June 4, 2014

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…

2 1

[hughsient@gmail.com: Please create an AppData file for Dillo]
by jcid＠dillo.org May 29, 2014

May 29, 2014

Hi, Does somebody have experience with this? -- Cheers Jorge.-

3 3

dillo on NetBSD/evbarm(earmhf) with RaspberryPI
by jun＠soum.co.jp May 14, 2014

May 14, 2014

I'm work for dillo with NetBSD/evbarm on RaspberryPI. On NetBSD/evbarm(earmhf), dillo fails to start up because some HTML tables calclation problem. With apply patch contains this article,Dillo works fine on my RaspberryPI. http://mail-index.netbsd.org/port-arm/2014/04/22/msg002386.html thanx. -- Jun Ebihara

2 1

Reddit regression
by onepoint＠starurchin.org May 7, 2014

May 7, 2014

Things are progressing nicely (I have already abandoned two problem reports because they were fixed in the meantime) but there has been an unfortunate regression - a few days ago Reddit comment threads started thrashing the CPU. Example: http://www.reddit.com/r/haskell/comments/24rcf0/hourglass_a_new_simpler_tim… This is bad news for me as I follow a lot of subreddits. I hope it can be fixed soon. If there is anything I can do to help find the problem please say so. Regards, Jeremy Henty

2 3

character references, trailing ';', urls
by eocene＠gmx.com May 5, 2014

May 5, 2014

I was looking at how badly dillo handles something like: <a href="http://www.dillo.org?asdf&copy=3&micro=zxcv">link</a> It becomes a much more common problem with html5, which has a _lot_ more character references. I could perhaps stick an argument on the Html_parse_entity() in Html_get_attr2(), telling it to insist upon finding a ';'. If we still had cvs.auriga, I could dig through prehistory and try to see whether not demanding ';' termination was initially done with the strong belief that it was for the best overall (or maybe it was even inherited from gzilla), but we don't have cvs.auriga, and we don't have mailing list search working (not that that's generally very fun to dig through in any case). After all, maybe we should always insist upon proper termination.

2 8

[jcid@dillo.org: Commit 3626. Redraw problems]
by jcid＠dillo.org May 4, 2014

May 4, 2014

Hi, FYI. -- Cheers Jorge.-

3 19

More problem pages
by onepoint＠starurchin.org May 2, 2014

May 2, 2014

I updated and rebuilt a few minutes ago and though thecode is shaking out nicely there are still some problems. Layout thrashes: http://www.nature.com/nature/journal/v508/n7496_supp/full/508S66a.html CPU thrashes for a long time but eventually calms down: http://www.sciencebasedmedicine.org/microwaves-and-nutrition/ Regards, Jeremy Henty

3 4

Gamma error in picture scaling
by sgeerken＠dillo.org April 30, 2014

April 30, 2014

Hi all! Visit <http://www.4p8.com/eric.brasseur/gamma.html> (you remember?) and search for "dillo". Sebastian

2 1

H1's inside A's
by dennisn＠dennisn.linuxd.org April 29, 2014

April 29, 2014

I know technically the H1 heading tags aren't allowed between A../A, and Dillo rightfully complains about this: "a" is not allowed to contain "h1". -- closing "a" But it seems like an innocent tiny mistake. Can't dillo linkify anyways, in addition to throwing this error? Currently the link-information is lost and only accessibly if I manually view the source and copy-paste it. Other browsers (i.e. webkitgtk based ones) do this, which is quite useful.

4 4

New/fixed Toolbar icons
by pankso＠slitaz.org April 26, 2014

April 26, 2014

Hi all, Please find attached the screenshot of SliTaz Toolbar icons and her are the new pixmaps.slitaz.h + fixed pixmaps.tango.h: http://hg.slitaz.org/wok/file/tip/dillo/stuff/pixmaps.slitaz.h http://hg.slitaz.org/wok/file/tip/dillo/stuff/pixmaps.tango.h Dillo is the default web browser on SliTaz ARM and SliTaz Raspberry Pi distribution so I wanted a realy fine desktop integration with modern look and feel :-) By the way, congrats for all the work done on Dillo! Best regards, - Christophe Lincoln

3 3

Nanolinux distro with Dillo
by mailbox＠georgpotthast.de April 25, 2014

April 25, 2014

I just want to mention that I made a small (14 MB footprint) Linux distro called "Nanolinux" which includes Dillo as the browser plus many FLTK apps: https://sourceforge.net/projects/nanolinux/ Georg

2 1

[jcid@dillo.org: Re: [jcid@dillo.org: Commit 3626. Redraw problems]]
by jcid＠dillo.org April 24, 2014

April 24, 2014

FYI, -- Cheers Jorge.-

1 0

[jcid@dillo.org: Commit 3626. Redraw problems]
by johannes.hofmann＠gmx.de April 24, 2014

April 24, 2014

That was me. Sorry I didn't follow this. Can you point me to the problem? The idea with redrawY is that when loading long pages we don't keep redrawing the currently visible (top) part of the page while adding text on the bottom. Obviously this only works as long as the newly incoming HTML doesn't affect the layout of the already drawn (top) part of the page. Cheers, Johannes Am 24.04.2014 14:44 schrieb Sebastian Geerken <sgeerken at dillo.org>: On Wed, Apr 23, 2014, Sebastian Geerken wrote: > Hi Jorge, > >?? Today I saw commit 3626, and checked whether the pages I see to > > produce redraw storms and CPU hogs were gone, and...? no?? :-P > > > >?? I got one of them and worked reducing it to try to produce a good > > test case, that's the attachment. If you open it with embedded CSS > > disabled, it's OK, then enable it and voila: redraw storm and CPU > > hog. > > > >?? I hope this helps the cause. Please let me know whether you can > > work on it, or give me some clues to try to start digging further. > > Yes, I can reproduce the problem. Thanks for the test. > > This change (revision 3626) was for the opposite problem: in some > cases, there is no redraw. It seems that I'll have to care about the > TODO of the commit message soon: "Cleanup and document lastWordDrawn > and redrawY!". > > I'll work on this soon, after an issue I'll hope to finish today. I'm now working on this, and have already found out that this is not a redrawing problem: the only change in 3626 is that the CPU load is shifted from dillo to Xorg. (It seems that more redrawing is done, but this is rather a symptom of another problem, probably with resizing.) I noted this several times, so please observe CPU load (e. g.? with top(1)): if it stays high, even if dillo is responsive this is a problem you should send to the list. Sebastian PS: Cleaning up lastWordDrawn/redrawY is still an issue, but with lower priority.? Who did actually implement this? _______________________________________________ Dillo-dev mailing list Dillo-dev at dillo.org http://lists.dillo.org/cgi-bin/mailman/listinfo/dillo-dev

1 0

New/fixed Toolbar icons
by pankso＠slitaz.org April 23, 2014

April 23, 2014

Hi all, Please find attached new pixmaps.slitaz.h + fixed pixmaps.tango.h and the screenshot of SliTaz Toolbar icons. Dillo is the default web browser on SliTaz ARM and SliTaz Raspberry Pi distribution so I wanted a realy fine desktop integration with modern look and feel :-) By the way, congrats for all the work done on Dillo! Best regards, - Christophe Lincoln

1 0

background images
by eocene＠gmx.com April 22, 2014

April 22, 2014

If I go to http://www.dillo.org/dw/html/index.html four of the tabs have a light bluish background color. If I go to some other page and then come back again, those tabs are just white.

2 1

Dillo can render freethoughtblogs.com again!
by onepoint＠starurchin.org April 22, 2014

April 22, 2014

I am very glad to see that freethoughtblogs.com pages no longer crash Dillo. Thanks! Regards, Jeremy Henty

1 0

Segfault with development dillo
by onepoint＠starurchin.org April 14, 2014

April 14, 2014

This URL reliably segfaults Dillo: http://freethoughtblogs.com/butterfliesandwheels/2014/04/where-will-brandei… I suspect this is due to a very recent change as for the past few days Dillo has been crashing a lot, which until then hadn't happened in ages. I haven't investigated further. Dillo (current hg tip), Linux 3.13.9, glibc 2.13, gcc 4.5.2 . Regards, Jeremy Henty

3 4