- Dillo-dev - lists.mailman3.com

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