- Dillo-dev - lists.mailman3.com

Rodrigo did you get my last email and the mbox.tgz
by pastebin＠gmx.com June 7, 2024

June 7, 2024

Hi Rodrigo did you get my mbox.tgz file? the email addresses might not be munged

2 1

mailing list is now considered spam
by pastebin＠gmx.com June 5, 2024

June 5, 2024

sorry to post this - but it is also a test for some reason the last few posts from the dev-dillo(a)mailman3.com mailing list are now considered spam and i have to download the 'past 30 days/mbox' to get them from https://lists.mailman3.com/hyperkitty/list/dillo-dev@mailman3.com/ what was changed?

2 3

dns over tls or dns over https
by pastebin＠gmx.com June 4, 2024

June 4, 2024

Hi could someone give me an idea about dillo using 'dns over tls' or 'dns over https'? or using dnssec? what about dillo using mbed-tls vs openssl? the configuration only shows a --disable-mbedtls

3 4

Dillo 3.1.0 on Mac OS X Tiger
by Sevan Janiyan May 8, 2024

May 8, 2024

Attached is a screenshot taken today of Dillo 3.1.0 running on Mac OS X Tiger 10.4, linked against latest versions of OpenSSL 3.2, zlib, libpng, libjpeg. :) Sevan

2 1

Dillo 3.1.0 released
by Rodrigo Arias May 5, 2024

May 5, 2024

Hi, I'm happy to announce that version 3.1.0 is finally released! https://dillo-browser.github.io/latest.html Thank you all for the patches and tests! Best, Rodrigo.

2 1

Re: Broken CSS in Hacker News
by Rodrigo Arias May 4, 2024

May 4, 2024

FYI ----- Forwarded message from Hacker News <hn(a)ycombinator.com> ----- Date: Sat, 4 May 2024 13:58:22 -0700 From: Hacker News <hn(a)ycombinator.com> To: Rodrigo Arias <rodarima(a)gmail.com> Subject: Re: Broken CSS in Hacker News Should be fixed now. Thanks! dang On Sat, May 4, 2024 at 4:36 AM Rodrigo Arias <rodarima(a)gmail.com> wrote: > Hi, > > I'm adding Hacker News in CC. > > On Sat, May 04, 2024 at 11:20:25AM +0200, a1ex(a)dismail.de wrote: > >Hi Rodrigo, > > > >> >>Sometimes the page text is not entirely wrapped to the browser > >> >>window, resulting in lines extending off screen, which is a pain. > >> > >> What do you mean by "resulting in lines extending off screen"? If you > >> mean the Dillo viewport, that is probably caused by some missing CSS > >> feature, which we should fix too, but shouldn't happen with CSS > >> disabled. > > > >Here is an example: > >https://news.ycombinator.com/item?id=40250573 > > > >Viewing the page in Dillo with CSS turned off, some of the text > >runs off the window and I have to scroll right to see it. With CSS > >turned on, the text is very small and impossible to read on my monitor > >(but now the offending lines fit on the window). > >In Firefox, the text appears correctly and is always wrapped to the > >window regardless of zoom level. > > I see what is going on. > > By default, Dillo doesn't wrap the content of <pre> elements. But, the > following rule in HN CSS should cause it to wrap the text at spaces and > newlines: > > > pre { overflow: auto; padding: 2px; white-space: pre-wrap; > > overflow-wrap:anywhere; } > > But Dillo fails to process the CSS document because it doesn't > understand a previous rule: > > > input[type=\"submit\"] { font-family:Verdana, Geneva, sans-serif; } > > The 'input[type=\"submit\"]' selector is causing the CSS parser to > ignore the rest of the CSS style sheet. > > I believe this is a bug in HN CSS, as it should be: > > > input[type="submit"] { font-family:Verdana, Geneva, sans-serif; } > > Which works properly, I attached a reproducer. > > I have to check what is going on in the parser, by I suspect the first > \" causes the parser to enter "string mode", and then the second \" is > parsed as a quote inside the string because it is escaped, not as the > closing quote. So everything else in the CSS file is treated as the > content of the string. This should be fixed on HN side. > > We should make the CSS parser more robust to these problems. > > In the meanwhile, you can add this workaround in ~/.dillo/style.css to > make <pre> wrapped by default in all pages: > > > pre { white-space: pre-wrap; } > > Best, > Rodrigo > ----- End forwarded message -----

1 0

"Layout::resizeIdle calls" messages ignore show_msg=NO
by Kevin Koster May 4, 2024

May 4, 2024

With Dillo 3.1.0-rc1 (and the current Git repo master branch), these messages are printed to stdout when pages load even with show_msg=NO in dillorc: ... Layout::resizeIdle calls = 578 Layout::resizeIdle calls = 579 Layout::resizeIdle calls = 580 Layout::resizeIdle calls = 581 Layout::resizeIdle calls = 582 Layout::resizeIdle calls = 583 ... I see that they come from a printf call in dw/layout.cc, line 876. Dillo 3.0.5 doesn't output such messages, and they are a minor inconvenience when starting dillo from a terminal window, so it would be nice if they obeyed the show_msg setting in dillorc when Dillo 3.1.0 is released.

2 2

<td> width attributes ignored
by Kevin Koster April 28, 2024

April 28, 2024

Another page rendering issue that's introduced after the 3.0.5 release, this time affecting my own website. URL: http://www.ombertech.com/ CSS: enabled or disabled Summary: <td> width attributes ignored. 3.0.5: Heading table at the top of the page displays correctly scaled with links in the middle formatted in a horizontal row if they all fit in 1/3rd of the browser window's width. 3.1.0-rc1: The "width" attributes of the <td> elements are ignored and the links in the middle are thereby squashed into a vertical row. Further testing with modified versions of the page shows that this table cell width problem is only present if the width attribute in the <td> elements is a percentage and the <table> element also has a width attribute set as a percentage, then the <td> width attributes get ignored. If either (or both) table or td width is in pixels, the problem isn't present, only when table and td width are both specified as percentages. So far as I can tell setting width in <table> and <td> elements as a percentage is valid for HTML 4.01 Transitional, and other browsers (Links, Firefox) render the table correctly.

2 2

Dillo not rendering HTML with comments before <!DOCTYPE>
by Kevin Koster April 28, 2024

April 28, 2024

This problem was present in 3.0.5 as well as in 3.1.0-rc1. URL: http://www.lemis.com/ CSS: enabled or disabled Summary: Won't render HTML with comments before <!DOCTYPE>. Pages on this website aren't rendered, just displayed as source code. Although they are XHTML, this doesn't appear to be due to this bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1036382 If I save the file as lemis.xhtml and remove the two comment lines before the <!DOCTYPE> declaration, then it renders when I load it with file:// or http://, otherwise it doesn't. My reading is that comments there are valid for HTML 4 (which is declared in the page's <!DOCTYPE>) since the standard says: White space (spaces, newlines, tabs, and comments) may appear before or after each section. https://www.w3.org/TR/html401/struct/global.html#h-7.1

2 7

Links closed empty due to <a> containing <div>
by Kevin Koster April 22, 2024

April 22, 2024

I use Dillo 3.0.5 (with SNI support added to the HTTPS plug-in) for the majority of my web browsing, so it's great to see some movement towards the next version. Testing 3.1.0-rc1 I still notice some HTML rendering regressions and other bugs which I'll report in this and the following emails. I don't see any of these the GitHub Issues section, but I won't post them there because I hate the GitHub website - it doesn't work in my favourite web browser for one thing! Other people are welcome to, though I'll only participate in discussion here. URL: http://my-addr.com/ CSS: enabled or disabled Summary: Links closed empty due to <a> containing <div>. 3.0.5: All links on page are usable and <a> elements don't have errors listed in the bug window. 3.1.0-rc1: Links below the horizontal heading bar at the top of the page aren't usable, they're just shown as plain text. The Bug window shows all of these <a> elements are closed when a <div> element is found inside them, leaving no text present inside the link. I see that <div> isn't allowed inside <a> according to the standard, but other browsers (Links and Firefox) still render this website's links in a functional way and it's a pretty inconvenient breakage.

2 2