- Dillo-dev - lists.mailman3.com

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