- Dillo-dev - lists.mailman3.com

Hello!

by nick＠linicks.net

Hi Per, On 17/04/16 11:23, Per Andersson wrote: > (my previous messages did not reach the list, it seems: trying again) One of your messages reached the list - I replied: http://lists.dillo.org/pipermail/dillo-dev/2016-April/010756.html It doesn't appear in the archive, though. Nick > I am the new guy: programming since 1976 (before that it was only hardware). > I have tried most fields in software, except databases. > I live in Arl?v in southern Sweden. I'm also a musician and archive > researcher/genealogist. > Before i can do anything useful, I need some general understanding of the > project and the software. > Best regards > > Per Andersson > > Senior developer > Artifex Software > > artifex at europe.com > PS My company has no connection with the makers of Ghostscript! ( I had the name > first :-) > > > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev at dillo.org > http://lists.dillo.org/cgi-bin/mailman/listinfo/dillo-dev > -- 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"

April 17, 2016

Status of dillo_grows

by sgeerken＠dillo.org

On Do, Apr 14, 2016, Nick Warne wrote: > I am sorry, this build is borken: > > http://forums.thinkbroadband.com This is a problem with CSS `height`. Consider this HTML: <table style="height: 20px; border: 1px solid"> <tr> <td>Sunt autem quidam e nostris, qui haec subtilius velint tradere et negent satis esse, quid bonum sit aut quid malum, sensu iudicari, sed animo etiam ac ratione intellegi posse et voluptatem ipsam per se esse expetendam et dolorem ipsum per se esse fugiendum. itaque aiunt hanc quasi naturalem atque insitam in animis nostris inesse notionem, ut alterum esse appetendum, alterum aspernandum sentiamus. Alii autem, quibus ego assentior, cum a philosophis compluribus permulta dicantur, cur nec voluptas in bonis sit numeranda nec in malis dolor, non existimant oportere nimium nos causae confidere, sed et argumentandum et accurate disserendum et rationibus conquisitis de voluptate et dolore disputandum putant.</td> </tr> </table> Dillo shows the table only 20px high, while Firefox seems to treat `height` the same way as `min-height`. I'm not sure which is correct, but probably we ought to do something about this, even if dillo is correct. Sebastian

April 17, 2016

Hello!

by artifex.since.1979＠gmail.com

An HTML attachment was scrubbed... URL: <http://lists.dillo.org/pipermail/dillo-dev/attachments/20160417/257516db/at…>

April 17, 2016

Status of dillo_grows

by sgeerken＠dillo.org

On Fr, Apr 15, 2016, Nick Warne wrote: > One more issue to look at - on one of my pages, the in line style renders > correctly with: > > <div style="height: 2px; width: 850px; background-color: blue; text-align: > center;"> > <span style="background-color: white; position: relative; top: -0.75em"> > <font size=-1><b> Word search section ['agc' > engine] </b></font> > </span> > </div> > > Now, current release Dillo just makes it a background colour bar ~ > acceptable. Your patch makes it a sort of underscore coloured line that > passes through the text. I looked at this in detail, and found some strange behaviour in all three versions of dillo (3.0.4, 3.1-dev, and 3.1-dev_grows2). Consider this HTML: <div> A <span style="background-color: green">B</span> C </div> <div> A <span style="background-color: green"><font>B</font></span> C </div> In the first line, "B" is shown with a green background, as expected, but not in the second line, where the only difference is the <font> element. Is this a bug of the HTML parser? Sebastian

April 17, 2016

Status of dillo_grows

by sgeerken＠dillo.org

On Sa, Apr 16, 2016, Nick Warne wrote: > Hi Sebastian, > > On 16/04/16 14:38, Sebastian Geerken wrote: > >On Fr, Apr 15, 2016, Nick Warne wrote: > >>One more issue to look at - on one of my pages, the in line style renders > >>correctly with: > >> > >><div style="height: 2px; width: 850px; background-color: blue; text-align: > >>center;"> > >> <span style="background-color: white; position: relative; top: -0.75em"> > >> <font size=-1><b> Word search section ['agc' > >>engine] </b></font> > >> </span> > >></div> > >> > >>Now, current release Dillo just makes it a background colour bar ~ > >>acceptable. Your patch makes it a sort of underscore coloured line that > >>passes through the text. > >> > >>To test: > >> > >>https://linicks.net/AnAdIc/ > > > >Again, this is again an issue also with the version at hg.dillo.org, > >although the result is slightly different. > > > > From what I see at a first glance the problem is that backgrounds for > >inline sections is not yet supported. > > > >If noone reports severe problems with dillo_grows, which do *not* > >affect the version at hg.dillo.org, I'll do the merge soon. > > Thanks for the hard work. I don't understand what you mean by that last > sentence. If dillo_grows does have a few issues, then surely merging it > with hg.dillo.org will taint that too? Or have I read it wrong? Not if a bug is already in hg.dillo.org. Sebastian

April 16, 2016

Status of dillo_grows

by nick＠linicks.net

Hi Sebastian, On 16/04/16 14:38, Sebastian Geerken wrote: > On Fr, Apr 15, 2016, Nick Warne wrote: >> One more issue to look at - on one of my pages, the in line style renders >> correctly with: >> >> <div style="height: 2px; width: 850px; background-color: blue; text-align: >> center;"> >> <span style="background-color: white; position: relative; top: -0.75em"> >> <font size=-1><b> Word search section ['agc' >> engine] </b></font> >> </span> >> </div> >> >> Now, current release Dillo just makes it a background colour bar ~ >> acceptable. Your patch makes it a sort of underscore coloured line that >> passes through the text. >> >> To test: >> >> https://linicks.net/AnAdIc/ > > Again, this is again an issue also with the version at hg.dillo.org, > although the result is slightly different. > > From what I see at a first glance the problem is that backgrounds for > inline sections is not yet supported. > > If noone reports severe problems with dillo_grows, which do *not* > affect the version at hg.dillo.org, I'll do the merge soon. Thanks for the hard work. I don't understand what you mean by that last sentence. If dillo_grows does have a few issues, then surely merging it with hg.dillo.org will taint that too? Or have I read it wrong? 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"

April 16, 2016

Status of dillo_grows

by sgeerken＠dillo.org

On Fr, Apr 15, 2016, Nick Warne wrote: > One more issue to look at - on one of my pages, the in line style renders > correctly with: > > <div style="height: 2px; width: 850px; background-color: blue; text-align: > center;"> > <span style="background-color: white; position: relative; top: -0.75em"> > <font size=-1><b> Word search section ['agc' > engine] </b></font> > </span> > </div> > > Now, current release Dillo just makes it a background colour bar ~ > acceptable. Your patch makes it a sort of underscore coloured line that > passes through the text. > > To test: > > https://linicks.net/AnAdIc/ Again, this is again an issue also with the version at hg.dillo.org, although the result is slightly different.

April 16, 2016

Status of dillo_grows

by nick＠linicks.net

On 16/04/16 11:46, Per Andersson wrote: > Please enlighten us other idiots! > Best regards > > Per Andersson Once grabbing the clone, cd into the dillo_grows directory and first run ./autogen.sh This will create the configure files etc. Nick > > Ignore this - me being an idiot. > > All is fine. > > 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" > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev at dillo.org > http://lists.dillo.org/cgi-bin/mailman/listinfo/dillo-dev > -- 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"

April 16, 2016

Status of dillo_grows

by nick＠linicks.net

On 14/04/16 21:05, Sebastian Geerken wrote: > On Do, Apr 14, 2016, Nick Warne wrote: >> On 14/04/16 19:24, Johannes Hofmann wrote: >> >On Wed, Apr 13, 2016 at 10:29:14PM +0200, Sebastian Geerken wrote: >> >>Hi! >> >> >> >>I've just pushed some optimizatios to >> >><http://flpsed.org/hgweb/dillo_grows>, so that all performance issues >> >>I know of seem fixed now. Since this version runs quite stable, I'd >> >>like to merge this into the main repository at hg.dillo.org, so that >> >>it hopefully soon becomes a new release. What do you think? >> >> I am sorry, this build is borken: >> >> http://forums.thinkbroadband.com >> >> There are lots of forums there - this build of Dillo only shows the first >> screen with no option to scroll down. >> >> Also I have found a few other issues. > > I see the problem with forums.thinkbroadband.com, I'll look at it. > > However, the current version at hg.dillo.org shows the same problem, > so this should not block the merge, only a release. One more issue to look at - on one of my pages, the in line style renders correctly with: <div style="height: 2px; width: 850px; background-color: blue; text-align: center;"> <span style="background-color: white; position: relative; top: -0.75em"> <font size=-1><b> Word search section ['agc' engine] </b></font> </span> </div> Now, current release Dillo just makes it a background colour bar ~ acceptable. Your patch makes it a sort of underscore coloured line that passes through the text. To test: https://linicks.net/AnAdIc/ 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"

April 15, 2016

Status of dillo_grows

by sgeerken＠dillo.org

On Do, Apr 14, 2016, Nick Warne wrote: > On 14/04/16 19:24, Johannes Hofmann wrote: > >On Wed, Apr 13, 2016 at 10:29:14PM +0200, Sebastian Geerken wrote: > >>Hi! > >> > >>I've just pushed some optimizatios to > >><http://flpsed.org/hgweb/dillo_grows>, so that all performance issues > >>I know of seem fixed now. Since this version runs quite stable, I'd > >>like to merge this into the main repository at hg.dillo.org, so that > >>it hopefully soon becomes a new release. What do you think? > > I am sorry, this build is borken: > > http://forums.thinkbroadband.com > > There are lots of forums there - this build of Dillo only shows the first > screen with no option to scroll down. > > Also I have found a few other issues. I see the problem with forums.thinkbroadband.com, I'll look at it. However, the current version at hg.dillo.org shows the same problem, so this should not block the merge, only a release. Sebastian

April 14, 2016

Status of dillo_grows

by nick＠linicks.net

On 14/04/16 19:24, Johannes Hofmann wrote: > On Wed, Apr 13, 2016 at 10:29:14PM +0200, Sebastian Geerken wrote: >> Hi! >> >> I've just pushed some optimizatios to >> <http://flpsed.org/hgweb/dillo_grows>, so that all performance issues >> I know of seem fixed now. Since this version runs quite stable, I'd >> like to merge this into the main repository at hg.dillo.org, so that >> it hopefully soon becomes a new release. What do you think? I am sorry, this build is borken: http://forums.thinkbroadband.com There are lots of forums there - this build of Dillo only shows the first screen with no option to scroll down. Also I have found a few other issues. Nick > _______________________________________________ > Dillo-dev mailing list > Dillo-dev at dillo.org > http://lists.dillo.org/cgi-bin/mailman/listinfo/dillo-dev > -- 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"

April 14, 2016

Status of dillo_grows

by nick＠linicks.net

On 14/04/16 19:35, Nick Warne wrote: > > > On 14/04/16 19:22, Johannes Hofmann wrote: >>> What is the URL to the repository (default?) to clone the latest Dillo >>> build? >> >> you can get the dillo_grows branch with >> >> hg clone http://flpsed.org/hgweb/dillo_grows > > OK, thanks... but there is no ./configure file. Ignore this - me being an idiot. All is fine. 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"

April 14, 2016

Status of dillo_grows

by nick＠linicks.net

On 14/04/16 19:24, Johannes Hofmann wrote: > I'm running it for some minutes now and it feels super fast! Heh. Dillo on my lowly notebook is to fast - quicker than an eyeblick - how can it get faster? 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"

April 14, 2016

Status of dillo_grows

by nick＠linicks.net

On 14/04/16 19:22, Johannes Hofmann wrote: >> What is the URL to the repository (default?) to clone the latest Dillo >> build? > > you can get the dillo_grows branch with > > hg clone http://flpsed.org/hgweb/dillo_grows OK, thanks... but there is no ./configure file. 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"

April 14, 2016

Status of dillo_grows

by Johannes.Hofmann＠gmx.de

On Wed, Apr 13, 2016 at 10:29:14PM +0200, Sebastian Geerken wrote: > Hi! > > I've just pushed some optimizatios to > <http://flpsed.org/hgweb/dillo_grows>, so that all performance issues > I know of seem fixed now. Since this version runs quite stable, I'd > like to merge this into the main repository at hg.dillo.org, so that > it hopefully soon becomes a new release. What do you think? I'm running it for some minutes now and it feels super fast! I'll report back after some more testing. Johannes

April 14, 2016

Status of dillo_grows

by Johannes.Hofmann＠gmx.de

On Thu, Apr 14, 2016 at 07:02:47PM +0100, Nick Warne wrote: > Hi all, > > On 13/04/16 21:29, Sebastian Geerken wrote: > > Hi! > > > > I've just pushed some optimizatios to > > <http://flpsed.org/hgweb/dillo_grows>, so that all performance issues > > I know of seem fixed now. Since this version runs quite stable, I'd > > like to merge this into the main repository at hg.dillo.org, so that > > it hopefully soon becomes a new release. What do you think? > > I have messed about a bit with hg, but getting nowhere. > > What is the URL to the repository (default?) to clone the latest Dillo > build? you can get the dillo_grows branch with hg clone http://flpsed.org/hgweb/dillo_grows Cheers, Johannes

April 14, 2016

Status of dillo_grows

by nick＠linicks.net

Hi all, On 13/04/16 21:29, Sebastian Geerken wrote: > Hi! > > I've just pushed some optimizatios to > <http://flpsed.org/hgweb/dillo_grows>, so that all performance issues > I know of seem fixed now. Since this version runs quite stable, I'd > like to merge this into the main repository at hg.dillo.org, so that > it hopefully soon becomes a new release. What do you think? I have messed about a bit with hg, but getting nowhere. What is the URL to the repository (default?) to clone the latest Dillo build? 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"

April 14, 2016

Status of dillo_grows

by sgeerken＠dillo.org

Hi! I've just pushed some optimizatios to <http://flpsed.org/hgweb/dillo_grows>, so that all performance issues I know of seem fixed now. Since this version runs quite stable, I'd like to merge this into the main repository at hg.dillo.org, so that it hopefully soon becomes a new release. What do you think? Sebastian

April 13, 2016

px in HTML

by nick＠linicks.net

On 10/04/16 23:23, James C wrote: > Hi All, > > I wonder what the steps are, to have a conversation about whether this > is a good move: > http://lists.dillo.org/pipermail/dillo-dev/2014-August/010200.html > > Regards, > James. I just quickly looked at that. It is not right. You can't guess. Dillo does the right thing in that what it doesn't understand it drops and uses a safe 'auto' value. 'px' '%' et al are all rendered differently, so you can't ignore one that the code doesn't know what to do with - i.e.: "ignoring garbage; using %g (possibly in pixels)\n", Possibly? That could be dangerous, if not bad coding. Nick > On 11/04/2016, Nick Warne <nick at linicks.net> wrote: >> On 10/04/16 16:21, Sebastian Geerken wrote: >>> On So, Apr 10, 2016, Nick Warne wrote: >>>> I have noticed that Dillo doesn't render px properly - this snippet: >>>> >>>> <hr width=500px align=left> >>>> >>>> just produces: >>>> >>>> . >>>> >>>> Using 50% (e.g.) works OK. Is this bad HTML or a 'to-do' thing? >>> >>> The HTML width attribute (which is depricated, btw) does not support >>> "px", instead, <hr width=500 ...> would be correct. >> >> Yes, thanks, I just sussed that out. Dillo is great for debugging HTML, >> as most browsers somehow parse crappy input into what seems right (but >> is wrong!). >> >> width=475 works great now. >> >> 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" >> >> _______________________________________________ >> Dillo-dev mailing list >> Dillo-dev at dillo.org >> http://lists.dillo.org/cgi-bin/mailman/listinfo/dillo-dev >> > -- 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"

April 11, 2016

Over run 'submit' button

by nick＠linicks.net

OK, please ignore this - it was my crappy HTML that produced the issue - Dillo was right, of course. Nick On 10/04/16 18:29, Nick Warne wrote: > Can anybody here tell me why Dillo renders the 'Go' button full form > width on my page here: > > https://linicks.net/cdn1/ > > (forget the iFrame and other stuff). > > It renders nice and small in other browsers [ Go ], but no matter what I > try, the 'Go' button runs the full distance: > [Go ]. > > Dillo reports no errors on the source. > > 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"

April 11, 2016

Cached pages

by nick＠linicks.net

Hi Jorge, On 11/04/16 16:23, Jorge Arellano Cid wrote: >> Now, if if you use the same words on the index page, dillo doesn't run the >> CGI, but produces the previous cached page - sure, a reload works, but that >> doesn't seem logical. > > Logic depends upon the considered facts. > > >> Firefox doesn't do this, it runs the CGI each time, which is what I would >> expect on something that produces dynamic content. > > Cache policy is not trivial (e.g. check idempotency in HTTP). > > For instance, if you decide to try to reload whenever it may > seem useful, you start having problems when users go offline > (i.e. intermitent internet connections). BTW, that's how we got > "offline mode"; Good&Simple right? Hmmm, no. Unfortunately it was > nearly impossible to teach the proverbial grandma when to go > offline and when online. Power users started to complain they > were not able to go back and forward fast on already visited > pages, and that pages dissappeared. Why, the browser issued a > reload every time, cleaning the cache, and guess what, websites > used the opportunity to refresh advertisement. > > At some point there were cache directives served in HTTP, but > they got abused by advertising again (i.e. always reload means > more money). And some sites decided to serve their pages with > always reload directives, even some decided to issue automatic > reloads after a certain a mount of time (more clicks/visits on > the stats, more money for payed advertisingt, etc...). > > One of the reasons why people love to have many open tabs is > that since the reload mess inception (and some other stuff as > custom navigation), it became hard to tell whether you'll be able > to see the same page again by going back and forward. So tabs are > a solution to the new problem. > > As you may see from this short sample, a cache policy must > consider lots of cases. First, I wasn't complaining, just curious (as 10CC sang, I don't like Dillo, I love it!) - and as I was debuggng a perl script, in normal use this wouldn't be an issue as the same input will always produce the same output, so a cached page is always correct. Many thanks for a very detailed explanation of the way this issue got into a mess - I am sure you are the best person to steer Dillo away from it. 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"

April 11, 2016

Cached pages

by jcid＠dillo.org

On Mon, Apr 04, 2016 at 05:16:54PM +0100, Nick Warne wrote: > Hi Jorge, > > On 04/04/16 13:00, Jorge Arellano Cid wrote: > >>Usually shift+[refresh] drops the cache and gets the new page, but the only > >>way I get get dillo to do this is exit, and restart (no big deal with a 0.02 > >>second start-up time :) ) > >> > >>Ideas? > > > > Strange, I just tested this trivial cgi script and a simple reload > >does the trick (button press or Ctrl-r). Does it work for you? > > OK, basically on the html page with the form you enter some letters/words... > hit submit (or 'process' in my case) and the perl CGI produces the results > and the time taken. > > Now, if if you use the same words on the index page, dillo doesn't run the > CGI, but produces the previous cached page - sure, a reload works, but that > doesn't seem logical. Logic depends upon the considered facts. > Firefox doesn't do this, it runs the CGI each time, which is what I would > expect on something that produces dynamic content. Cache policy is not trivial (e.g. check idempotency in HTTP). For instance, if you decide to try to reload whenever it may seem useful, you start having problems when users go offline (i.e. intermitent internet connections). BTW, that's how we got "offline mode"; Good&Simple right? Hmmm, no. Unfortunately it was nearly impossible to teach the proverbial grandma when to go offline and when online. Power users started to complain they were not able to go back and forward fast on already visited pages, and that pages dissappeared. Why, the browser issued a reload every time, cleaning the cache, and guess what, websites used the opportunity to refresh advertisement. At some point there were cache directives served in HTTP, but they got abused by advertising again (i.e. always reload means more money). And some sites decided to serve their pages with always reload directives, even some decided to issue automatic reloads after a certain a mount of time (more clicks/visits on the stats, more money for payed advertisingt, etc...). One of the reasons why people love to have many open tabs is that since the reload mess inception (and some other stuff as custom navigation), it became hard to tell whether you'll be able to see the same page again by going back and forward. So tabs are a solution to the new problem. As you may see from this short sample, a cache policy must consider lots of cases. -- Cheers Jorge.-

April 11, 2016

Cached pages

by jcid＠dillo.org

On Mon, Apr 04, 2016 at 08:09:22PM +0300, John Found wrote: > I am not sure its the same problem, but I have problems with the CSS files. > When some page loads CSS files and I press "Refresh" (or Ctrl+R), Dillo reloads > only the content, but not the linked CSS files. This way, when I try to design > some page to be compatible with Dillo, I have to restart it on every test. > > Other browsers sometimes have the same problem, but they have a way to refresh > with cache clearing - Ctrl+F5 in Firefox. Dillo seems to not have such mode. Yes dillo does not have such mode yet. It would be useful to have it though. -- Cheers Jorge.-

April 11, 2016

Over run 'submit' button

by nick＠linicks.net

Can anybody here tell me why Dillo renders the 'Go' button full form width on my page here: https://linicks.net/cdn1/ (forget the iFrame and other stuff). It renders nice and small in other browsers [ Go ], but no matter what I try, the 'Go' button runs the full distance: [Go ]. Dillo reports no errors on the source. 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"

April 10, 2016

URL searches in dillorc

by nick＠linicks.net

Google can now be updated to (I expect you all know): search_url="Google (https) https://www.google.com/search?ie=UTF-8&oe=UTF-8&q=%s" And maybe add 'onelook', a search engine of all dictionaries: search_url="ol Onelook dictionaries http://www.onelook.com/?w=%s" 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"

April 10, 2016

px in HTML

by nick＠linicks.net

On 10/04/16 16:21, Sebastian Geerken wrote: > On So, Apr 10, 2016, Nick Warne wrote: >> I have noticed that Dillo doesn't render px properly - this snippet: >> >> <hr width=500px align=left> >> >> just produces: >> >> . >> >> Using 50% (e.g.) works OK. Is this bad HTML or a 'to-do' thing? > > The HTML width attribute (which is depricated, btw) does not support > "px", instead, <hr width=500 ...> would be correct. Yes, thanks, I just sussed that out. Dillo is great for debugging HTML, as most browsers somehow parse crappy input into what seems right (but is wrong!). width=475 works great now. 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"

April 10, 2016

px in HTML

by sgeerken＠dillo.org

On So, Apr 10, 2016, Nick Warne wrote: > I have noticed that Dillo doesn't render px properly - this snippet: > > <hr width=500px align=left> > > just produces: > > . > > Using 50% (e.g.) works OK. Is this bad HTML or a 'to-do' thing? The HTML width attribute (which is depricated, btw) does not support "px", instead, <hr width=500 ...> would be correct. Sebastian

April 10, 2016

px in HTML

by nick＠linicks.net

I have noticed that Dillo doesn't render px properly - this snippet: <hr width=500px align=left> just produces: . Using 50% (e.g.) works OK. Is this bad HTML or a 'to-do' thing? BTW, great bit of kit - so fast... 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"

April 10, 2016

abort on read failure

by eocene＠gmx.com

On Sat, Apr 09, 2016 at 10:18:33PM -0300, Jorge Arellano Cid wrote: > Do you mean the problem of "unresponsive links" doesn't happen > anymore on "solid" environments? I don't think it would have any effect on his problem, if I understand it correctly.

April 10, 2016

abort on read failure

by jcid＠dillo.org

Hi, On Sat, Apr 09, 2016 at 04:25:29PM +0000, eocene wrote: > > I was recently in an environment with a very weak connection. > With most sites, if I didn't get a full page, lsof would show the > connection still open and just sitting there. Some sites _would_ > close the connection, but unfortunately dillo wouldn't give the > user any indication that further waiting was pointless. > > I just committed some code that aborts the connection on read > failure. It also gives a status msg to the user (though status > messages are imperfect, as discussed last month). > > The case where no data was received could bear further improvement, > but I had limited time and improved what I needed most. > > It got a week or so of "free" testing in that bad environment, > and hasn't given me any trouble since then in more solid > environments. Do you mean the problem of "unresponsive links" doesn't happen anymore on "solid" environments? -- Cheers Jorge.-

April 10, 2016

abort on read failure

by eocene＠gmx.com

I was recently in an environment with a very weak connection. With most sites, if I didn't get a full page, lsof would show the connection still open and just sitting there. Some sites _would_ close the connection, but unfortunately dillo wouldn't give the user any indication that further waiting was pointless. I just committed some code that aborts the connection on read failure. It also gives a status msg to the user (though status messages are imperfect, as discussed last month). The case where no data was received could bear further improvement, but I had limited time and improved what I needed most. It got a week or so of "free" testing in that bad environment, and hasn't given me any trouble since then in more solid environments.

April 9, 2016

Non-drawing of nested tables

by jcid＠dillo.org

Hi James, On Mon, Apr 04, 2016 at 01:44:02PM +1200, James C wrote: > The attached html draws nested tables with green borders on (old) > Safari, Chrome and Firefox on OSX 10.6.8. > > On the tip of the default branch of dillo, it draws the page title and > nothing else. > > I plan to keep deploying it, in the hope that dillo's behaviour will > change toward everything else's. If someone wants to supervise me > toward accepting a patch, then I'm willing to explore toward fixing > it. Thanks for the bug report, and your will to help by working on it. I gave it a preliminar look and the problem is very simple, the comment terminator in the test page is "--!>" instead of "-->" , so dillo thinks of a long unterminated comment. "--!>" is not a legal comment terminator in HTML 4.01. Why some browsers honour it (e.g. SGML corner case, heuristics, ...) I don't know. It may be on purpose or just a side effect. -- Cheers Jorge.-

April 6, 2016

Cached pages

by johnfound＠asm32.info

I am not sure its the same problem, but I have problems with the CSS files. When some page loads CSS files and I press "Refresh" (or Ctrl+R), Dillo reloads only the content, but not the linked CSS files. This way, when I try to design some page to be compatible with Dillo, I have to restart it on every test. Other browsers sometimes have the same problem, but they have a way to refresh with cache clearing - Ctrl+F5 in Firefox. Dillo seems to not have such mode. On Sun, 3 Apr 2016 20:31:14 +0100 Nick Warne <nick at linicks.net> wrote: > Hi all, > > I first used 'dillo' many years go on a 486 running Mandrake Linux > around 2004. Since then, forgot all about it. Until now - it is brilliant. > > Anyway, to the point. I run my own web server, and while debugging CGI > perl scripts etc. dillo somehow caches the results from the output produced. > > Usually shift+[refresh] drops the cache and gets the new page, but the > only way I get get dillo to do this is exit, and restart (no big deal > with a 0.02 second start-up time :) ) > > Ideas? > > 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" > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev at dillo.org > http://lists.dillo.org/cgi-bin/mailman/listinfo/dillo-dev -- http://fresh.flatassembler.net http://asm32.info John Found <johnfound at asm32.info>

April 4, 2016

Cached pages

by nick＠linicks.net

Hi Jorge, On 04/04/16 13:00, Jorge Arellano Cid wrote: >> Usually shift+[refresh] drops the cache and gets the new page, but the only >> way I get get dillo to do this is exit, and restart (no big deal with a 0.02 >> second start-up time :) ) >> >> Ideas? > > Strange, I just tested this trivial cgi script and a simple reload > does the trick (button press or Ctrl-r). Does it work for you? OK, basically on the html page with the form you enter some letters/words... hit submit (or 'process' in my case) and the perl CGI produces the results and the time taken. Now, if if you use the same words on the index page, dillo doesn't run the CGI, but produces the previous cached page - sure, a reload works, but that doesn't seem logical. Firefox doesn't do this, it runs the CGI each time, which is what I would expect on something that produces dynamic content. The page is here is you want to have a look: https://linicks.net/AnAdIc/ Nick P.S. ssl/TLS works well on my site! -- 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"

April 4, 2016

Cached pages

by jcid＠dillo.org

Hi Nick, On Sun, Apr 03, 2016 at 08:31:14PM +0100, Nick Warne wrote: > Hi all, > > I first used 'dillo' many years go on a 486 running Mandrake Linux around > 2004. Since then, forgot all about it. Until now - it is brilliant. Good to hear you like it, thanks. > > Anyway, to the point. I run my own web server, and while debugging CGI perl > scripts etc. dillo somehow caches the results from the output produced. > > Usually shift+[refresh] drops the cache and gets the new page, but the only > way I get get dillo to do this is exit, and restart (no big deal with a 0.02 > second start-up time :) ) > > Ideas? Strange, I just tested this trivial cgi script and a simple reload does the trick (button press or Ctrl-r). Does it work for you? -- Cheers Jorge.- -- #!/bin/sh # # Simple bash CGI script. # Return current time and date # # # HTTP doc type (2 newlines needed). echo "Content-type: text/html" echo # HTML content echo " <html><body> <PRE> `/bin/date` </PRE> </body></html> "

April 4, 2016

Non-drawing of nested tables

by james.from.wellington＠gmail.com

The attached html draws nested tables with green borders on (old) Safari, Chrome and Firefox on OSX 10.6.8. On the tip of the default branch of dillo, it draws the page title and nothing else. I plan to keep deploying it, in the hope that dillo's behaviour will change toward everything else's. If someone wants to supervise me toward accepting a patch, then I'm willing to explore toward fixing it. Regards, James.

April 4, 2016

Cached pages

by nick＠linicks.net

Hi all, I first used 'dillo' many years go on a 486 running Mandrake Linux around 2004. Since then, forgot all about it. Until now - it is brilliant. Anyway, to the point. I run my own web server, and while debugging CGI perl scripts etc. dillo somehow caches the results from the output produced. Usually shift+[refresh] drops the cache and gets the new page, but the only way I get get dillo to do this is exit, and restart (no big deal with a 0.02 second start-up time :) ) Ideas? 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"

April 3, 2016

block elements (was: Is this a known bug?)

by sgeerken＠dillo.org

On Mo, M?r 14, 2016, Sebastian Geerken wrote: > Probably the simplest approach is that dw::Textblock simply uses > widget style, not word style for alignment. I'm not sure whether there > is already one dw::Textblock for each block element. I've looked at this; I'd like to get rid of the current form of dw:Textblock::addParbreak. So far, I've stumbled on the tags <form>, <dl>, and <dt> (and <dir>, FFIW), which are not yet rendered as new dw::Textblock. However, when I look at Html_tag_open_pre (as an example), I'm confused how this is supposed to work. Sebastian

March 20, 2016

Is this a known bug?

by sgeerken＠dillo.org

On Mo, M?r 14, 2016, John Found wrote: > In the following html: > > <html> > <head> > </head> > <body style="text-align: left;"> > <div style="width: 50%; text-align: right; background: #f0f060;"> > <span style="display:inline-block; text-align: left; height: 32px; width: 150px; background: #60f0f0;">Some text!</span> > </div> > </body> > </html> > > Dillo aligns the div to the right and the span to the left of the div, while all other browsers align the div to the left and the span to the right. Something like (B-body, D-div, S-span): > > Dillo: > BBBBBBBBBBBBBBBBBBBBB > DDDDDDDDDDD > SSSSS > > Others: > BBBBBBBBBBBBBBBBBBBBB > DDDDDDDDDDD > SSSSS I haven't looked at it in detail, but it looks like dillo is referring 'text-align' to the element where it is defined, so positioning the <div> on the right, and <span> on the left side. As specified in [1], this is incorrect behaviour: 'text-align' [...] Applies to:??block containers [...] This property describes how *inline-level content* of a block container is aligned. Values have the following meanings: [...] (Emphasis mine.) Probably the simplest approach is that dw::Textblock simply uses widget style, not word style for alignment. I'm not sure whether there is already one dw::Textblock for each block element. Sebastian [1] https://www.w3.org/TR/CSS2/text.html#propdef-text-align

March 14, 2016

Is this a known bug?

by johnfound＠asm32.info

In the following html: <html> <head> </head> <body style="text-align: left;"> <div style="width: 50%; text-align: right; background: #f0f060;"> <span style="display:inline-block; text-align: left; height: 32px; width: 150px; background: #60f0f0;">Some text!</span> </div> </body> </html> Dillo aligns the div to the right and the span to the left of the div, while all other browsers align the div to the left and the span to the right. Something like (B-body, D-div, S-span): Dillo: BBBBBBBBBBBBBBBBBBBBB DDDDDDDDDDD SSSSS Others: BBBBBBBBBBBBBBBBBBBBB DDDDDDDDDDD SSSSS Regards -- http://fresh.flatassembler.net http://asm32.info John Found <johnfound at asm32.info>

March 14, 2016

Feature request: Server connection status message

by Hole.destructor＠gmx.de

Hello Jorge, > I'd go for kind of a colored led indicator in the status bar (not wiped by > cursor movement {which displays the underlying URL}). that when hovered pops > a hint text briefly explaining the status. For instance: > > red: Resolving server name > orange: contacting host > yellow: expecting answer > green: data stream already flowing. > white/off: done. > > That way it would be quite easy to tell at which stage lies the failure. I think that would be very solution, because, as you said, the underlying URL would still be visible in the status bar. > Obviously this is for the main page only (not images, nor stylesheets, > nor other resources). That's a good point, actually. Wouldn't it make sense to display information about stylesheets, images etc. as well? Best regards, Alex On Fri, Mar 11, 2016 at 09:07:15AM -0300, Jorge Arellano Cid wrote: > On Thu, Mar 10, 2016 at 04:12:05AM +0000, eocene wrote: > > On Wed, Mar 09, 2016 at 08:39:02PM +1300, James C wrote: > > > Hello Dillo maintainer people, > > > > > > If I set out to write this patch, the first version will be painful. Do you want the change? Do you want to hand-hold me through writing it? > > > > We do have: > > > > MSG_BW(S->web, 1, "Contacting host..."); > > MSG_BW(S->web, 1, "DNS resolving %s", hostname); > > > > for the status bar, although unfortunately they are wiped out if you move > > the pointer over a link. I've thought it would be nice if such status messages > > could reappear when no longer showing a link... > > Yep. > > It was a bit funny to see a feature request for some status messages which > were already there (among others). > The reasons for it, though, are completely understandable (IMO). Usually > those messages go very fast and get wiped out by cursor movement, so > they miss the intended informative purpose. > > It was also very good to read a question before trying to develop a patch. > Usually it's better to ask and have some feedback before coding [the attentive > reader already got that the reuqested patch would make no difference]. > > ... but the problem is real! > > Years have taught me to try to find the root problem of what the patch > tries to fix. In this case, it looks like the problem it that sometimes > the user can't find out whether the page has been asked for or not (no > visual clue feedback telling the difference). I've had the same problem > at times (using ADSL). Thinking of it as I use dillo, I suspect that sometimes > the servers are answering a "temporarily busy" HTTP message or just droping > the connection. This is known to happen, as it was developed as a technique > against bots and DDOS attacks, by using the fact that a web browser would > try again (which dillo may not be doing for some cases). > I've also noticed that sometimes I don't get images from a site and the > reason is that the DNS can't resolve the name, but when asked again it does. > This surely is part of the problem (at least for me). BTW, this is typical > behaviour of a crowded DNS server. > > I'd go for kind of a colored led indicator in the status bar (not wiped by > cursor movement {which displays the underlying URL}). that when hovered pops > a hint text briefly explaining the status. For instance: > > red: Resolving server name > orange: contacting host > yellow: expecting answer > green: data stream already flowing. > white/off: done. > > That way it would be quite easy to tell at which stage lies the failure. > Obviously this is for the main page only (not images, nor stylesheets, > nor other resources). > > Now, I'd say the problem would be tackled once the underlying causes > (as the ones described above, or a different one) are patched for. In > which case the "status led indicator" would be very useful feedback, and > would help to locate problems while browsing. > > Let's discuss this a bit before coding, > we have a very good signal/noise ratio in dillo-dev! > > > -- > Cheers > Jorge.- > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev at dillo.org > http://lists.dillo.org/cgi-bin/mailman/listinfo/dillo-dev

March 13, 2016

Feature request: Server connection status message

by jcid＠dillo.org

On Thu, Mar 10, 2016 at 04:12:05AM +0000, eocene wrote: > On Wed, Mar 09, 2016 at 08:39:02PM +1300, James C wrote: > > Hello Dillo maintainer people, > > > > If I set out to write this patch, the first version will be painful. Do you want the change? Do you want to hand-hold me through writing it? > > We do have: > > MSG_BW(S->web, 1, "Contacting host..."); > MSG_BW(S->web, 1, "DNS resolving %s", hostname); > > for the status bar, although unfortunately they are wiped out if you move > the pointer over a link. I've thought it would be nice if such status messages > could reappear when no longer showing a link... Yep. It was a bit funny to see a feature request for some status messages which were already there (among others). The reasons for it, though, are completely understandable (IMO). Usually those messages go very fast and get wiped out by cursor movement, so they miss the intended informative purpose. It was also very good to read a question before trying to develop a patch. Usually it's better to ask and have some feedback before coding [the attentive reader already got that the reuqested patch would make no difference]. ... but the problem is real! Years have taught me to try to find the root problem of what the patch tries to fix. In this case, it looks like the problem it that sometimes the user can't find out whether the page has been asked for or not (no visual clue feedback telling the difference). I've had the same problem at times (using ADSL). Thinking of it as I use dillo, I suspect that sometimes the servers are answering a "temporarily busy" HTTP message or just droping the connection. This is known to happen, as it was developed as a technique against bots and DDOS attacks, by using the fact that a web browser would try again (which dillo may not be doing for some cases). I've also noticed that sometimes I don't get images from a site and the reason is that the DNS can't resolve the name, but when asked again it does. This surely is part of the problem (at least for me). BTW, this is typical behaviour of a crowded DNS server. I'd go for kind of a colored led indicator in the status bar (not wiped by cursor movement {which displays the underlying URL}). that when hovered pops a hint text briefly explaining the status. For instance: red: Resolving server name orange: contacting host yellow: expecting answer green: data stream already flowing. white/off: done. That way it would be quite easy to tell at which stage lies the failure. Obviously this is for the main page only (not images, nor stylesheets, nor other resources). Now, I'd say the problem would be tackled once the underlying causes (as the ones described above, or a different one) are patched for. In which case the "status led indicator" would be very useful feedback, and would help to locate problems while browsing. Let's discuss this a bit before coding, we have a very good signal/noise ratio in dillo-dev! -- Cheers Jorge.-

March 11, 2016

Feature request: Server connection status message

by eocene＠gmx.com

On Wed, Mar 09, 2016 at 08:39:02PM +1300, James C wrote: > Hello Dillo maintainer people, > > If I set out to write this patch, the first version will be painful. Do you want the change? Do you want to hand-hold me through writing it? We do have: MSG_BW(S->web, 1, "Contacting host..."); MSG_BW(S->web, 1, "DNS resolving %s", hostname); for the status bar, although unfortunately they are wiped out if you move the pointer over a link. I've thought it would be nice if such status messages could reappear when no longer showing a link...

March 10, 2016

Dillo crash on HTTPS connection (to MS web site)

by eocene＠gmx.com

On Wed, Mar 09, 2016 at 11:41:15AM +0100, Johannes Hofmann wrote: > I was experiencing this assertion also now on > https://blog.scaleway.com/2016/03/08/c2-insanely-affordable-x64-servers/ > and the patch below fixes it. Ah, good. Thanks for the report!

March 9, 2016

Dillo crash on HTTPS connection (to MS web site)

by johannes.hofmann＠gmx.de

Hi, I was experiencing this assertion also now on https://blog.scaleway.com/2016/03/08/c2-insanely-affordable-x64-servers/ and the patch below fixes it. Cheers, Johannes On Wed, Mar 02, 2016 at 11:10:13AM +0000, eocene wrote: > On Wed, Feb 24, 2016 at 11:41:48PM +0200, John Found wrote: > > ** ERROR **: our TLS mystery error is: error:140C5042:SSL routines:ssl_undefined_function:called a function you should not call > > If this is indeed the same problem that apache, nginx, et al., are seeing, > then the attached should suffice to fix it. > > diff -r 50d1c1aff6ae src/IO/tls.c > --- a/src/IO/tls.c Mon Jan 25 19:48:54 2016 +0100 > +++ b/src/IO/tls.c Wed Mar 02 11:00:50 2016 +0000 > @@ -1041,7 +1041,12 @@ > a_IOwatch_remove_fd(c->fd, -1); > dClose(c->fd); > } > - SSL_shutdown(c->ssl); > + if (!SSL_in_init(c->ssl)) { > + /* openssl 1.0.2f does not like shutdown being called during handshake, > + * resulting in ssl_undefined_function in the error queue. > + */ > + SSL_shutdown(c->ssl); > + } > SSL_free(c->ssl); > > a_Url_free(c->url); > _______________________________________________ > Dillo-dev mailing list > Dillo-dev at dillo.org > http://lists.dillo.org/cgi-bin/mailman/listinfo/dillo-dev

March 9, 2016

Feature request: Server connection status message

by james.from.wellington＠gmail.com

Hello Dillo maintainer people, If I set out to write this patch, the first version will be painful. Do you want the change? Do you want to hand-hold me through writing it? Regards, James. > On 9/03/2016, at 4:09 am, Alexander Voigt <Hole.destructor at gmx.de> wrote: > > Hi James, > >> 'Transferring ...' is already covered in the top right corner, where >> there is a number of kilobytes that goes grey when transferring >> finishes. > > ah, you are right, I was not aware of that. > >> I wonder if the other things that you want could be retrofitted into >> that box. I wonder if the set should include: >> - Parse - parsing the URL and preparing to act on it >> - DNS - waiting for the DNS >> - CONN - waiting for a TCP connection to complete >> - SEC - waiting for a security handshake > > Yes, that would be great! It would make even more transparent what > Dillo does in the background. > > Best regards, > Alex > >> On Tue, Mar 08, 2016 at 10:53:49PM +1300, James C wrote: >> Hello Alexander, >> >> 'Transferring ...' is already covered in the top right corner, where >> there is a number of kilobytes that goes grey when transferring >> finishes. >> >> I wonder if the other things that you want could be retrofitted into >> that box. I wonder if the set should include: >> - Parse - parsing the URL and preparing to act on it >> - DNS - waiting for the DNS >> - CONN - waiting for a TCP connection to complete >> - SEC - waiting for a security handshake >> >> Regards, >> James. >> >>> On 08/03/2016, Alexander Voigt <Hole.destructor at gmx.de> wrote: >>> Dear Dillo developers, >>> >>> since the bug tracker is down, please let me propose a new feature >>> over the mailing list. >>> >>> From time to time I am in places with a very bad internet connection. >>> when I surf with Dillo and click on a link it appears that nothing >>> happens, except that the link color has changed. Then I'm usually >>> wondering what's going on now. Did I really click the link? Has the >>> server has been found? Is the server responding very slowly? Does >>> Dillo receive data from it? Or is my connection dead? >>> >>> To avoid this confusion, I'd like to propose a status message which is >>> displayed in the status bar at the very bottom of the Dillo window. >>> The message could say what is currently been done. For example, >>> Firefox says >>> >>> "Looking up www.example.de" >>> "Waiting for www.example.de" >>> "Transferring data from www.example.de" >>> >>> Many thanks and best regards, >>> Alex >>> >>> _______________________________________________ >>> Dillo-dev mailing list >>> Dillo-dev at dillo.org >>> http://lists.dillo.org/cgi-bin/mailman/listinfo/dillo-dev >>>

March 9, 2016

Feature request: Server connection status message

by Hole.destructor＠gmx.de

Hi James, > 'Transferring ...' is already covered in the top right corner, where > there is a number of kilobytes that goes grey when transferring > finishes. ah, you are right, I was not aware of that. > I wonder if the other things that you want could be retrofitted into > that box. I wonder if the set should include: > - Parse - parsing the URL and preparing to act on it > - DNS - waiting for the DNS > - CONN - waiting for a TCP connection to complete > - SEC - waiting for a security handshake Yes, that would be great! It would make even more transparent what Dillo does in the background. Best regards, Alex On Tue, Mar 08, 2016 at 10:53:49PM +1300, James C wrote: > Hello Alexander, > > 'Transferring ...' is already covered in the top right corner, where > there is a number of kilobytes that goes grey when transferring > finishes. > > I wonder if the other things that you want could be retrofitted into > that box. I wonder if the set should include: > - Parse - parsing the URL and preparing to act on it > - DNS - waiting for the DNS > - CONN - waiting for a TCP connection to complete > - SEC - waiting for a security handshake > > Regards, > James. > > On 08/03/2016, Alexander Voigt <Hole.destructor at gmx.de> wrote: > > Dear Dillo developers, > > > > since the bug tracker is down, please let me propose a new feature > > over the mailing list. > > > > From time to time I am in places with a very bad internet connection. > > when I surf with Dillo and click on a link it appears that nothing > > happens, except that the link color has changed. Then I'm usually > > wondering what's going on now. Did I really click the link? Has the > > server has been found? Is the server responding very slowly? Does > > Dillo receive data from it? Or is my connection dead? > > > > To avoid this confusion, I'd like to propose a status message which is > > displayed in the status bar at the very bottom of the Dillo window. > > The message could say what is currently been done. For example, > > Firefox says > > > > "Looking up www.example.de" > > "Waiting for www.example.de" > > "Transferring data from www.example.de" > > > > Many thanks and best regards, > > Alex > > > > _______________________________________________ > > Dillo-dev mailing list > > Dillo-dev at dillo.org > > http://lists.dillo.org/cgi-bin/mailman/listinfo/dillo-dev > >

March 8, 2016

Feature request: Server connection status message

by james.from.wellington＠gmail.com

Hello Alexander, 'Transferring ...' is already covered in the top right corner, where there is a number of kilobytes that goes grey when transferring finishes. I wonder if the other things that you want could be retrofitted into that box. I wonder if the set should include: - Parse - parsing the URL and preparing to act on it - DNS - waiting for the DNS - CONN - waiting for a TCP connection to complete - SEC - waiting for a security handshake Regards, James. On 08/03/2016, Alexander Voigt <Hole.destructor at gmx.de> wrote: > Dear Dillo developers, > > since the bug tracker is down, please let me propose a new feature > over the mailing list. > > From time to time I am in places with a very bad internet connection. > when I surf with Dillo and click on a link it appears that nothing > happens, except that the link color has changed. Then I'm usually > wondering what's going on now. Did I really click the link? Has the > server has been found? Is the server responding very slowly? Does > Dillo receive data from it? Or is my connection dead? > > To avoid this confusion, I'd like to propose a status message which is > displayed in the status bar at the very bottom of the Dillo window. > The message could say what is currently been done. For example, > Firefox says > > "Looking up www.example.de" > "Waiting for www.example.de" > "Transferring data from www.example.de" > > Many thanks and best regards, > Alex > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev at dillo.org > http://lists.dillo.org/cgi-bin/mailman/listinfo/dillo-dev >

March 8, 2016

Feature request: Server connection status message

by Hole.destructor＠gmx.de

Dear Dillo developers, since the bug tracker is down, please let me propose a new feature over the mailing list. >From time to time I am in places with a very bad internet connection. when I surf with Dillo and click on a link it appears that nothing happens, except that the link color has changed. Then I'm usually wondering what's going on now. Did I really click the link? Has the server has been found? Is the server responding very slowly? Does Dillo receive data from it? Or is my connection dead? To avoid this confusion, I'd like to propose a status message which is displayed in the status bar at the very bottom of the Dillo window. The message could say what is currently been done. For example, Firefox says "Looking up www.example.de" "Waiting for www.example.de" "Transferring data from www.example.de" Many thanks and best regards, Alex

March 8, 2016

CPU hog

by jcid＠dillo.org

Hi, FYI, https://www.raspberrypi.org/blog/raspberry-pi-3-on-sale/ gives a CPU hog on both dillo and dillo_grows. -- Cheers Jorge.-

March 5, 2016