- Dillo-dev - lists.mailman3.com

[PATCH] Reverse scroll wheel tab switching
by Rodrigo Arias April 5, 2024

April 5, 2024

Hi Alex, We have a mailing list for patches at <dillo-dev(a)mailman3.com>, maybe I should add a comment to the README too. Regarding your patch, I find that behavior unintuitive :-) But we shouldn't expect people to agree on those, so I think this should be implemented as a configuration option. Check the PR of the tab switching[1] to see how to add another option yourself. [1]: https://github.com/dillo-browser/dillo/pull/62/files Otherwise I can work on it after the 3.1.0 release. I opened an issue: https://github.com/dillo-browser/dillo/issues/122 Best, Rodrigo. ----- Forwarded message from Alex ----- Hello, In my opinion the behavior of the mouse wheel tab switching is backwards. Scrolling up switches to the previous tab, and down goes to the next tab. This seems unintuitive and I find myself frequently scrolling in the wrong direction. Sorry I don't have a github account to do a pull request, but here is a diff that reverses the direction: --- uicmd.cc Fri Apr 5 10:59:06 2024 +++ uicmd.cc Fri Apr 5 10:59:21 2024 @@ -255,9 +255,9 @@ int dir = dy ? dy : dx; if (dir > 0) - next_tab(); - else if (dir < 0) prev_tab(); + else if (dir < 0) + next_tab(); ret = 1; } Dillo for life! Alex ----- End forwarded message -----

2 2

Doxygen documentation online
by Rodrigo Arias March 9, 2024

March 9, 2024

Hi, I added the Doxygen documentation in the main website, with the Doxygen Awesome theme: https://dillo-browser.github.io/doxygen/index.html Here is the main overview: https://dillo-browser.github.io/doxygen/dw-overview.html It also includes the documentation of most C functions that was not being included due to "/*" comments instead of "/**" at the beginning of the functions. It is rendered directly from the Dillo git repository weekly, until I figure how to trigger a pipeline in a different repo. It seems Doxygen is injecting some Javascript for the index, but I think there may be a way to avoid it so it can be properly read in Dillo itself. For now I'm leaving it as-is. Best, Rodrigo.

1 0

New mailing list for Dillo
by Rodrigo Arias Jan. 28, 2024

Jan. 28, 2024

Hi all, The people at mailman3.com has agreed on hosting Dillo mailing list free of charge as part of their open-source program (thanks for the pointer Charles), for which I'm very grateful :-) With the help of Andreas, I have put together most of the mailing list archives I could gather from the old server, although there are some posts and attachments missing. The objective of this list is to continue the discussion for the development of Dillo[1] and related topics, in the same way dillo-dev was used before but with moderation to keep a friendly tone. [1]: https://dillo-browser.github.io/ The GitHub platform[2] is used for now to hold the repository, store issues and to run the CI tests, until a more suitable platform is available. [2]: https://github.com/dillo-browser/dillo I hope we can finally made the 3.1 release soon (as in the next month), so distributions can get the new release (after years) in their package repositories. Best regards, Rodrigo.

2 2

patch for dillo and openssl 1.1
by itsme_410＠yahoo.com Sept. 16, 2017

Sept. 16, 2017

Hello, Dillo's https stopped working on F26. It turned out that that was because of the move to openssl v1.1. The kind folks (in particular Matias Ellert) made a patch for F26 which works for both the old version of dillo with openssl v1.0 and v1.1. I am including his patch here in case there is interest in merging this upstream (which is the best place to put it). Best wishes!

1 0

Howto get dillo's new rendering engine
by rashad.kanavath＠c-s.fr Sept. 5, 2017

Sept. 5, 2017

Hello all, I read from Jorge's mail from archive[1] that there is an ongoing work on a new rendering engine in dillo. I would like to checkout this cool feature. How do I access the code ?. I already have dillo master from mercurial[2]. [1] http://lists.dillo.org/pipermail/dillo-dev/ [2] https://hg.dillo.org/dillo

1 0

Access forbidden to the mail-list archives
by rodarima＠gmail.com Sept. 3, 2017

Sept. 3, 2017

Hello, I was trying to access the mail-list archive found here: http://lists.dillo.org/pipermail/dillo-dev/ But I get a 403 response: > Forbidden > You don't have permission to access /pipermail/dillo-dev/ on this server. I can access to the old archives at: https://www.dillo.org/oldmail/ I would like to read previous discussions between 2002 and now. BTW, is there any simple way to open a url in a new tab, on a running dillo instance, from the command line? It would be interesting something like dillo --newtab 'https://www.google.com/' Thanks, Rodrigo.

2 1

any plans to release dillo 3.1 any time soon?
by itsme_410＠yahoo.com July 9, 2017

July 9, 2017

Hello, Are there any plans to release dillo 3.1 any time soon? >From a very grateful user

1 0

Delay loading some sites
by dennisn＠dennisn.mooo.com July 8, 2017

July 8, 2017

On Fri, 7 Jul 2017 13:30:04 -0400, Jorge Arellano Cid wrote: > On Fri, Jul 07, 2017 at 12:36:01PM -0400, Dennis New wrote: > > On Fri, 7 Jul 2017 18:22:43 +0200, Johannes Hofmann wrote: > > > Hm, for me both sites seem to load reasonably fast here, but I > > > just tested it once right now. > > > You could try something like this (with show_msg=YES): > > > > > > dillo http://craigslist.org/ | gawk '{ print strftime("[%Y-%m-%d % > > > H:% M:%S]"), $0 }' > > > > > > Maybe that gives a hint what is taking up time. > > > > It's something in the Nav_open_url process. I don't have this delay > > using other browsers, so I don't think it's a DNS issue. > > > > [2017-07-07 12:30:58] Nav_open_url: new url='http://craigslist.org/' > > [2017-07-07 12:30:58] Dns_server [0]: craigslist.org is > > 208.82.237.129 [2017-07-07 12:30:58] Connecting to 208.82.237.129 > > [2017-07-07 12:30:58] ** ERROR **: [Dpi_read_comm_keys] No such > > file or directory [2017-07-07 12:30:58] Dpi_blocking_start_dpid: > > try 1 [2017-07-07 12:30:58] Nav_open_url: new > > url='http://www.craigslist.org/' [2017-07-07 12:30:58] Dns_server > > [0]: www.craigslist.org is 208.82.237.1 [2017-07-07 12:30:58] > > Connecting to 208.82.237.1 [2017-07-07 12:30:58] Nav_open_url: new > > url='https://www.craigslist.org/' [2017-07-07 12:30:59] > > Nav_open_url: new url='https://geo.craigslist.org/' [2017-07-07 > > 12:32:30] Nav_open_url: new > > url='https://montreal.craigslist.ca' [2017-07-07 12:32:30] Cookies: > > not sent for request by 'geo.craigslist.org' for > > 'montreal.craigslist.ca' > > Well, there's clearly a time taken by dpid to start. Fire a new > dillo, ask for the bookmarks (this will get dpid running), then go to > craigslist.org and see if the delay persists. The delay persists. > If yes, try with another DNS. Other browsers seem to default to > google ones. I tried with only google's 8.8.8.8 DNS server, same thing. I think this could be something else. The delay happens after the Nav_open_url https://geo.craigslist.org line. I noticed that with the links terminal browser, the DNS activity is four pairs of A and AAAA queries: -- dns with links -- 06:36 : query[A] craigslist.org from 10.0.0.1 06:36 : query[AAAA] craigslist.org from 10.0.0.1 06:36 : query[A] www.craigslist.org from 10.0.0.1 06:36 : query[AAAA] www.craigslist.org from 10.0.0.1 06:36 : query[A] geo.craigslist.org from 10.0.0.1 06:36 : query[AAAA] geo.craigslist.org from 10.0.0.1 06:36 : query[A] montreal.craigslist.ca from 10.0.0.1 06:36 : query[AAAA] montreal.craigslist.ca from 10.0.0.1 -- While dillo has an extra www.craigslist.org query, and none of the last three have a corresponding AAAA query: -- dns with dillo 06:46 : query[A] craigslist.org from 10.0.0.1 06:46 : query[AAAA] craigslist.org from 10.0.0.1 06:47 : query[A] www.craigslist.org from 10.0.0.1 06:47 : query[AAAA] www.craigslist.org from 10.0.0.1 06:47 : query[A] www.craigslist.org from 10.0.0.1 06:47 : query[A] geo.craigslist.org from 10.0.0.1 08:18 : query[A] montreal.craigslist.ca from 10.0.0.1 --

1 0

Delay loading some sites
by dennisn＠dennisn.mooo.com July 7, 2017

July 7, 2017

Is anyone else experiencing a long delay (many seconds) before some sites load, like: http://craigslist.org

4 4

Cannot access Dillo mercurial repository
by onepoint＠starurchin.org June 20, 2017

June 20, 2017

Sometime during the past day my access to the Dillo HG repository started failing: $ hg incoming abort: error: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:581) I have not changed my HG configuration at all. I did upgrade my Debian Jessie OS yesterday, but that will not have affected mercurial because I build that from source. I can ssh into my remote hosts as normal, only Dillo HG access has failed. Any ideas? I have no idea how to debug SSL certificate problems. .hg/hgrc (password censored) is: [paths] default = https://jhenty:xxxxxxxxxxx at hg.dillo.org/dillo Regards, Jeremy Henty

4 6

Where to get dillo-3.1 dev?
by itsme_410＠yahoo.com May 6, 2017

May 6, 2017

Hello, I have been trying to find out where to get this from, and having been unsuccessful so far? Where do I get this from? Is there a plan for an actual release in he near future? Thanks!

3 6

unable to read from website
by itsme_410＠yahoo.com April 28, 2017

April 28, 2017

Hi, I posted this some time ago but did not get any reply. I am using dillo-3.0.5 on a fully up-to-date Fedora 25 installation. I used to be able to access the website at The Telegraph - Calcutta but no longer. Nothing happens when I type the UR. This problem has been oing on for the past several months. Here is what I get by way of messages on the terminal: $ dillo paths: Cannot open file '/home/trotter/.dillo/keysrc': No such file or directory paths: Using /etc/dillo/keysrc paths: Cannot open file '/home/trotter/.dillo/domainrc': No such file or directory paths: Using /etc/dillo/domainrc Domain: Default accept. dillo_dns_init: Here we go! (threaded) Enabling cookies as from cookiesrc... Nav_open_url: new url='about:splash' a_Dicache_cleanup: length = 0 Nav_open_url: new url='http://www.telegraphindia.com' Dns_server [0]: www.telegraphindia.com is 104.24.122.141 104.24.123.141 2400:cb00:2048:1::6818:7a8d 2400:cb00:2048:1::6818:7b8d Connecting to 104.24.122.141 HTTP warning: Message with a body lacked Content-Type header. Nav_open_url: new url='https://www.telegraphindia.com/' How do I resolve this? Many thanks! | | | | | | | | | | | The Telegraph - Calcutta The Telegraph on the Web: Daily international, national international news, daily newspaper, national, politics,... | | | |

2 3

Changes at hg.dillo.org - now I cannot access the repository
by onepoint＠starurchin.org March 22, 2017

March 22, 2017

I noticed that my connections to hg.dillo.org were timing out. I discovered that the IP address had changed and so my firewall was dropping the packets. So I updated my firewall to fix that, and now my connections are immediately rejected. For instance, if I try "hg incoming" it immediately responds "abort: error: Connection refused" and exits with status 255 (which I take to mean that something serious went wrong). So what to do to fix this? Adding a "--verbose" flag to the "hg incoming" command did not change the output. Maybe the port 39390 which is specified in my repository's hgrc file is no longer correct, but I do not know how to test that. Any ideas? Regards, Jeremy Henty

3 3

dillo dev with https
by andreas＠kemnade.info Feb. 4, 2017

Feb. 4, 2017

Hi, On Sat, 4 Feb 2017 12:20:07 +0000 Adam Mendoza <adammendoza at hotmail.com> wrote: > Can someone do a quick Skype or similar to get a build set-up with > https? I want to be a contributor. > well, its just es usual, there are libpng, libjpeg, libfltk-1.3 and libmbedtls as dependencies. You have to install their development headers. Hint for debian jessie: libmbedtls-dev is in jessie-backports. And then the usual autogen.sh, configure --enable-ssl, make, make install Regards, Andreas Kemnade

1 0

Any plans for a release in the next few weeks?
by abe＠deuxchevaux.org Dec. 7, 2016

Dec. 7, 2016

Dear Dillo Developers, since the freeze for the next Debian Stable release is quite close, I wonder if there are any plans for a new Dillo release in the next few weeks. If so, I'd be happy if that release (epsecially if there will be a 3.0.6) would happen before christmas to be able to get it into the next Debian Stable release. (I currently assume that 3.1 won't be ready before christmas, but feel free to surprise me. ;-) The freeze for new upstream versions is on 5th of January 2017 and to be included, new upstream releases must have migrated from Debian Unstable to Debian Testing before that date. Given the 10 days migration period, the last chance for an upload would be on 2016-12-24, preferable earlier so that there's a chance to fix potential issues like unexpected build failures, etc. in time. P.S.: Releasing the next Debian Stable with a well-working 3.0.5 isn't bad either. Just wanting to let you know about these freeze deadlines. 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://abe.noone.org/ (Web)

2 2

Cannot log into github
by singpolyma＠singpolyma.net Nov. 2, 2016

Nov. 2, 2016

Can others log into Github with Dillo tip? I just built and installed and while I no longer see errors about cookie date formats with tip like I did with the version I had installed, it still does not log me in. I am using two factor auth with Github, in case that make a difference compared to anyone else's experience. Thanks for any help :) -- Stephen Paul Weber, @singpolyma See <http://singpolyma.net> for how I prefer to be contacted edition right joseph

2 1

Page sneds Dillo into a (lock up] loop
by nick＠linicks.net Oct. 30, 2016

Oct. 30, 2016

Hi all, Chin-up people :) Believe it or not, I was looking into HTML5 font size stuff, and found Dillo seemed to crash on the page below. Running raw from a terminal that is not the case - it gets it's knickers in a twist in a permanent loop of: ... Layout::resizeIdle calls = 2536 Layout::resizeIdle calls = 2537 Layout::resizeIdle calls = 2538 Layout::resizeIdle calls = 2539 Layout::resizeIdle calls = 2540 Layout::resizeIdle calls = 2541 Layout::resizeIdle calls = 2542 Layout::resizeIdle calls = 2543 Layout::resizeIdle calls = 2544 Layout::resizeIdle calls = 2545 Layout::resizeIdle calls = 2546 Layout::resizeIdle calls = 2547 Layout::resizeIdle calls = 2548 Layout::resizeIdle calls = 2549 etc. The link (BEWARE!): http://www.w3schools.com/cssref/pr_font_font-size.asp Nick -- "Gosh that takes me back... or is it forward? That's the trouble with time travel, you never can tell." -- Doctor Who "Androids of Tara"

1 0

Gmail textareas
by james.from.wellington＠gmail.com Oct. 24, 2016

Oct. 24, 2016

Hello all, I have a work-around, so this isn't urgent. In view of recent events, keep caring for yourselves. Gmail sizes some text areas weirdly, as (CSS) width:80ex, and they disappear from view. I've tried two fonts, and the disappearance is complete in both cases. A cut down example is attached. The diff to suppress the disappearance is: --- gmail-compose-14.html 2016-10-21 21:06:01.000000000 +1300 +++ gmail-compose-15.html 2016-10-21 21:10:41.000000000 +1300 @@ -18,7 +18,10 @@ .th a:link, .th a:active, .th a:visited{text-decoration:none} .bn td{border:1px solid #FAD163} .ct textarea, .ct input, .ct select{font-family:arial,sans-serif;font-size:100%} + .compose .mi{width:80ex;font-family:arial,sans-serif;font-size:100%} +.compose .mi{width:100%;font-family:arial,sans-serif;font-size:100%} + .compose .i, .search .i{width:99%;font-family:arial,sans-serif;font-size:100%} .qr textarea{width:80ex;font-family:arial,sans-serif;font-size:100%} .qr input{font-family:arial,sans-serif;font-size:100%} The immensely crude work-around is the following, as a .gdbinit: ---------------- break 'StyleEngine::setClass' break main commands 2 cond 1 (0 == (int)strcmp(klass, "mi")) cont end commands 1 set klass = "i" cont end run ---------------- I'm open to hints about where to look for the effect of width on multiline text resources, but really I'm lost. Regards, James.

1 1

Sad news
by jcid＠dillo.org Oct. 21, 2016

Oct. 21, 2016

Hi, I'd like to inform our users and contributors, that we're mourning the loss of a friend, and core dillo developer. He was with us along the road for 16 years or so. A brilliant, and dedicated person, sharing his talents with us, the main architect of Dillo widgets, a reserved person with altruism and a ludic sense of humor. He will be missed as a person, friend, and fellow developer. Sebastian passed away in late September this year, Fare thy well, in your future endeavours outside this realm! -- Jorge.-

5 4

dillo development
by jcid＠dillo.org Sept. 28, 2016

Sept. 28, 2016

Hi there, Please expect very good news in the next months... (there's very nice code developing in the labs now). Just that, stay tuned. -- Cheers Jorge.-

2 1

Site doesn't render - just HTML code
by nick＠linicks.net Sept. 21, 2016

Sept. 21, 2016

Only me again :) Firefox, links and lynx render this page OK, but Dillo just shows the HTML code: http://www.afrowsoft.co.uk ? Nick -- Gosh that takes me back... or is it forward? That's the trouble with time travel, you never can tell." -- Doctor Who "Androids of Tara"

2 2

Startup time of the latest dev versions.
by johnfound＠asm32.info Sept. 19, 2016

Sept. 19, 2016

I am using Dillo as a help viewer of my IDE, because it has really short startup times and pressing F1 I get instant access to the documentation. Recently I tried to compile and use the recent development versions from the hg repository, because of the recent changes in the rendering and the general improvements in the browser. But unfortunately, the startup time seems to be increased and now I have to wait 2..3 seconds for browser to start and to show my help files. Is such slow startup time side effect of some changes that will be fixed some day, or it is kind of compromise, because of other improvements and this way will persists in the project from now on? Or (what is pretty possible) I messed something with the compilation? -- http://fresh.flatassembler.net http://asm32.info John Found <johnfound at asm32.info>

5 9

Entry in cookiesrc locks Dillo up
by nick＠linicks.net Sept. 16, 2016

Sept. 16, 2016

Hi All, I frequent a Slackware Pi forum, and decided to get Dillo to remember my log-in details with cookies. The URL is (in my bookmarks file): http://forum.fatdog.eu/viewforum.php?f=30 If I add: forum.fatdog.eu ACCEPT in my cookiesrc file, then start Dillo, click on the above said link in bookmarks, Dillo locks up and the only way out is to kill it from the command line. Any ideas on this? Or am I being stupid? Nick -- Gosh that takes me back... or is it forward? That's the trouble with time travel, you never can tell." -- Doctor Who "Androids of Tara"

1 2

Get Dillo to honour target=_blank
by nick＠linicks.net Aug. 29, 2016

Aug. 29, 2016

Hi all, How easy (or hard) would it be to get Dillo to honour the URL/FORM directive 'target="_blank" to get URL/CGI data returned in a new tab? I ahve looked at the code, seeing as Dillo already has tabs, but I just don't get C++ classes and stuff, and wouldn't know where to begin. The reason for asking this is if one has a form with a lot of data that needs processing, once submitted the data gets returned to the parent page... if there is a mistake, then you need to go back to the form, and as Dillo doesn't keep the previous page data, you have to fill it all in again. By diverting the output to a new tab, the previous parent window remains the same, ready for editing and processing again. Thanks, Nick -- Gosh that takes me back... or is it forward? That's the trouble with time travel, you never can tell." -- Doctor Who "Androids of Tara"

3 6

Underscores not drawn in pre with background color
by Hole.destructor＠gmx.de Aug. 17, 2016

Aug. 17, 2016

Hi Dillo developers, I stumbled upon a page with a lot of code snippets wrapped in a <pre> block, where Dillo seems to have a rendering problem: Underscores `_' are not drawn. I stripped down this real-world-example to the attached minimal html file which reproduces the problem: The page should render as follows: ============================================ softpoint_with_block() { { echo ""; } | ./softpoint.x leshouches } ============================================ However, in the development version of Dillo it renders as follows: ============================================ softpoint with block() { { echo ""; } | ./softpoint.x leshouches } ============================================ As you can see, the underscores in the function softpoint_with_block() are not drawn in Dillo. However, the underscores are drawn correcty if you * remove the style="..." specification from the <pre> block or * remove the line { echo ""; } | ./softpoint.x leshouches from the <pre> block content. Best regards, Alex

4 14

Underscores not drawn in pre with background color
by michael.baeuerle＠stz-e.de Aug. 15, 2016

Aug. 15, 2016

Nick Warne wrote: > On Sat, 23 Jul 2016 11:25:18 +0100 Nick Warne <nick at linicks.net> wrote: > > On Sat, 23 Jul 2016 11:13:19 +0100 Nick Warne <nick at linicks.net> wrote: > > > On Sat, 23 Jul 2016 10:01:59 +0100 Nick Warne <nick at linicks.net> wrote: > > > > On Fri, 22 Jul 2016 20:12:59 +0300 John Found <johnfound at asm32.info> wrote: > > > > > > > > > > Confirmed. I am using "Liberation Mono", but with "DejaVu Sans > > > > > Mono" have the same problem. It is probably because of the > > > > > characters height - the next row of text overwrites the > > > > > previous. The question is whether this is because of Dillo or > > > > > because of FLTK. > > > > > > > > > > The same font, used in Firefox renders correctly. > > > > > > > > This looks like a bug in the font: > > > > > > > > http://dejavu-fonts.org/wiki/Bugs/Archived > > > > > > > > (you need to scroll down a bit). > > > > > > > > I have version 2.34 installed - will see if I can reproduce it > > > > later. > > > > > > OK, I get the same issue. But if you change the font size, thus: > > > > > > <pre style="background-color: white; > > > font-size:105%;">softpoint_with_block() { > > > > > > the underscores are visible. > > > > Huh! Strangely the underscores become visible with font size set to > > 95% too! Only 100% renders them invisible? > > OK, turning off 'use embedded CSS' makes them visible too. > > CSS parsing error? Please check whether the problem is related to this FLTK STR I created some days ago: <http://www.fltk.org/str.php?L3321>

2 1

Good news in dillo's rendering!
by jcid＠dillo.org Aug. 4, 2016

Aug. 4, 2016

Hi there, Here go some good news. Originally I was to send this internally to the core devs, but as we've benefitted from the feedback of active users in the list, and their experiences with the patches (before/afterwards), on the sites they usually browse, it looks like a good idea to do it again. Since June 6, when this thread [1] was started by Sebastian, I've been investigating/working in problems related to it. This led to some extensive rendering tests that catched a laundry list of problems with our current tip (#4643 today). This is a list with brief explanations, taken from the testing data tables I've gathered so far: Problems: 1: overwrites text with images. 2: crops images (aspect ratio). 3: different layout. 4: overwrites text with text float. 5: overwrites text with text. 6: CPU HOG with: tmp.num.html, tmp.num.small.html 7: Missing page sections (sometimes works for the same page). 8: Small images cut in two sometimes ("ESP", "CRO", ...) 9: Wrong aspect ratio for images (text line height) 10: Page drawn with offset (but browser thinks other section is on screen). There're test cases for each one, and most of them were taken and reduced from real pages. Having reduced test cases is good, reduced and isolated tests is better, but the good news is that I have a couple of patches that solve all of them! I'm not saying dillo will be error-free hereafter, but that the root of a whole family of problems has been found and fixed, and this will make future testing much simpler. GROWS2 is the "Grand Redesign Of Widget Sizes" v2 by Sebastian. This is a very powerful and flexible concept whose design allows floats, layers (and absolutes in the future, and more). It has proven very fast so far, even without optimizations. Well the patches are two simple but deep changes in the way markSizeChange() and queueResize() interact. The patch idea is close to graph coverage recursions (with pruning), applied to the widget tree. I'd like to commit it, upload the test suite I'm using, and show the testing data tables I've gathered so everyone can check it with their use cases and report on it. @Sebastian: May I, or would you prefer to review them before? (the patches are the "middle ground" you mentioned. Solve the dw hog problems at dw level, not in the parser, and reuse code you've already seen. A couple of days should be enough to review) @Sebastian: Problem #10 is not related to GROWS2, but a three year old bug discovered during the tests. So let's get it done first. How to reproduce it: Go to [2], wait a bit for most images to load, then use "find text" to find the "re-re" string, scroll a bit downwards to find the image and center it. Go back then forward; no image! But dillo thinks it *is* there so move the cursor to the center of the page and you'll see the hand cursor, wait for the tooltip and drag it a bit downwards to the right. Dillo will repaint from the image data. Bisect shows the bug was introduced by #2863. Attached is a simple concept patch for it. Please review/fix/commit, as I don't know the updated invariants of resize idle. [1] http://lists.dillo.org/pipermail/dillo-dev/2016-June/010887.html [2] http://tinyurl.com/huvf6pn -- Cheers Jorge.-

2 4

Successful build on OS X
by gears_of_war__＠hotmail.com Aug. 4, 2016

Aug. 4, 2016

Dillo builds an runs on mac os x 10.5.8 (ppc32) with fltk-1.3.3. It runs great!

1 0

ImageMagick for SVG and other image types?
by jgaffney＠lawrenceville.org July 20, 2016

July 20, 2016

At this point Dillo supports the display of GIF, PNG, and JPG, but SVG is used heavily by sites like, for example, Wikipedia. Has the Magick++ library in ImageMagick been considered for supporting these other image formats? The FLTK people seem enthusiastic about the Imago library in spite of its alpha state of development; librsvg, which looks, at least to my untutored eye, like it requires a fair amount of voodoo to use, is apparently no longer actively supported and would at any rate only provide SVG support; but ImageMagick is pretty standard with Linux distributions, and the Magick++ interface makes conversions from any format to PNG for the purposes of display extremely easy. In src/misc.c, at the end of the image part of the else-if ladder in a_Misc_get_content_type_from_data(), one could add another "rung" that uses Data and Size to create a Magick::Blob, and from this a Magick::Image, then use Magick::Image.write() to write this to another Magick::Blob of type PNG, and then replace Data and Size with those of the resulting Magick::Blob. A try-catch block would catch the cases where Data is not an image. Altogether this sort of "cheat" would require very few lines of code to implement. And the Magick++-config utility could supply the needed -D..., -I..., -l... flags to the configure script. I'm not suggesting this is an ideal long-term solution, but in the interim would at least allow the display of other image types. The most recent mention of this on the mailing list seems to be Jorge's indication on 22 April 2016 that No, there's no SVG image support in dillo yet. It should not be hard to implement though, but it needs an effort similar to GIF or PNG or JPEG code. Patch welcomed! ;) But surely someone has thought of ImageMagick before. Are there objections to using it? And if so, maybe a flag could be set by the configure script to conditionally compile this in for those who want it? (If this is pursued, the configure script should probably also check that the version of ImageMagick is recent enough to have been patched against that serious exploit in just this sort of conversion code.) A test program shows that the invocation of ImageMagick and conversions really are as simple as the steps outlined above. But I would be happy to make an attempt at a patch, if you don't mind this being undertaken by an amateur.

1 1

cppcheck on Dillo source
by nick＠linicks.net July 17, 2016

July 17, 2016

Hi all, While waiting for the Tour De France to start on TV, I ran cppcheck on Dillo source for something to do - a few errors were picked up! I have compacted the findings (with two comments from me)and attached it as a plain text file. Keep up the great work guys and thanks! Nick -- Gosh that takes me back... or is it forward? That's the trouble with time travel, you never can tell." -- Doctor Who "Androids of Tara"

3 6

Problem related to generated content
by sgeerken＠dillo.org July 10, 2016

July 10, 2016

Hi! I've come upon an interesting problem. Consider this HTML (stripped down from a real world example): <head> <style> .fc:after { content: ""; display: block; clear: both; } </style> </head> <body> <div class="fc"> <div style="float: left">main</div> </div> <div style="background:#404040; color:#ffffff">footer</div> </body> Firefox (and probably other browsers) renders black text "main" on white background above white text "footer" on dark gray background. Dillo 3.0.5 does the same, for the simple reason that it does not support floats. Dillo 3.1-dev, however, renders black text "main" and white text "footer" side by side on dark gray background, because "main" is within a float. (Which is, of course, difficult to read.) The reason why Firefox renders this as it does: the definition within <style> generates something like a block element before the text containing "footer", with "clear: both" as CSS attributes; something like: <body> <div class="fc"> <div style="float: left">main</div> </div> <div style="clear:both"></div> <div style="background:#404040; color:#ffffff">footer</div> </body> Aside from the fact that dillo has still problems with this ("footer" is too much to the right; I'll investigate this independently), this shows that dillo's limited capabilities regarding generated content, together with floats, causes some unpleasing rendering errors, which are furthermore laborious to analyse (and thus not so simple to be ignored). Has someone a feasible idea to deal with this? Sebastian

1 1

URL field / Loading page images / Refreshing DNS cache
by jgaffney＠lawrenceville.org July 9, 2016

July 9, 2016

First, a huge thanks to all the Dillo team for their efforts: I just switched from 3.0.5 to the current snapshot to try out the mbedtls changes, and I am wowed not only by this, but by all the improvements in rendering, etc. Great work! A few suggestions, all very minor, that might be added to the back of the development queue: In the current snapshot, the navigation bar has changed, and the URL field does not seem to be taking into account font_factor -- with the result that the window is smaller than the font height. You can test this by setting, e.g., font_factor=2.0 in your dillorc (most dramatically for a tiny panel with small icons). The issue seems to be with this factor not being taken into account when bh and lh are set in make_panel() in ui.cc. As far as I can see, one can use the context menu to download individual images on a page, or use the panel to toggle image loading. But if one wants not to download images in general, but to download all the images for some one page (e.g., a weather forecast page), then one has to toggle downloading of images on and then off again. Maybe a command could be added to KeysCommand_t in keys.hh, bound by default to something like Ctrl-i in keys.cc, with a corresponding call to a_Html_load_images() in handle() in ui.cc? To make the switch to the current snapshot, I had, sadly, to terminate an instance of 3.0.5 that had been running continuously for 90 days without any issues. But to get that much up time it was necessary to add a little code so that SIGUSR1 would call a_Dns_freeall() and a_Dns_init(), otherwise (unless I am missing something) Dillo will persist in using the cached lookup indefinitely and not detect when the IP address has changed. So maybe some sort of key binding could be added that would flush the cache when needed? Thanks again for all your hard work!

4 5

patches #4634 and #4635
by jcid＠dillo.org July 9, 2016

July 9, 2016

Hi corvid, Some comments: ----------------- Patch #4635: rm IO flags, as they are never used Yes, those linger from a time when shutdown() was used for handling sockets in dillo. Not necessary now since we use read() write() close(). ------------------ Patch #4634: freeing http socket, close FD that's being connected Why did you do this? (i.e. Is there a specific bug?). Beware the FD is closed inside IO.c (OpEnd|OpAbort). If you close it in Http_socket_free(), you are opening race conditions on file descriptors, and coding outside the design. Http_socket_free() is used with the CCC chains, that's why it doesn't close the FD, IO will do it by means of CCC; avoiding race conditions. I haven't tested the code yet, but I'd be amazed if resources don't stop to load at random. For instance, Http_socket_reuse(int Skey) would be activating and reporting success on a socket that's just been closed. Please review all the related patches and be more careful before committing. PD: IIRC I used lsof to check for FD leaks long ago. -- Cheers Jorge.-

1 0

an experiment using mbed TLS
by eocene＠gmx.com July 8, 2016

July 8, 2016

I wanted to see what it would take to use mbed tls with dillo. I put a copy of the diff at http://www.dillo.org/test/mbedtls.diff and I mention it here in case someone should want that one day. That said, it looks like netsurf uses curl, and curl can use any tls library you care to mention. And I'm pretty sure netsurf does javascript.

5 17

URL field / Loading page images / Refreshing DNS cache
by jgaffney＠lawrenceville.org July 8, 2016

July 8, 2016

Jorge Arellano Cid <jcid at dillo.org> writes: [...] >> As far as I can see, one can use the context menu to download >> individual images on a page, or use the panel to toggle image >> loading. But if one wants not to download images in general, but to >> download all the images for some one page (e.g., a weather forecast >> page), then one has to toggle downloading of images on and then off >> again. Maybe a command could be added to KeysCommand_t in keys.hh, >> bound by default to something like Ctrl-i in keys.cc, with a >> corresponding call to a_Html_load_images() in handle() in ui.cc? > > This is interesting. > >> To make the switch to the current snapshot, I had, sadly, to terminate >> an instance of 3.0.5 that had been running continuously for 90 days >> without any issues. > > Wow, it's good to know it can last that long. > > What you describe here is very interesting, in a way I've > come to suspect most users don't have the slightest clue. > > I mean, everyone of us (as dillo users) have *different* use cases. > There's no way we can guess what other people are doing outside of > our awareness realm. > > Now, you're not only a casual user, but one that uses dillo *a lot*, > and appreciate it as an everyday tool. > > That being stated, we are very interested in knowing your use case, > and all the details of it. There's potentially a lot we can learn from it, > and also improve yours/and-the-generic user experience as a result of > this learning. > > So please elaborate on why you like to have it running for that long time, > what do you do with it, how you do it, what problem does it solve that other > tools don't, why is it your choice. What you'd wish it had. I had been using Firefox (and still do, for trusted sites that require javascript), but looked around for another browser when the option to turn off javascript was removed from the preferences dialog -- when javascript is so often the vulnerability behind exploits, I didn't want a browser hoisting in javascript from all over the Internet at its own discretion. (It is still possible to turn javascript off in Firefox if one starts from a script that invokes a prefs.js with a legacy `user_pref("javascript.enabled", false);', or from the internal about:config page, but:) Dillo was one of the few browsers without javascript, and when I checked it out, I found that I agreed very much with Dillo's stated philosophy. And it has been my principal browser ever since. In fact, along with an xterm and Emacs, it's one of the three apps always running on my machine. Things I like about Dillo: Dillo doesn't even include javascript. (I cringe a bit when there is talk on the list about the possibility of including it -- if it is included at some point, I hope that there will be a #define to exclude that code at compile time.) Dillo is small and fast, which is nice not only for general browsing, but when invoking it through, e.g., Emacs to open a link. Dillo let's me configure things the way I like, and when it doesn't do something I want, the code base is accessible enough that I can modify it to do so. (I had in fact already implemented the suggestions I made, but didn't share any patches because, even beyond being an amateur, my hacks tend to be on the ugly side -- the loading of images per page, for example, required adding #include "html.hh" to ui.cc, indicating that I am certainly violating some logic of organization and encapsulation.) Dillo isn't phoning home or doing anything else behind my back, and it let's me easily block ad and other such sites in domainrc. Dillo doesn't try to do all sorts of exotic things, or invoke external apps to do them, with all of the potential security risks. With other browsers, you have to do a lot of work to try to prevent this sort of automagical behavior, and even if it's possible, you aren't left feeling at all confident about having prevented it. Like you, I like that Dillo caches DNS lookups, but of course IP addresses change from time to time for legitimate reasons, so there does need to be a way to flush the cache. Johannes's patch is a good one, but I also still like the idea of using the cache until I need it to refresh. Of course, one could simply start a new instance of Dillo, but I also like that it caches pages in a way that allows me to open a link to a previously visited page off-line, without trying to reconnect and reload it. And -- possibly a unique personal idiosyncrasy -- I like to see links I have visited displayed as visited. Other than that, there really isn't any reason not to be firing up a fresh instance of Dillo whenever it is needed. And probably a lot of other virtues in Dillo that just aren't coming to mind right now. > Some things may be possible, others not, a few may be solved in different > ways, etc. Just learning about those key tasks, or improving a single one, > would be a big gain for all of us. > > Your feedback as a dillo power-user is not only welcomed, it's asked for! > > >> Thanks again for all your hard work! > > Ack! > > > @all: if you're a dillo power-user, let us know about it!

1 0

CSS files downloaded only after reloading page
by Hole.destructor＠gmx.de July 8, 2016

July 8, 2016

Hi Dillo developers, the dillo version from the repository seems to have problems downloading some CSS files the first time some pages are loaded. Though, the remaining CSS files are downloaded when the page is re-loaded using CTRL-r. Example page: https://netzpolitik.org/ Reproduce: 1) dillo https://netzpolitik.org/ -> styles from some CSS files seem to be missing 2) press CTRL-r -> some new CSS file is downloaded and styles are applied 3) press CTRL-r -> some new CSS file is downloaded and styles are applied Best regards, Alex

3 2

URL field / Loading page images / Refreshing DNS cache
by jgaffney＠lawrenceville.org July 8, 2016

July 8, 2016

Johannes Hofmann <johannes.hofmann at gmx.de> writes: [...] >> > To make the switch to the current snapshot, I had, sadly, to terminate >> > an instance of 3.0.5 that had been running continuously for 90 days >> > without any issues. But to get that much up time it was necessary to >> > add a little code so that SIGUSR1 would call a_Dns_freeall() and >> > a_Dns_init(), otherwise (unless I am missing something) Dillo will >> > persist in using the cached lookup indefinitely and not detect when >> > the IP address has changed. So maybe some sort of key binding could >> > be added that would flush the cache when needed? >> >> good point. However I'd like to avoid another key-binding and rather >> do the right thing automatically. >> I could think of a general DNS entry timeout of a couple of seconds. >> In many cases DNS responses are cached at OS-level too respecting >> lifetime values given by the server. > > Firefox has an option to configure the DNS cache expiration > (network.dnsCacheExpiration). > Attached patch implements a similar feature for Dillo. > > Cheers, > Johannes That was fast! Thanks for this; I will try it out.

1 0

URL field / Loading page images / Refreshing DNS cache: Correction
by jgaffney＠lawrenceville.org July 8, 2016

July 8, 2016

Jorge Arellano Cid <jcid at dillo.org> writes: > Hi John, > > On Thu, Jul 07, 2016 at 05:16:04PM -0400, John Gaffney wrote: >> [...] >> > In the current snapshot, the navigation bar has changed, and the URL >> > field does not seem to be taking into account font_factor -- with the >> > result that the window is smaller than the font height. You can test >> > this by setting, e.g., font_factor=2.0 in your dillorc (most >> > dramatically for a tiny panel with small icons). The issue seems to >> > be with this factor not being taken into account when bh and lh are >> > set in make_panel() in ui.cc. >> [...] >> >> I meant what is actually called the "location box," and on comparing >> the code for 3.0.5 to the snapshot of a few days ago, I see that there >> has been no change in the section of make_panel() in ui.cc that sets >> the values of bh, lh, etc. The change that has caused the problem is >> the addition of line 466 of ui.cc: >> >> i->textsize((int) rint(14.0 * prefs.font_factor)); >> >> But the height of the CustInput i is still set to lh, which does not >> take into account prefs.font_factor. > > Yes man. > > That was a quick patch (#4222 in Hg) for a larger font. > > I'll look at it after I finish a general rendering algorithm bug > I'm working in. > > Please be patient. > > BTW, do you really need a font size that enlarges the location box? or > would it be enough to clamp the font size to fit in? The second case is > a much simpler patch. No rush! I was just pointing out the issue; for myself, just commenting out the above line works just fine by reverting to the old behavior and smaller font size in the location bar.

1 0

URL field / Loading page images / Refreshing DNS cache: Correction
by jgaffney＠lawrenceville.org July 8, 2016

July 8, 2016

[...] > In the current snapshot, the navigation bar has changed, and the URL > field does not seem to be taking into account font_factor -- with the > result that the window is smaller than the font height. You can test > this by setting, e.g., font_factor=2.0 in your dillorc (most > dramatically for a tiny panel with small icons). The issue seems to > be with this factor not being taken into account when bh and lh are > set in make_panel() in ui.cc. [...] I meant what is actually called the "location box," and on comparing the code for 3.0.5 to the snapshot of a few days ago, I see that there has been no change in the section of make_panel() in ui.cc that sets the values of bh, lh, etc. The change that has caused the problem is the addition of line 466 of ui.cc: i->textsize((int) rint(14.0 * prefs.font_factor)); But the height of the CustInput i is still set to lh, which does not take into account prefs.font_factor.

3 2

CSS parser bug
by sgeerken＠dillo.org July 5, 2016

July 5, 2016

Hi! The CSS parser seems to have a bug handling shorthand properties. This example works well, both properties are handled correctly: <body style="background: url(http://www.gnu.org/graphics/heckert_gnu.small.png) repeat-y"> Adding "transparent" (for "background-color"), however, causes the other parts not to be parsed: <body style="background: transparent url(http://www.gnu.org/graphics/heckert_gnu.small.png) repeat-y"> Not a regression, dillo 3.0.5 shows the same behaviour. Sebastian

2 2

trustworthiness of dillo's TLS code at present
by eocene＠gmx.com July 4, 2016

July 4, 2016

Currently I'd trust dillo for https about as much as I'd trust wget for https. (Not that I've really examined wget, but just as a sort of gauge here...) Back in the DPI days, dillo didn't check hostnames on certificates because that was an impossible nightmare with openssl unless you found the code somewhere to modify for your own project. [By the way, there was outrage a couple of years ago when people realized that lots and lots of tools out there, and tls libraries for popular languages, were using OpenSSL and not doing any hostname validation.] It was only with 3.0.5 that I had looked into TLS myself and learned enough about what's insecure at present to disable old ciphers, disable ssl3, disable tls compression. When TLS moved into the browser with the OpenSSL version, I integrated hostname checking code adapted from wget source. And now mbed TLS does the checking itself. At present, our weakness relative to something like chrome or firefox would be in the area of certificate revocation. Dillo has never had a way to know when a certificate has been revoked. For a while, there were certificate revocation lists (CRLs) that are generally published by the assorted certificate authorities, although sometimes you have to click on agreements to get them. The other problem is that those grow _huge_, and distributions don't generally have packages for them (unlike ca-certificates for root certificates). I wouldn't be surprised if the agreements bar distribution. And there was OCSP, which stands for.... Online Certificate Status Protocol. Every time you get a certificate, you query some server, often a third-party server, and ask it whether this certificate is still valid. But those OCSP servers were/are nowhere near reliable enough, and browsers couldn't very well fail everything when the OCSP servers were being flaky.. So OCSP stapling has been coming along, where the OCSP data comes from the original server along with the certificate. OpenSSL has had OCSP code for a little while, but it's very buggy and not documented, and maybe you could get it to work if your application is exceedingly similar to the sample client, but good luck. mbed TLS has OCSP on their roadmap, but it's not implemented yet. As for what the firefoxes and chromes of the world are up to, firefox ripped out their CRL code a while back and they have some other mechanism where certificate authorities notify them of revocations and they push it out. Because they're still big enough to get certificate authorities to do things for them. And they have 'public key pinning' where a server sends keys to certificates, and the client checks that, when certificates are presented in the future, they continue to use one or more of those keys. My understanding is that this is not at all widely used currently. Like if you go to google while claiming that you're chrome, maybe.

1 0

valgrind errors
by eocene＠gmx.com June 26, 2016

June 26, 2016

Was just having a look at the valgrind errors, and I think the main one is in textblock.cc: int leftBorder = boxOffsetX () + leftInnerPadding + (lines->size () == 0 ? line1OffsetEff : 0); leftBorder being set to line1OffsetEff when line1OffsetEff has not been initialized.

2 4

Error message when starting 3.1-dev from xterm
by waltdnes＠waltdnes.org June 26, 2016

June 26, 2016

Wnen starting up from an xterm, and then exiting, I get the following. ** ERROR **: prefsparser: Syntax error in dillorc: name="(null)" value="(null)" Domain: Default accept. dillo_dns_init: Here we go! (threaded) Disabling cookies. Dillo: normal exit! I moved my custom dillorc, and copied the generic one, i.e. /usr/local/dillo/etc/dillo/dillorc to check that it wasn't something I did. It still gets the same error. -- Walter Dnes <waltdnes at waltdnes.org>

3 4

Patch: Zero detected HTML errors
by nick＠linicks.net June 25, 2016

June 25, 2016

Hi Devs, The sentence (Dillo message): Zero detected HTML errors! Is a bit contrived in English - this small patch (attached) changes it to more legal/legible English usage. Regards, Nick -- Gosh that takes me back... or is it forward? That's the trouble with time travel, you never can tell." -- Doctor Who "Androids of Tara"

2 6

New design of tag nesting cleanup within the parser.
by jcid＠dillo.org June 24, 2016

June 24, 2016

Hi there, This is an important patchset that's just been committed. There're plenty of details in the hg comments (hg log -v). This are changes that affect the way dillo copes with Tag Soup (i.e. bad formed HTML). The idea is to create a valid doc tree before passing it to Dw for rendering, so yes, rendering may change. Please check the comments, then browse your regular sites and give it a test drive, then send some feedback. At least in my case there were nice surprises! -- Cheers Jorge.-

5 18

Strange performance behaviour related to <span>
by sgeerken＠dillo.org June 20, 2016

June 20, 2016

Hi! I've stripped down one testcase to a sequence of simple HTML snippets. Try (for i in $(seq 1 20); do echo '<div style="float:left"><div></div><div style="display:table"><span></div></div>'; done) > tmp.html; dillo tmp.html and the development version of dillo hangs for a while. You may vary the number (second argument of seq). If you look at the file tmp.html, you'll notice that it is incorrect HTML. Interrestinly, leaving the <span> away still results in incorrect and deeply nested HTML, but dillo is much faster: (for i in $(seq 1 20); do echo '<div style="float:left"><div></div><div style="display:table"></div></div>'; done) > tmp.html; dillo tmp.html Dillo 3.0.5 is fast in both cases. Does anyone have an idea what effect the <span> has? I've already run gprof, but the result does not look very meaningful at a first glance. Sebastian

2 6

ComplexButtonResource initial size
by jcid＠dillo.org June 18, 2016

June 18, 2016

Hi Sebastian, While testing the design corrections of the parser's nesting handling, I noticed ComplexButtonResource takes full width as initial size. e.g. A<button></button> I didn't find where to set its initial size. Would you mind giving it a look? -- Cheers Jorge.-

2 1

Bug report - enterpress_forces_submit; mouse cursor wonky
by nick＠linicks.net June 8, 2016

June 8, 2016

Hi all, Hard one to explain. First some info; I am running: Slackware 14.1 Xfce4 4.10.0 Latest stable kernel 3.18.35 (updated today) Now, I have a word search/dictionary page with several fields, and for some reason Dillo needs to use the mouse to 'process' the submit form - I haven't investigated what can be wrong with my HTML to make Dillo just use 'enter' to 'submit' yet. I added dillorc option enterpress_forces_submit=YES and now the page 'submit' works with the enter key. But when doing so, sometimes the mouse cursor disappears altogether afterwards (but it is still there as in the WM toolbar it appears again) You can see the Dillo toolbar icons depress but no mouse. Sometimes the mouse cursor changes to a 'I' and stays like that (in Dillo). The behaviour is totally random. The page to test is here: https://linicks.net/AnAdIc/ Just use the first field to mess around in. Try 'dillo' first, then just add extra letters or other words to test (as Dillo saves the cache - we need to refresh it). Nick -- Gosh that takes me back... or is it forward? That's the trouble with time travel, you never can tell." -- Doctor Who "Androids of Tara"

1 0

Left border show on the top border of other cell table when use border-collapse: collapse.
by darkspirit5000＠gmail.com June 8, 2016

June 8, 2016

Hello. I have find a this playing with border-collapse: collapse. Left border show on the top border of other cell table. the attachment have minimal code html that breaks Sorry for my english Salud! Diego

1 0

Missing anchor - strange results
by nick＠linicks.net June 5, 2016

June 5, 2016

Hi All, I don't know what to make of this one: http://apod.nasa.gov/apod/ap160604.html It appears line 49 in the source is missing a </a> which seems make the whole paragraph a URL, but the other URLs in there are still shown/valid if you hover over the text. Viewing the source, no errors are reported by Dillo either. So do we get a URL embedding all the other URLs on the plain text in between? Nick -- Gosh that takes me back... or is it forward? That's the trouble with time travel, you never can tell." -- Doctor Who "Androids of Tara"

3 5