- Dillo-dev - lists.mailman3.com

Re: extra /tmp on file name line when save html

by pastebin＠gmx.com

any idea what triggers it? On Mon, 03 Jun 2024 23:02:21 -0400 "Charles E. Lehner" <cel(a)celehner.com> wrote: > I see something like this. Selecting all in the text box allows rewriting > the whole path. > > On Monday, 3 June 2024 18:35:03 EDT, pastebin(a)gmx.com wrote: > > Hi > > > > i save html files in a dir called /html (dillo saves them > > correctly there 99.99% of the time) > > > > i have a dir /html/tmp (dir named tmp in /html) > > > > but sometimes and i can't pin down what causes it the file line > > becomes /tmp and if i try to backspace it just adds more > > /tmp/tmp/tmp etc so i have to cancel the file save and redo > > the dialog > > i can click on tmp and the dir changes to /html/tmp and saving > > file there is no problem > > > > any one experiencing something similar or any ideas? > _______________________________________________ > Dillo-dev mailing list -- dillo-dev(a)mailman3.com > To unsubscribe send an email to dillo-dev-leave(a)mailman3.com

June 8, 2024

Version 3.1.1 released

by Rodrigo Arias

Hi, I just released the 3.1.1 version of Dillo: https://dillo-browser.github.io/release/3.1.1/ It only includes minor bug fixes, but we can now begin to merge new features for next 3.2.0 :-) Best, Rodrigo.

June 8, 2024

Re: Rodrigo did you get my last email and the mbox.tgz

by Rodrigo Arias

On Fri, Jun 07, 2024 at 12:18:12PM -0600, pastebin(a)gmx.com wrote: >Hi Rodrigo > >did you get my mbox.tgz file? the email addresses might not be munged I got the mbox file you sent me last week: % md5sum pastebin-mbox.tgz 53df2eb78251621db802bfc4ba2e459f pastebin-mbox.tgz It is archived on GitHub too: https://github.com/dillo-browser/dillo/issues/45#issuecomment-2143587504 Rodrigo.

June 7, 2024

Rodrigo did you get my last email and the mbox.tgz

by pastebin＠gmx.com

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

June 7, 2024

Re: mailing list is now considered spam

by pastebin＠gmx.com

On Wed, 5 Jun 2024 00:05:25 +0200 Rodrigo Arias <rodarima(a)gmail.com> wrote: > >for some reason the last few posts from the dev-dillo(a)mailman3.com > >mailing list are now considered spam > > On gmail it seems to be working as usual. > > They are also being accepted by mail-archive.com: accepted -> displayed you can't send emails to mail-archive.com .... can you? > > https://www.mail-archive.com/dillo-dev@mailman3.com/ > > Maybe something with gmx.com? > _______________________________________________ > Dillo-dev mailing list -- dillo-dev(a)mailman3.com > To unsubscribe send an email to dillo-dev-leave(a)mailman3.com

June 4, 2024

Re: mailing list is now considered spam

by pastebin＠gmx.com

must be gmx - cause i got this one from you/the mailing list - but not the post i sent to the mailing list On Wed, 5 Jun 2024 00:05:25 +0200 Rodrigo Arias <rodarima(a)gmail.com> wrote: > >for some reason the last few posts from the dev-dillo(a)mailman3.com > >mailing list are now considered spam > > On gmail it seems to be working as usual. > > They are also being accepted by mail-archive.com: > > https://www.mail-archive.com/dillo-dev@mailman3.com/ > > Maybe something with gmx.com? > _______________________________________________ > Dillo-dev mailing list -- dillo-dev(a)mailman3.com > To unsubscribe send an email to dillo-dev-leave(a)mailman3.com

June 4, 2024

Re: mailing list is now considered spam

by Rodrigo Arias

>for some reason the last few posts from the dev-dillo(a)mailman3.com >mailing list are now considered spam On gmail it seems to be working as usual. They are also being accepted by mail-archive.com: https://www.mail-archive.com/dillo-dev@mailman3.com/ Maybe something with gmx.com?

June 4, 2024

mailing list is now considered spam

by pastebin＠gmx.com

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?

June 4, 2024

Re: extra /tmp on file name line when save html

by Charles E. Lehner

I see something like this. Selecting all in the text box allows rewriting the whole path. On Monday, 3 June 2024 18:35:03 EDT, pastebin(a)gmx.com wrote: > Hi > > i save html files in a dir called /html (dillo saves them > correctly there 99.99% of the time) > > i have a dir /html/tmp (dir named tmp in /html) > > but sometimes and i can't pin down what causes it the file line > becomes /tmp and if i try to backspace it just adds more > /tmp/tmp/tmp etc so i have to cancel the file save and redo > the dialog > i can click on tmp and the dir changes to /html/tmp and saving > file there is no problem > > any one experiencing something similar or any ideas?

June 4, 2024

Re: dns over tls or dns over https

by Kevin Koster

Rodrigo Arias <rodarima-Re5JQEeQqe8AvxtiuMwx3w(a)public.gmane.org> wrote: > On Sat, Jun 01, 2024 at 02:21:36PM -0600, pastebin-KK0ffGbhmjU(a)public.gmane.org wrote: >>suggestion add 'to search for mbed TLS only' to '--disable-openssl' >>switch :) > > Good idea. Yes when I first tried to build with MbedTLS I assumed '--enable-mbedtls' would work, then I had to run configure again with '--disable-openssl' when I saw it had still selected OpenSSL. At least the "Configuration summary" makes these mistakes much more obvious than most other configure scripts do.

June 3, 2024

extra /tmp on file name line when save html

by pastebin＠gmx.com

Hi i save html files in a dir called /html (dillo saves them correctly there 99.99% of the time) i have a dir /html/tmp (dir named tmp in /html) but sometimes and i can't pin down what causes it the file line becomes /tmp and if i try to backspace it just adds more /tmp/tmp/tmp etc so i have to cancel the file save and redo the dialog i can click on tmp and the dir changes to /html/tmp and saving file there is no problem any one experiencing something similar or any ideas?

June 3, 2024

Re: dns over tls or dns over https

by Rodrigo Arias

Hi, On Sat, Jun 01, 2024 at 02:21:36PM -0600, pastebin(a)gmx.com wrote: >Thanks - good information > >are you getting my emails to your gmail email? Got them now, as they went so spam. >suggestion add 'to search for mbed TLS only' to '--disable-openssl' >switch :) Good idea. >why don't you like dnssec? I do, just didn't configured it in this machine. Rodrigo.

June 1, 2024

Re: it is nice to see dillo reborn

by Rodrigo Arias

Hi, On Sat, Jun 01, 2024 at 09:06:44AM -0600, pastebin(a)gmx.com wrote: >> Yes, you can send them to my email. Not sure what format sylpheed >> uses, but I will try to convert them to mbox and merge what is >> missing. > >see my private email to you Just got it now, thanks! >see attached pngs > >1.png 'save page as file' dialog - dialog size i want > >2.png 'save page as file' dialog - file already exists - dialog size i want > >3.png 'file exists' dialog - is the same size as 'save page as file' >dialog - the size is to large for what i want so if i reduce the >dimensions - the next 'save page as file' dialog i get will be to small >(the same size as what i made the 'file exists' dialog As a general note, in your pictures I see you are loading /root directly from Dillo, which suggest you are running Dillo as root. I would really avoid doing that while browsing, as any potential remote code execution we could have would give an attacker immediate root access on your machine (among other issues). >dillo saves one dimension size for the two dialog boxes >maybe 2 separate size dimensions for 'save page as file' and 'file >exists' dialog If you have a working patch I could merge it into 3.1.1. Otherwise I can queue it among the other issues, as I would need to investigate further how to solve it. I have a patch somewhere that switches to a native file picker, which may solve one of the problems (it also remembers where you saved the last file). But this will probably be added in 3.2.0, as I'm finishing bug fixes for 3.1.1 (no more features for now). >do don't get ssl dialog warning when connecting to https site and does >connection > >src.IO.tls.c >/* 3.0.5 modification > choice = a_Dialog_choice(title, dialog_warning_msg, "Continue", > "Cancel", NULL); > if (choice == 1) { > ret = 0; > } */ > ret = 0; > dFree(dialog_warning_msg); > } > } > dFree(title); > This shouldn't be a problem now, as the annoying pop-ups are fixed. But they still show when there is an actual problem with the TLS certificates, in which case you *don't* want to ignore them by default. >- > >src.prefs.c >/* 3.0.5 modification >#define PREFS_HOME "http://www.dillo.org/" */ >#define PREFS_HOME "" > >src.ui.cc >/* 3.0.5 modification > StatusOutput->value("http://www.dillo.org"); */ > StatusOutput->value(""); > >- These are fixed too. You can configure the home address to another value in dillorc with the "home" option, no need to patch Dillo. > >src.menu.cc >/* 3.0.5 modification > static Menu_popup_data_t page_data = {"Page menu", NULL, pm}; */ > static Menu_popup_data_t page_data = {NULL, NULL, pm}; > >src.menu.cc >/* 3.0.5 modification > static Menu_popup_data_t image_data = {"Image menu", NULL, pm}; */ > static Menu_popup_data_t image_data = {NULL, NULL, pm}; > >src.menu.cc >/* 3.0.5 modification > static Menu_popup_data_t form_data = {"Form menu", NULL, pm}; */ > static Menu_popup_data_t form_data = {NULL, NULL, pm}; > >--- I think these are useful to be seen, as it may happen that you are clicking accidentally on an image that is larger than it look like, and the menu is not what you would expect. > >> >and changing position of dialog buttons i will post them in case >> >someone else wants them - >> >> This may be useful, as sometimes they open in weird positions. > >i didn't do this for 3.0.5 (just for earlier versions - i forgot to do it for 3.0.5 and it was okay :) For the future, if you work with git (recommended), you can format your patches with `git format-patch` so they can be applied directly. Or with `git send-email` so you also include the patch message and other metadata. Alternatively, please format patches with `patch -up` so they are easy to integrate. Best, Rodrigo.

June 1, 2024

Re: dns over tls or dns over https

by pastebin＠gmx.com

Thanks - good information are you getting my emails to your gmail email? suggestion add 'to search for mbed TLS only' to '--disable-openssl' switch :) why don't you like dnssec? On Sat, 1 Jun 2024 21:58:42 +0200 Rodrigo Arias <rodarima(a)gmail.com> wrote: > Hi, > > On Sat, Jun 01, 2024 at 01:27:07PM -0600, pastebin(a)gmx.com wrote: > >Hi > > > >could someone give me an idea about dillo using 'dns over tls' or 'dns > >over https'? or using dnssec? > > The mobilized fork has added support for it, as it is provided by > libcurl (which they have switched to): > > > 20240522: New tarball. To enable DNS-over-HTTPS (DoH), you can now set > > the preference dns_over_https_url. > > https://www.toomanyatoms.com/software/mobilized_dillo.html > > My recommendation is to setup a local resolver on your machine, so all > name resolution is handled by it, not just Dillo. Then you can use > whatever mechanism you want (DoH, DoT, DNSSEC...). > > This would be especially useful if you download a file with Dillo, as it > would launch an external wget process. Or if you use any plugin that > performs network operations on its own. > > Here are some docs (even if you don't use Arch): > > https://wiki.archlinux.org/title/DNS-over-HTTPS > https://wiki.archlinux.org/title/DNSSEC > > I didn't check on my own how well that works, but I would rather keep it > out of Dillo if posible. > > >what about dillo using mbed-tls vs openssl? > >the configuration only shows a --disable-mbedtls > > The DNS resolution is done prior to interacting with any TLS library. > There is also a --disable-openssl switch to search for mbed TLS only, > see ./configure --help. > > Best, > Rodrigo. > _______________________________________________ > Dillo-dev mailing list -- dillo-dev(a)mailman3.com > To unsubscribe send an email to dillo-dev-leave(a)mailman3.com

June 1, 2024

Re: dns over tls or dns over https

by Rodrigo Arias

Hi, On Sat, Jun 01, 2024 at 01:27:07PM -0600, pastebin(a)gmx.com wrote: >Hi > >could someone give me an idea about dillo using 'dns over tls' or 'dns >over https'? or using dnssec? The mobilized fork has added support for it, as it is provided by libcurl (which they have switched to): > 20240522: New tarball. To enable DNS-over-HTTPS (DoH), you can now set > the preference dns_over_https_url. https://www.toomanyatoms.com/software/mobilized_dillo.html My recommendation is to setup a local resolver on your machine, so all name resolution is handled by it, not just Dillo. Then you can use whatever mechanism you want (DoH, DoT, DNSSEC...). This would be especially useful if you download a file with Dillo, as it would launch an external wget process. Or if you use any plugin that performs network operations on its own. Here are some docs (even if you don't use Arch): https://wiki.archlinux.org/title/DNS-over-HTTPS https://wiki.archlinux.org/title/DNSSEC I didn't check on my own how well that works, but I would rather keep it out of Dillo if posible. >what about dillo using mbed-tls vs openssl? >the configuration only shows a --disable-mbedtls The DNS resolution is done prior to interacting with any TLS library. There is also a --disable-openssl switch to search for mbed TLS only, see ./configure --help. Best, Rodrigo.

June 1, 2024

dns over tls or dns over https

by pastebin＠gmx.com

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

June 1, 2024

Re: it is nice to see dillo reborn

by pastebin＠gmx.com

Hi Rodrigo I passed my emissions better than last years numbers - now i can pollute the environment with a smile that i complied with their silly money making scheme here are the replies On Tue, 28 May 2024 22:45:06 +0200 Rodrigo Arias <rodarima(a)gmail.com> wrote: > Hi, > > On Mon, May 27, 2024 at 04:14:15PM -0600, pastebin(a)gmx.com wrote: > >i have saved 140 emails from 2019-2022 in (2) tar.bz2 files (total > >780K) your archive seems to be missing my posts :) which are in these > >as well > >i would have no idea about sending them to the archive.org but what > >about sending them to you directly rather then through the mailing > >list? > >they are in indivdual files just tarred up sylpheed folder dirs not in > >mbox format > > Yes, you can send them to my email. Not sure what format sylpheed uses, > but I will try to convert them to mbox and merge what is missing. see my private email to you > >my only problems with 3.0.5 where changes in the size of 'dialog' > >popups that affected other popup sizes (i will be more specific when > >they next occur) > >there appears to be one 'size' that applies to all popups? am i > >correct? > > Not sure what size are you referring to, is this an option in dillorc? see attached pngs 1.png 'save page as file' dialog - dialog size i want 2.png 'save page as file' dialog - file already exists - dialog size i want 3.png 'file exists' dialog - is the same size as 'save page as file' dialog - the size is to large for what i want so if i reduce the dimensions - the next 'save page as file' dialog i get will be to small (the same size as what i made the 'file exists' dialog dillo saves one dimension size for the two dialog boxes maybe 2 separate size dimensions for 'save page as file' and 'file exists' dialog > >I've been compiling source since early red hat and it never dawned on > >me that running ./configure is as dangerouse as hacked source itself - > >if the source is not trusted then neither is the ./configure - thanks > >for straightening me out on a decade old basic false assumption i've > >had (YIKES!) > > :-) > > >My changes from 3.0.5 to my 3.1 are largely cosmetic prefernces (local > >loading of help file vs getting it over the web when click '?' > > This is the default[1] but the manual has been updated heavily. If the > local file cannot be opened, the remote version[2] is tried. > > [1]:https://github.com/dillo-browser/dillo/blob/v3.1.0/src/ui.cc#L240-L255 > [2]:https://dillo-browser.github.io/user_help.html > > >and adding duckduck to primary search choice when click 'magnifying > >glass' > > This is also the default now. since they are now the default they are moot for dillo-3.1.0 src.IO.about.c /* i3.0.5 modification " <a href='http://www.dillo.org/dillo3-help.html'>\n" */ " <a href='file://root/.dillo/help/dillo3-help.html'>\n" src.prefs.c /* 3.0.5 modification #define PREFS_SEARCH_URL "https://www.google.com/search?ie=UTF-8&oe=UTF-8&q=%s" */ #define PREFS_SEARCH_URL "http://duckduckgo.com/lite/?kp=-1&q=%s" src.menu.cc /* 3.0.5 modification a_UIcmd_open_urlstr(popup_bw, "http://www.dillo.org/help/bug_meter.html"); */ a_UIcmd_open_urlstr(popup_bw, "file:/root/.dillo/bugmeter/bug_meter.html"); src.ui.cc /* 3.0.5 modification a_UIcmd_open_urlstr(bw, "http://www.dillo.org/dillo3-help.html"); */ a_UIcmd_open_urlstr(bw, "file://root/.dillo/help/dillo3-help.html"); - - do don't get ssl dialog warning when connecting to https site and does connection src.IO.tls.c /* 3.0.5 modification choice = a_Dialog_choice(title, dialog_warning_msg, "Continue", "Cancel", NULL); if (choice == 1) { ret = 0; } */ ret = 0; dFree(dialog_warning_msg); } } dFree(title); - src.prefs.c /* 3.0.5 modification #define PREFS_HOME "http://www.dillo.org/" */ #define PREFS_HOME "" src.ui.cc /* 3.0.5 modification StatusOutput->value("http://www.dillo.org"); */ StatusOutput->value(""); - src.menu.cc /* 3.0.5 modification static Menu_popup_data_t page_data = {"Page menu", NULL, pm}; */ static Menu_popup_data_t page_data = {NULL, NULL, pm}; src.menu.cc /* 3.0.5 modification static Menu_popup_data_t image_data = {"Image menu", NULL, pm}; */ static Menu_popup_data_t image_data = {NULL, NULL, pm}; src.menu.cc /* 3.0.5 modification static Menu_popup_data_t form_data = {"Form menu", NULL, pm}; */ static Menu_popup_data_t form_data = {NULL, NULL, pm}; --- > >and changing position of dialog buttons i will post them in case > >someone else wants them - > > This may be useful, as sometimes they open in weird positions. i didn't do this for 3.0.5 (just for earlier versions - i forgot to do it for 3.0.5 and it was okay :)

June 1, 2024

Re: it is nice to see dillo reborn

by pastebin＠gmx.com

Hi Rodrigo sorry about the delay - i can send the emails to you (see below) and the pngs (see below) and button position changes to the mailing list as soon as i pass my state car emissions test - i have until friday 5/31/24 to prevent a $120.00 fine it seems - i think they also mentioned i could just donate the car to charity - but right now i'm the chartity who wants the car most - a new rotor and cap and spark plug wires appear to be in order here > On Mon, May 27, 2024 at 04:14:15PM -0600, pastebin(a)gmx.com wrote: > >i have saved 140 emails from 2019-2022 in (2) tar.bz2 files (total > >780K) your archive seems to be missing my posts :) which are in these > >as well > >i would have no idea about sending them to the archive.org but what > >about sending them to you directly rather then through the mailing > >list? > >they are in indivdual files just tarred up sylpheed folder dirs not in > >mbox format > > Yes, you can send them to my email. Not sure what format sylpheed uses, > but I will try to convert them to mbox and merge what is missing. it looks like i can export the dirs to 'unix mbox' format in sylpheed itself i will tar.gz them and send them to you sometime this week as soon as i can > >my only problems with 3.0.5 where changes in the size of 'dialog' > >popups that affected other popup sizes (i will be more specific when > >they next occur) > >there appears to be one 'size' that applies to all popups? am i > >correct? > > Not sure what size are you referring to, is this an option in dillorc? it is the size of any 'dialog' box that affects the size of all other boxes after that - some dialogs i like small and others i want bigger but if i change the one i want bigger to bigger - then the one i want smaller also becomes bigger and vice versa - leading to a horrible cirular situation :) i will send pngs to the mailing list when i do some testing > This is the default[1] but the manual has been updated heavily. If the > local file cannot be opened, the remote version[2] is tried. > > [1]:https://github.com/dillo-browser/dillo/blob/v3.1.0/src/ui.cc#L240-L255 > [2]:https://dillo-browser.github.io/user_help.html > > >and adding duckduck to primary search choice when click 'magnifying > >glass' > > This is also the default now. defaults based on smart and intelligent use are always good ;) > >and changing position of dialog buttons i will post them in case > >someone else wants them - > > This may be useful, as sometimes they open in weird positions. i will also send as soon as possible > > Best, > Rodrigo. > _______________________________________________ > Dillo-dev mailing list -- dillo-dev(a)mailman3.com > To unsubscribe send an email to dillo-dev-leave(a)mailman3.com

May 29, 2024

Re: it is nice to see dillo reborn

by Rodrigo Arias

Hi, On Mon, May 27, 2024 at 04:14:15PM -0600, pastebin(a)gmx.com wrote: >i have saved 140 emails from 2019-2022 in (2) tar.bz2 files (total >780K) your archive seems to be missing my posts :) which are in these >as well >i would have no idea about sending them to the archive.org but what >about sending them to you directly rather then through the mailing >list? >they are in indivdual files just tarred up sylpheed folder dirs not in >mbox format Yes, you can send them to my email. Not sure what format sylpheed uses, but I will try to convert them to mbox and merge what is missing. >my only problems with 3.0.5 where changes in the size of 'dialog' >popups that affected other popup sizes (i will be more specific when >they next occur) >there appears to be one 'size' that applies to all popups? am i >correct? Not sure what size are you referring to, is this an option in dillorc? >I've been compiling source since early red hat and it never dawned on >me that running ./configure is as dangerouse as hacked source itself - >if the source is not trusted then neither is the ./configure - thanks >for straightening me out on a decade old basic false assumption i've >had (YIKES!) :-) >My changes from 3.0.5 to my 3.1 are largely cosmetic prefernces (local >loading of help file vs getting it over the web when click '?' This is the default[1] but the manual has been updated heavily. If the local file cannot be opened, the remote version[2] is tried. [1]:https://github.com/dillo-browser/dillo/blob/v3.1.0/src/ui.cc#L240-L255 [2]:https://dillo-browser.github.io/user_help.html >and adding duckduck to primary search choice when click 'magnifying >glass' This is also the default now. >and changing position of dialog buttons i will post them in case >someone else wants them - This may be useful, as sometimes they open in weird positions. Best, Rodrigo.

May 28, 2024

Re: it is nice to see dillo reborn

by pastebin＠gmx.com

Thank you Rodrigo for the pgp/signing info - i have now installed the dillo-3.1.0 and it installed and runs fine On Mon, 27 May 2024 22:41:16 +0200 Rodrigo Arias <rodarima(a)gmail.com> wrote: > Hi, > > On Mon, May 27, 2024 at 12:52:12PM -0600, pastebin(a)gmx.com wrote: > >Hello dillo-dev mailing list, > > > >i was able to successfully import into sylpheed what appears to be a > >complete mbox of the old original dillo.org mailing list and the new > >mailman3.com mailing list - (thank you very much for this work and > >setting up the new mailman3.com mailing list) > > If you happen to have an old archive I would like to get a copy, as > there are some segments of time with missing attachments or other > problems. I tried to put it together as best as I could from the copies > I could get from the web. You can upload it to archive.org to avoid > sending large files to the ML. i have saved 140 emails from 2019-2022 in (2) tar.bz2 files (total 780K) your archive seems to be missing my posts :) which are in these as well i would have no idea about sending them to the archive.org but what about sending them to you directly rather then through the mailing list? they are in indivdual files just tarred up sylpheed folder dirs not in mbox format > >i have reposted my 5/11/24 post to the old (dead) dillo.org mailing > >list to this list > > > >i am glad to see dillo being reborn - it is my main http/https browser > >(i use w3m and curl and seamonkey as needed) > > Glad to see Dillo is still being used :-) > > >--- > > > >To: dillo-dev(a)dillo.org > >Subject: dillo-3.1.0 > >Date: Sat, 11 May 2024 16:00:22 -0600 > > > >Hi > > > >i just saw this on slashdot > >https://tech.slashdot.org/story/24/05/11/1348216/lightweight-dillo-browser-… > > > >and downloaded dillo-3.1.0.tar.bz2 from (https://github.com/dillo-browser/dillo/releases/download/v3.1.0/dillo-3.1.0…) > >configure --enable-ssl --disable-ipv6 (--enable-ssl from dillo-3.0.5 is deprecated in dillo-3.1.0) ( > > The --enable-ssl flag is renamed to --enable-tls and is now enabled by > default. > > >checking FLTK 1.3... yes > >checking for libpng version... 1.6.37 > >configure: Using OpenSSL as TLS library. > >checking for pthread_create in -lpthread... yes > > > >make good > >make install didn't do > > > > > >but because of many known questions of github vulnerability problems (i > >no longer get any source from github - except this one time) > > You don't need to trust GitHub, both the tarball and the release tag are > signed with my GPG key: > > % gpg --keyserver keys.openpgp.org --recv-keys 32E65EC501A1B6FDF8190D293EE6BA977EB2A253 > gpg: key 3EE6BA977EB2A253: "Rodrigo Arias Mallo <rodarima(a)gmail.com>" 1 new signature > gpg: Total number processed: 1 > gpg: new signatures: 1 > > % gpg --verify dillo-3.1.0.tar.gz.asc dillo-3.1.0.tar.gz > gpg: Signature made 2024-05-04T22:12:49 CEST > gpg: using RSA key 32E65EC501A1B6FDF8190D293EE6BA977EB2A253 > gpg: Good signature from "Rodrigo Arias Mallo <rodarima(a)gmail.com>" [ultimate] > > % git tag -v v3.1.0 > object 995ed3bd934484df7cfc437324f1eea2202d179b > type commit > tag v3.1.0 > tagger Rodrigo Arias Mallo <rodarima(a)gmail.com> 1714853597 +0200 > > Release version 3.1.0 > gpg: Signature made 2024-05-04T22:13:25 CEST > gpg: using RSA key 32E65EC501A1B6FDF8190D293EE6BA977EB2A253 > gpg: issuer "rodarima(a)gmail.com" > gpg: Good signature from "Rodrigo Arias Mallo <rodarima(a)gmail.com>" [ultimate] > > GitHub has not had the chance to write anything to the repository > silently. Changes are merged from the command line using git, as I don't > trust the web PR merge button. > > >i didn't install it or run it until i can go over the code myself or > >someone also does a security check of the source code (added 5/27/24 > >this is only a reflection on the github problems and not on anyone > >coding dillo) > > If you find any issues, please report them here so we can fix them. I > tried my best to improve Dillo, but I may have also accidentally > introduced new bugs (as with any piece of software). my only problems with 3.0.5 where changes in the size of 'dialog' popups that affected other popup sizes (i will be more specific when they next occur) there appears to be one 'size' that applies to all popups? am i correct? if they occur with the dillo-3.1.0 i will report what i find > Keep in mind that running the configure itself is dangerous if you don't > trust the source. I've been compiling source since early red hat and it never dawned on me that running ./configure is as dangerouse as hacked source itself - if the source is not trusted then neither is the ./configure - thanks for straightening me out on a decade old basic false assumption i've had (YIKES!) > > If you don't trust doing `make install` as root, you can use the > --prefix=/foo/bar flag to install Dillo in a path were your user can > write (instead of /usr/local), then you don't need root to install it. > You will only need to `export PATH=$PATH:/boo/bar/bin` to get the Dillo > binaries in your PATH. > > >i have done my own dillo-3.1 from dillo-3.0.5 > > Do you mean you have some patches of your own? It would be nice if you > can share them if that is the case. My changes from 3.0.5 to my 3.1 are largely cosmetic prefernces (local loading of help file vs getting it over the web when click '?' and adding duckduck to primary search choice when click 'magnifying glass' and changing position of dialog buttons i will post them in case someone else wants them - > >i will also wait to test the configure option > >--enable-html-tests Enable HTML tests (requires xvfb, xwd and imagemagick) > > Those tests check that Dillo renders a test page pixel-by-pixel > identical to a reference page and are designed to catch regressions. > They are not required for general use of the browser. > > Best, > Rodrigo. > _______________________________________________ > Dillo-dev mailing list -- dillo-dev(a)mailman3.com > To unsubscribe send an email to dillo-dev-leave(a)mailman3.com

May 27, 2024

Re: it is nice to see dillo reborn

by Rodrigo Arias

Hi, On Mon, May 27, 2024 at 12:52:12PM -0600, pastebin(a)gmx.com wrote: >Hello dillo-dev mailing list, > >i was able to successfully import into sylpheed what appears to be a >complete mbox of the old original dillo.org mailing list and the new >mailman3.com mailing list - (thank you very much for this work and >setting up the new mailman3.com mailing list) If you happen to have an old archive I would like to get a copy, as there are some segments of time with missing attachments or other problems. I tried to put it together as best as I could from the copies I could get from the web. You can upload it to archive.org to avoid sending large files to the ML. >i have reposted my 5/11/24 post to the old (dead) dillo.org mailing >list to this list > >i am glad to see dillo being reborn - it is my main http/https browser >(i use w3m and curl and seamonkey as needed) Glad to see Dillo is still being used :-) >--- > >To: dillo-dev(a)dillo.org >Subject: dillo-3.1.0 >Date: Sat, 11 May 2024 16:00:22 -0600 > >Hi > >i just saw this on slashdot >https://tech.slashdot.org/story/24/05/11/1348216/lightweight-dillo-browser-… > >and downloaded dillo-3.1.0.tar.bz2 from (https://github.com/dillo-browser/dillo/releases/download/v3.1.0/dillo-3.1.0…) >configure --enable-ssl --disable-ipv6 (--enable-ssl from dillo-3.0.5 is deprecated in dillo-3.1.0) ( The --enable-ssl flag is renamed to --enable-tls and is now enabled by default. >checking FLTK 1.3... yes >checking for libpng version... 1.6.37 >configure: Using OpenSSL as TLS library. >checking for pthread_create in -lpthread... yes > >make good >make install didn't do > > >but because of many known questions of github vulnerability problems (i >no longer get any source from github - except this one time) You don't need to trust GitHub, both the tarball and the release tag are signed with my GPG key: % gpg --keyserver keys.openpgp.org --recv-keys 32E65EC501A1B6FDF8190D293EE6BA977EB2A253 gpg: key 3EE6BA977EB2A253: "Rodrigo Arias Mallo <rodarima(a)gmail.com>" 1 new signature gpg: Total number processed: 1 gpg: new signatures: 1 % gpg --verify dillo-3.1.0.tar.gz.asc dillo-3.1.0.tar.gz gpg: Signature made 2024-05-04T22:12:49 CEST gpg: using RSA key 32E65EC501A1B6FDF8190D293EE6BA977EB2A253 gpg: Good signature from "Rodrigo Arias Mallo <rodarima(a)gmail.com>" [ultimate] % git tag -v v3.1.0 object 995ed3bd934484df7cfc437324f1eea2202d179b type commit tag v3.1.0 tagger Rodrigo Arias Mallo <rodarima(a)gmail.com> 1714853597 +0200 Release version 3.1.0 gpg: Signature made 2024-05-04T22:13:25 CEST gpg: using RSA key 32E65EC501A1B6FDF8190D293EE6BA977EB2A253 gpg: issuer "rodarima(a)gmail.com" gpg: Good signature from "Rodrigo Arias Mallo <rodarima(a)gmail.com>" [ultimate] GitHub has not had the chance to write anything to the repository silently. Changes are merged from the command line using git, as I don't trust the web PR merge button. >i didn't install it or run it until i can go over the code myself or >someone also does a security check of the source code (added 5/27/24 >this is only a reflection on the github problems and not on anyone >coding dillo) If you find any issues, please report them here so we can fix them. I tried my best to improve Dillo, but I may have also accidentally introduced new bugs (as with any piece of software). Keep in mind that running the configure itself is dangerous if you don't trust the source. If you don't trust doing `make install` as root, you can use the --prefix=/foo/bar flag to install Dillo in a path were your user can write (instead of /usr/local), then you don't need root to install it. You will only need to `export PATH=$PATH:/boo/bar/bin` to get the Dillo binaries in your PATH. >i have done my own dillo-3.1 from dillo-3.0.5 Do you mean you have some patches of your own? It would be nice if you can share them if that is the case. >i will also wait to test the configure option >--enable-html-tests Enable HTML tests (requires xvfb, xwd and imagemagick) Those tests check that Dillo renders a test page pixel-by-pixel identical to a reference page and are designed to catch regressions. They are not required for general use of the browser. Best, Rodrigo.

May 27, 2024

it is nice to see dillo reborn

by pastebin＠gmx.com

Hello dillo-dev mailing list, i was able to successfully import into sylpheed what appears to be a complete mbox of the old original dillo.org mailing list and the new mailman3.com mailing list - (thank you very much for this work and setting up the new mailman3.com mailing list) i have reposted my 5/11/24 post to the old (dead) dillo.org mailing list to this list i am glad to see dillo being reborn - it is my main http/https browser (i use w3m and curl and seamonkey as needed) --- To: dillo-dev(a)dillo.org Subject: dillo-3.1.0 Date: Sat, 11 May 2024 16:00:22 -0600 Hi i just saw this on slashdot https://tech.slashdot.org/story/24/05/11/1348216/lightweight-dillo-browser-… and downloaded dillo-3.1.0.tar.bz2 from (https://github.com/dillo-browser/dillo/releases/download/v3.1.0/dillo-3.1.0…) configure --enable-ssl --disable-ipv6 (--enable-ssl from dillo-3.0.5 is deprecated in dillo-3.1.0) ( checking FLTK 1.3... yes checking for libpng version... 1.6.37 configure: Using OpenSSL as TLS library. checking for pthread_create in -lpthread... yes make good make install didn't do but because of many known questions of github vulnerability problems (i no longer get any source from github - except this one time) i didn't install it or run it until i can go over the code myself or someone also does a security check of the source code (added 5/27/24 this is only a reflection on the github problems and not on anyone coding dillo) i have done my own dillo-3.1 from dillo-3.0.5 i will also wait to test the configure option --enable-html-tests Enable HTML tests (requires xvfb, xwd and imagemagick)

May 27, 2024

Re: Dillo 3.1.0 on Mac OS X Tiger

by Rodrigo Arias

Hi, On Sun, May 05, 2024 at 09:48:29PM +0100, Sevan Janiyan wrote: >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 Thanks! I added it to the gallery: https://dillo-browser.github.io/gallery/ Best, Rodrigo.

May 8, 2024

Dillo 3.1.0 on Mac OS X Tiger

by Sevan Janiyan

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

May 5, 2024

Re: Dark mode screenshot and tutorial

by a1ex＠dismail.de

> bg_color=000000 > ui_fg_color=999999 > ui_main_bg_color=000000 > ui_text_bg_color=000000 > ui_selection_color=444444 > ui_button_highlight_color=ffffff > ui_tab_active_bg_color=999999 > ui_tab_active_fg_color=000000 > ui_tab_bg_color=000000 Correction, the hex color codes above should obviously be prefixed with a '#', otherwise Dillo will complain on the console: prefs: Color '000000' not recognized. correct: bg_color=#000000 Interesting that it somehow still works without the '#' though, despite the warning...

May 5, 2024

Dark mode screenshot and tutorial

by a1ex＠dismail.de

Hi list, Attached is a screenshot of Dillo with a simple "Dark Mode" theme. For those interested in how to do this, here is a small tutorial: Put this in ~/.dillo/style.css: * { background-color: #000000 !important; color: #999999 !important; } :link { color: #ffffff !important; text-decoration: none !important; } :visited { color: #ffffff !important; text-decoration: underline !important; } Put this in ~/.dillo/dillorc: bg_color=000000 ui_fg_color=999999 ui_main_bg_color=000000 ui_text_bg_color=000000 ui_selection_color=444444 ui_button_highlight_color=ffffff ui_tab_active_bg_color=999999 ui_tab_active_fg_color=000000 ui_tab_bg_color=000000 And then we can tighten up the UI to taste: panel_size=tiny small_icons=YES show_search=NO show_help=NO Hopefully someone will find this useful :) Regards, Alex

May 5, 2024

Re: Dillo 3.1.0 released

by Kevin Koster

Rodrigo Arias <rodarima-Re5JQEeQqe8AvxtiuMwx3w(a)public.gmane.org> wrote: > > I'm happy to announce that version 3.1.0 is finally released! > > https://dillo-browser.github.io/latest.html Great to hear, thank you for your efforts! It would be really nice if there were direct download links in the release announcement, since the GitHub releases page doesn't show them without Javascript so you can't download Dillo using Dillo. For others here, these are the direct download links: dillo-3.1.0.zip.asc (488) https://github.com/dillo-browser/dillo/releases/download/v3.1.0/dillo-3.1.0… dillo-3.1.0.zip (1.4M) https://github.com/dillo-browser/dillo/releases/download/v3.1.0/dillo-3.1.0… dillo-3.1.0.tar.gz.asc (488) https://github.com/dillo-browser/dillo/releases/download/v3.1.0/dillo-3.1.0… dillo-3.1.0.tar.gz (1.2M) https://github.com/dillo-browser/dillo/releases/download/v3.1.0/dillo-3.1.0… dillo-3.1.0.tar.bz2.asc (488) https://github.com/dillo-browser/dillo/releases/download/v3.1.0/dillo-3.1.0… dillo-3.1.0.tar.bz2 (972K) https://github.com/dillo-browser/dillo/releases/download/v3.1.0/dillo-3.1.0…

May 4, 2024

Re: Broken CSS in Hacker News

by Rodrigo Arias

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 -----

May 4, 2024

Dillo 3.1.0 released

by Rodrigo Arias

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.

May 4, 2024

Re: Broken CSS in Hacker News

by a1ex＠dismail.de

> 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; } That does the trick, thanks very much! This has been a frustration for quite a while, and I'm pretty sure I have run into other sites in the past with similar issues. Hopefully never again :) Thanks again, Alex

May 4, 2024

Re: Feature idea: zoom buttons

by Rodrigo Arias

Hi, I reply to this in another thread to keep the topic about the zoom feature. On Sat, May 04, 2024 at 11:20:25AM +0200, a1ex(a)dismail.de wrote: >I have tested your patch and it works pretty well, minus the image >scaling issue you mentioned. Thanks for testing! >One thing I will note however, on a TKL (ten key less) keyboard, there >is no dedicated '+' key, so zooming in doesn't work. On a US layout >for example, the key is =/+, but pressing Ctrl-Shift-= doesn't have >the expected result. I changed the mapping in keys.cc to Ctrl-= and it >works for me, but would vary for other localizations. I choose the Ctrl + / Ctrl - as it is the default in other browsers, but I mostly use Ctrl and the mouse wheel. I haven't been able to figure it out how to make it work yet on Dillo, but maybe that would help you too. In any case, you can adjust the ~/.dillo/keysrc file to you needs[1], no need to change the source code. [1]: https://dillo-browser.github.io/user_help.html#keysrc Best, Rodrigo.

May 4, 2024

Broken CSS in Hacker News

by Rodrigo Arias

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

May 4, 2024

Re: Feature idea: zoom buttons

by a1ex＠dismail.de

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 think we should implement a zoom control, like on other browsers > with Control + / Control -. Here is an issue on this topic: > > https://github.com/dillo-browser/dillo/issues/21 > > I have a patch that implements it by adding a zoom factor that > changes with Ctrl + and Ctrl -, but it doesn't work well in some > cases. Notice that the font_factor is not the same as "zooming" all > elements. I have tested your patch and it works pretty well, minus the image scaling issue you mentioned. One thing I will note however, on a TKL (ten key less) keyboard, there is no dedicated '+' key, so zooming in doesn't work. On a US layout for example, the key is =/+, but pressing Ctrl-Shift-= doesn't have the expected result. I changed the mapping in keys.cc to Ctrl-= and it works for me, but would vary for other localizations. Regards, Alex

May 4, 2024

Re: "Layout::resizeIdle calls" messages ignore show_msg=NO

by Kevin Koster

Rodrigo Arias <rodarima-Re5JQEeQqe8AvxtiuMwx3w(a)public.gmane.org> wrote: > On Fri, May 03, 2024 at 12:48:54PM +1000, Kevin Koster wrote: >>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. > > Yeah, there is no way to properly output messages from the dw module > (the layout renderer), as it doesn't link with the code that parses the > preferences, so it cannot access the "prefs.show_msg" variable to find > out if it should output messages or not. > > I will disable it for now by using _MSG() instead, and we can think of > something more elaborate later. Sounds good. The messages look like they'd mainly be useful to someone looking to to tweak the code and rebuild anyway.

May 4, 2024

Re: "Layout::resizeIdle calls" messages ignore show_msg=NO

by Rodrigo Arias

Hi, On Fri, May 03, 2024 at 12:48:54PM +1000, Kevin Koster wrote: >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. Yeah, there is no way to properly output messages from the dw module (the layout renderer), as it doesn't link with the code that parses the preferences, so it cannot access the "prefs.show_msg" variable to find out if it should output messages or not. I will disable it for now by using _MSG() instead, and we can think of something more elaborate later. Thanks, Rodrigo.

May 3, 2024

"Layout::resizeIdle calls" messages ignore show_msg=NO

by Kevin Koster

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.

May 3, 2024

Re: [PATCH] User defined new tab page

by Rodrigo Arias

On Thu, Apr 11, 2024 at 05:36:07PM +0200, a1ex(a)dismail.de wrote: > >> We may leave the value "about:blank" by default (and forbid ""), but >> then, when opening a new tab, if the new_tab_url matches >> "about:blank", we set it to NULL to leave the location empty, which >> follows the current behavior. Maybe, something like this? >> >> + if (!url && strcmp(URL_STR(prefs.new_tab_page), "about:blank") != >> 0) >> + url = prefs.new_tab_page; > >That does seem like the most elegant solution for now. Thanks! Related PR: https://github.com/dillo-browser/dillo/pull/147 Rodrigo.

May 2, 2024

Re: Feature idea: zoom buttons

by Rodrigo Arias

Hi, On Thu, May 02, 2024 at 09:53:39AM -0400, Charles E. Lehner wrote: >Sounds like a nice feature. >and/or as menu items > >On Wednesday, 1 May 2024 18:02:39 EDT, a1ex(a)dismail.de wrote: >>Hello, >> >>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. >>This can be especially visible if remote CSS is disabled, and/or you >>are using a portrait display. Maybe this can be partially mitigated by >>having zoom buttons in the toolbar. Beyond that, there are many other >>reasons why you might want to make the text larger or smaller, >>depending on the page and display configuration, accessibility needs, >>etc. It's not always practical to edit dillorc and restart for every >>page in question. I agree. >>I think one of the Dillo forks did it before. Can we just dynamically >>adjust the 'font_factor' setting? Any interest in this? I think we should implement a zoom control, like on other browsers with Control + / Control -. Here is an issue on this topic: https://github.com/dillo-browser/dillo/issues/21 I have a patch that implements it by adding a zoom factor that changes with Ctrl + and Ctrl -, but it doesn't work well in some cases. Notice that the font_factor is not the same as "zooming" all elements. For example, if you load the old website and try to zoom with Ctrl +, the top image is not scaled accordingly: $ dillo https://dillo-browser.github.io/old/index.html Here is the branch[1] and patch[2]: [1]:https://github.com/dillo-browser/dillo/compare/zoom-control [2]:https://github.com/dillo-browser/dillo/commit/bfa6dfae82887ba51749cf4b71… I think it would made more sense to scale the complete page, and not only the font, but that would require a bit more work. We would need this anyway to implement proper DPI scaling. Rodrigo.

May 2, 2024

Re: Feature idea: zoom buttons

by Charles E. Lehner

Sounds like a nice feature. and/or as menu items On Wednesday, 1 May 2024 18:02:39 EDT, a1ex(a)dismail.de wrote: > Hello, > > Sometimes the page text is not entirely wrapped to the browser > window, resulting in lines extending off screen, which is a pain. > This can be especially visible if remote CSS is disabled, and/or you > are using a portrait display. Maybe this can be partially mitigated by > having zoom buttons in the toolbar. Beyond that, there are many other > reasons why you might want to make the text larger or smaller, > depending on the page and display configuration, accessibility needs, > etc. It's not always practical to edit dillorc and restart for every > page in question. > > I think one of the Dillo forks did it before. Can we just dynamically > adjust the 'font_factor' setting? Any interest in this? > > Regards, > Alex

May 2, 2024

Feature idea: zoom buttons

by a1ex＠dismail.de

Hello, Sometimes the page text is not entirely wrapped to the browser window, resulting in lines extending off screen, which is a pain. This can be especially visible if remote CSS is disabled, and/or you are using a portrait display. Maybe this can be partially mitigated by having zoom buttons in the toolbar. Beyond that, there are many other reasons why you might want to make the text larger or smaller, depending on the page and display configuration, accessibility needs, etc. It's not always practical to edit dillorc and restart for every page in question. I think one of the Dillo forks did it before. Can we just dynamically adjust the 'font_factor' setting? Any interest in this? Regards, Alex

May 1, 2024

Re: <td> width attributes ignored

by Rodrigo Arias

>Thanks. This is caused by commit f5a0b6[1], which should be already >solved[2]. Reverting it fixes this specific problem, I'll add some >regression tests and see if it doesn't break anything else. > >[1]:https://github.com/dillo-browser/dillo/commit/f5a0b6030c2001e5a0fcacf813… >[2]:https://github.com/dillo-browser/dillo/commit/b0f6a3f055039c5c9c3ab65102… Merged in: https://github.com/dillo-browser/dillo/commit/b18496029c93a601646245adeb193… Rodrigo.

April 28, 2024

Re: Dillo not rendering HTML with comments before <!DOCTYPE>

by Rodrigo Arias

Hi, >> If you want to work on it, feel free to do so :-) > >I might have a go at it then. Nice :-) >> I pushed another patch that should fix this issue. It is caused >> primarily by the ".xhtml" extension not being recognized by the file >> plugin, which then tries to detect the doctype and fails in the same >> way, falling back to text/plain. > >All working well now, thanks again. Merged in: https://github.com/dillo-browser/dillo/commit/d9c506df8528c2db84d724048f9bc… Best, Rodrigo.

April 28, 2024

Re: Dillo not rendering HTML with comments before <!DOCTYPE>

by Kevin Koster

On Thu, 25 Apr 2024 21:36:04 +0200 Rodrigo Arias <rodarima(a)gmail.com> wrote: > We can improve the content detection to handle both HTML and > XML-style comments, but I prefer to defer it after the 3.1.0 release. > Websites shouldn't rely on the browser to guess the content type, it > should be stated in the HTTP header or the meta tag. So I don't > consider this a priority that should block the release for longer. Yes, that's reasonable. > If you want to work on it, feel free to do so :-) I might have a go at it then. > >I've built Dillo from that branch and pages on www.lemis.com now > >render correctly, thanks! If I save the homepage as lemis.xhtml it > >still shows as plain text when loaded with file://, though it is > >rendered if the comments before <!DOCTYPE> are removed or if the > >original file is saved as lemis.html. Not much of an issue, but it > >could cause confusion for someone. > > I pushed another patch that should fix this issue. It is caused > primarily by the ".xhtml" extension not being recognized by the file > plugin, which then tries to detect the doctype and fails in the same > way, falling back to text/plain. All working well now, thanks again.

April 27, 2024

Re: scroll_step description

by Rodrigo Arias

On Thu, Apr 25, 2024 at 09:52:50PM +0200, Rodrigo Arias wrote: >Thanks, I added them in this PR: > >https://github.com/dillo-browser/dillo/pull/142 Merged in: https://github.com/dillo-browser/dillo/commit/52110e1ea2a50e91e66bd04981103… Rodrigo.

April 26, 2024

Re: scroll_step description

by Rodrigo Arias

Hi, On Mon, Apr 22, 2024 at 09:38:19AM +1000, Kevin Koster wrote: >> Thanks, I agree. Could you provide a patch? > >OK, see the attached dillorc_scroll_step_description.patch (applied >directly to the file, eg. "patch dillo/dillorc < >dillorc_scroll_step_description.patch"). The patch also includes a fix >for a misspelling of "differentiates" in a later comment there. >I'd only add that a scroll_step is subtracted from the Pg. Up/Down >movement, as I've done in the other attached patch >(user_help_page_step.patch). >--- dillo/dillorc 2024-04-21 22:30:16.000000000 +1000 >+++ dillo_mod/dillorc 2024-04-21 23:22:36.666672639 +1000 >@@ -40,7 +40,10 @@ > # Set your default directory for download/save operations > #save_dir=/tmp > >-# Mouse wheel scroll step in pixels >+# Set the increment in pixels that the page is moved up/down with each input >+# from the mouse wheel, keyboard arrow keys, or scrollbar arrow buttons. >+# Page movement with the Page Up/Down keys is one scroll_step less than the >+# height of the visible page area. > #scroll_step=100 > > #------------------------------------------------------------------------- >@@ -89,7 +92,7 @@ > # If this is set to YES, all CSS size specifications for tables are > # adjusted so that all contents can be displayed. This is seperated > # from "adjust_min_width" so that it is able to mimic Firefox, which >-# differenciates between tables and, say, textblocks (in some cases). >+# differentiates between tables and, say, textblocks (in some cases). > #adjust_table_min_width=YES > > #------------------------------------------------------------------------- >--- dillo/doc/user_help.html 2024-04-21 23:20:19.319997475 +1000 >+++ dillo_mod/doc/user_help.html 2024-04-21 23:19:01.916659356 +1000 >@@ -177,7 +177,7 @@ > <li>Use the <code>Home</code> or <code>End</code> keys to jump to the top > or to the end of a page.</li> > <li>Use <code>PgUp</code> or <code>PgDn</code> to advance a whole >- page (window size).</li> >+ page (window size) minus one step.</li> > <li>Use the arrow keys to move the view a step in that > direction.</li> > <li>You can also use the <code>Space</code> key as <code>PgDn</code> and Thanks, I added them in this PR: https://github.com/dillo-browser/dillo/pull/142 Best, Rodrigo.

April 25, 2024

Re: Dillo not rendering HTML with comments before <!DOCTYPE>

by Rodrigo Arias

Hi, On Thu, Apr 25, 2024 at 09:23:38AM +1000, Kevin Koster wrote: >Thanks for the explanation, this also makes clearer an issue I had with >XHTML image indexes generated by ImageMagick Montage which were getting >(by an unusual sequence of events) the incorrect HTTP Content-Type type >of "text/xml" (and they don't contain a meta tag). They'd load properly >via file:// but show as text over http://. Now I know to ideally force >the HTTP Content-Type to "application/xhtml+xml" instead of "text/html" >which I used to fix the problem originally. For Dillo, "application/xhtml+xml" and "text/html" are handled by the same HTML parser, which later identifies which version of HTML/XHTML is the document, based on the doctype. The problem is failing to set the content type to any of those two, like when using "text/xml". AFIK, the proper content type for XHTML is "application/xhtml+xml", which should be set on the HTTP Content-Type header. >> Regarding the type guessing bug, I think I can improve it by assuming >> that if we find the "<!doctype html" string in the first 1024 bytes or >> so, it is an HTML-like type, but it incurrs in more overhead. > >But if it aborts that search upon encountering the first thing that >isn't "spaces, newlines, tabs, and comments", most text files will be >detected within the first few bytes. > >I'm not sure how that approach would work with ImageMagick image index >XHTML pages which start like this though: > <?xml version="1.0" encoding="US-ASCII"?> > <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" > "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> > >Example: >http://www.ombertech.com/cnk/dillo/STS-133_Pictures/photo_index.html > >I don't really understand how XHTML is supposed to work, and I don't >have time to learn, so perhaps I'm ignoring a distinction between >differet flavours of XHTML that can begin in different ways? Anyway I >like how ImageMagick image map pages are viewable in Dillo at the >moment. We can improve the content detection to handle both HTML and XML-style comments, but I prefer to defer it after the 3.1.0 release. Websites shouldn't rely on the browser to guess the content type, it should be stated in the HTTP header or the meta tag. So I don't consider this a priority that should block the release for longer. If you want to work on it, feel free to do so :-) >> So I think for now we can rely on the correction of "text/xhtml" to >> "application/xhtml+xml", which seems to work fine. I don't like adding >> quirks, but I will keep this one as it was already there. Here is the >> PR: >> >> https://github.com/dillo-browser/dillo/pull/140 > >I've built Dillo from that branch and pages on www.lemis.com now render >correctly, thanks! If I save the homepage as lemis.xhtml it still shows >as plain text when loaded with file://, though it is rendered if the >comments before <!DOCTYPE> are removed or if the original file is saved >as lemis.html. Not much of an issue, but it could cause confusion for >someone. I pushed another patch that should fix this issue. It is caused primarily by the ".xhtml" extension not being recognized by the file plugin, which then tries to detect the doctype and fails in the same way, falling back to text/plain. Best, Rodrigo.

April 25, 2024

Re: Dillo not rendering HTML with comments before <!DOCTYPE>

by Kevin Koster

On Thu, 25 Apr 2024 09:23:38 +1000 Kevin Koster <dillo(a)ombertech.com> wrote: > On Tue, 23 Apr 2024 23:29:45 +0200 > Rodrigo Arias <rodarima(a)gmail.com> wrote: > > Regarding the type guessing bug, I think I can improve it by > > assuming that if we find the "<!doctype html" string in the first > > 1024 bytes or so, it is an HTML-like type, but it incurrs in more > > overhead. > > But if it aborts that search upon encountering the first thing that > isn't "spaces, newlines, tabs, and comments", most text files will be > detected within the first few bytes. > > I'm not sure how that approach would work with ImageMagick image index > XHTML pages which start like this though: > <?xml version="1.0" encoding="US-ASCII"?> > <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" > "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> > > Example: > http://www.ombertech.com/cnk/dillo/STS-133_Pictures/photo_index.html > > I don't really understand how XHTML is supposed to work, and I don't > have time to learn, so perhaps I'm ignoring a distinction between > differet flavours of XHTML that can begin in different ways? Anyway I > like how ImageMagick image map pages are viewable in Dillo at the > moment. It seems that the text/html type can be valid for XHTML documents, and the relevent RFC 2854 has a section on recognising HTML and XHTML files: 5. Recognizing HTML files Almost all HTML files have the string "<html" or "<HTML" near the beginning of the file. Documents conformant to HTML 2.0, HTML 3.2 and HTML 4.0 will start with a DOCTYPE declaration "<!DOCTYPE HTML" near the beginning, before the "<html". These dialects are case insensitive. Files may start with white space, comments (introduced by "<!--" ), or processing instructions (introduced by "<?") prior to the DOCTYPE declaration. XHTML documents (optionally) start with an XML declaration which begins with "<?xml" and are required to have a DOCTYPE declaration "<!DOCTYPE html". https://www.ietf.org/rfc/rfc2854.txt Possibly old news for others, but it clears up some of my own XHTML-ignorant confusions. For Dillo it doesn't look like it would harm performance much to add detection of comments and "<? >" on top of the existing detection of whitespace before looking for tags that indicate HTML-compatible content in misc.c. For non-(X)HTML data it will usually only mean checking for '<' as well as whitespace before it finds a byte that shouldn't be in a HTML-compatible document before the first tag. If it does find a '<' first then it will be a little more complicated to check and skip following characters. But only XML documents would normally have much of that and yet still end up displayed as plain text like they are already, so it seems like that would be a rare (and anyway minimal) performance issue.

April 25, 2024

Re: Dillo not rendering HTML with comments before <!DOCTYPE>

by Kevin Koster

On Tue, 23 Apr 2024 23:29:45 +0200 Rodrigo Arias <rodarima(a)gmail.com> wrote: > On Sat, Apr 20, 2024 at 02:35:10PM +0200, Rodrigo Arias wrote: > >Yeah, the current detection mechanism in Dillo for content types is > >not very good. It searches for the doctype line at the beginning of > >the document[1] but it doesn't handle comments. > > > >[1]:https://github.com/dillo-browser/dillo/blob/v3.1.0-rc1/src/misc. > >c#L148 > > > >We should rely on the Content-Type provided by the server, or at > >least improve the detection. > > So, this is a tricky case. > > Dillo has several content types for a single document sorted by > priority, the first one set defines the content type of the document: > > 1. The "override type" used to override the type (highest priority) > 2. The "meta type" given by the <meta ... content="..."> tag in HTML > 3. The "http type" given by the HTTP Content-Type header > 4. The "guessed type" based on the document data (lowest priority) Thanks for the explanation, this also makes clearer an issue I had with XHTML image indexes generated by ImageMagick Montage which were getting (by an unusual sequence of events) the incorrect HTTP Content-Type type of "text/xml" (and they don't contain a meta tag). They'd load properly via file:// but show as text over http://. Now I know to ideally force the HTTP Content-Type to "application/xhtml+xml" instead of "text/html" which I used to fix the problem originally. > Regarding the type guessing bug, I think I can improve it by assuming > that if we find the "<!doctype html" string in the first 1024 bytes or > so, it is an HTML-like type, but it incurrs in more overhead. But if it aborts that search upon encountering the first thing that isn't "spaces, newlines, tabs, and comments", most text files will be detected within the first few bytes. I'm not sure how that approach would work with ImageMagick image index XHTML pages which start like this though: <?xml version="1.0" encoding="US-ASCII"?> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> Example: http://www.ombertech.com/cnk/dillo/STS-133_Pictures/photo_index.html I don't really understand how XHTML is supposed to work, and I don't have time to learn, so perhaps I'm ignoring a distinction between differet flavours of XHTML that can begin in different ways? Anyway I like how ImageMagick image map pages are viewable in Dillo at the moment. > So I think for now we can rely on the correction of "text/xhtml" to > "application/xhtml+xml", which seems to work fine. I don't like adding > quirks, but I will keep this one as it was already there. Here is the > PR: > > https://github.com/dillo-browser/dillo/pull/140 I've built Dillo from that branch and pages on www.lemis.com now render correctly, thanks! If I save the homepage as lemis.xhtml it still shows as plain text when loaded with file://, though it is rendered if the comments before <!DOCTYPE> are removed or if the original file is saved as lemis.html. Not much of an issue, but it could cause confusion for someone.

April 24, 2024

Re: Dillo not rendering HTML with comments before <!DOCTYPE>

by Rodrigo Arias

Hi, On Sat, Apr 20, 2024 at 02:35:10PM +0200, Rodrigo Arias wrote: >Hi, > >On Sat, Apr 20, 2024 at 02:00:05PM +1000, Kevin Koster wrote: >>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 > >Yeah, the current detection mechanism in Dillo for content types is >not very good. It searches for the doctype line at the beginning of >the document[1] but it doesn't handle comments. > >[1]:https://github.com/dillo-browser/dillo/blob/v3.1.0-rc1/src/misc.c#L148 > >We should rely on the Content-Type provided by the server, or at least >improve the detection. So, this is a tricky case. Dillo has several content types for a single document sorted by priority, the first one set defines the content type of the document: 1. The "override type" used to override the type (highest priority) 2. The "meta type" given by the <meta ... content="..."> tag in HTML 3. The "http type" given by the HTTP Content-Type header 4. The "guessed type" based on the document data (lowest priority) They all start set to NULL. At first, the server sends "text/html; charset=UTF-8" which defines the http type: > % curl -sI http://www.lemis.com/ | grep Content > Content-Type: text/html; charset=UTF-8 The guessed type is also wrongly set to "text/plain" due to the comments in the beginning which cause a mismatch of the "<!doctype". This is the *first bug*. As the document continues loading, the <meta> tag is found: > % curl -s http://www.lemis.com/ | grep Content > <meta http-equiv="Content-Type" content="text/xhtml; charset=utf-8"/> Which sets the meta type to "text/xhtml". So far we have this situation: override_type = NULL meta_type = "text/xhtml; charset=utf-8" http_type = "text/html; charset=UTF-8" guessed_type = "text/plain" While setting the meta type, there is also an special rule as a workaround for Doxygen pages, which checks if the the content type of the meta tag begins with "text/xhtml" (which it does) and if so sets the override type to the guessed type: https://github.com/dillo-browser/dillo/blob/a0151cbc86166731465b963ea3addb0… So the types are left as follows: override_type = "text/plain" meta_type = "text/xhtml; charset=utf-8" http_type = "text/html; charset=UTF-8" guessed_type = "text/plain" This causes the type of the document to be handled as "text/plain". The "text/xhtml" type should be defined as "application/xhtml+xml", as the W3 describes: https://www.w3.org/TR/xhtml-media-types/#media-types Which Dillo handles fine. So, I'm thinking in transforming the "text/xhtml" to "application/xhtml+xml", better than relying on the guessed type. The types end up being: override_type = "application/xhtml+xml; charset=utf-8" meta_type = "text/xhtml; charset=utf-8" http_type = "text/html; charset=UTF-8" guessed_type = "text/plain" That solves the problem. AFAIK, the "text/xhtml" is not standardized. It was mentioned in the XHTML 1.0 draft on February 1999: https://www.w3.org/TR/1999/WD-html-in-xml-19990224/#h-5.1.3 On March they raised concern about it: https://www.w3.org/TR/1999/WD-html-in-xml-19990304/ > There is one issue that is still mildly contentious within the working > group, and that we are especially interested in receiving comments on: > whether we should register a new Internet media type "text/xhtml". > > Very briefly the two opinions are: yes - that is the only way to > recognise the application type without accessing the resource; no - > all XML applications are going to have this problem, and the answer > isn't to register every single application. And on May it got removed: https://www.w3.org/TR/1999/xhtml1-19990505/ And is not part of the XHTML 1.0 standard: https://www.w3.org/TR/xhtml1/ So I don't think is should be ever used. Regarding the type guessing bug, I think I can improve it by assuming that if we find the "<!doctype html" string in the first 1024 bytes or so, it is an HTML-like type, but it incurrs in more overhead. So I think for now we can rely on the correction of "text/xhtml" to "application/xhtml+xml", which seems to work fine. I don't like adding quirks, but I will keep this one as it was already there. Here is the PR: https://github.com/dillo-browser/dillo/pull/140 I'll check with some Doxygen pages and see it they don't break anything. Interestingly, to this day they continue to generate documents with the wrong "text/xhtml" content type (since at least 13 years, based on the git blame): https://github.com/doxygen/doxygen/blame/78422d3905e57acebf0374feefafa6578d… I'll open an issue on their repo too. Best regards, Rodrigo.

April 23, 2024

Re: scroll_step description

by Kevin Koster

On Sat, 20 Apr 2024 14:19:32 +0200 Rodrigo Arias <rodarima(a)gmail.com> wrote: > On Sat, Apr 20, 2024 at 01:54:26PM +1000, Kevin Koster wrote: > >There's a new "scroll_step" option in the example configuration file > >for 3.1.0-rc1. The comment "Mouse wheel scroll step in pixels" > >suggests that this only affects the mouse wheel, but it also changes > >the distance the page moves when the arrow keys are pressed and the > >overlap of previous page content that's left when you press Page > >Up/Down. I think that's a little confusing, especially as the value > >has changed since the default behaviour in 3.0.5 (the old value > >seems to have been about 25). > > Thanks, I agree. Could you provide a patch? OK, see the attached dillorc_scroll_step_description.patch (applied directly to the file, eg. "patch dillo/dillorc < dillorc_scroll_step_description.patch"). The patch also includes a fix for a misspelling of "differentiates" in a later comment there. > Please consider reviewing the manual on that topic[1], in case some > parts need to be clarified too. > [1]:https://dillo-browser.github.io/user_help.html#scrolling I'd only add that a scroll_step is subtracted from the Pg. Up/Down movement, as I've done in the other attached patch (user_help_page_step.patch).

April 21, 2024