- Dillo-dev - lists.mailman3.com

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

by pastebin＠gmx.com

Hi i haven't had this problem since upgrading to fltk-1.3.9 On Sat, 8 Jun 2024 21:31:32 +0200 Rodrigo Arias <rodarima(a)gmail.com> wrote: > Hi, > > On Sat, Jun 08, 2024 at 10:04:40AM -0600, pastebin(a)gmx.com wrote: > >> Which version of Dillo and FLTK do you have? Cannot reproduce with > >> Dillo 3.1.1 and FLTK 1.3.9. > >> > >> I'm thinking it may be related to file access permissions, > > > >i'm thinking it has to do with 'accidentally hitting an arrow key > >before i want to type a file name to save' but nothing is reproducable > > I reviewed the code and it doesn't seem this is likely to be on Dillo > side, as we only call fl_file_chooser() of FLTK: > > https://github.com/dillo-browser/dillo/blob/e89a2293ebb3331dca46f5edf010823… > > Please report your FLTK version, as it may be already solved on 1.3.9 > and that could explain why I don't see it. > > Rodrigo. > _______________________________________________ > Dillo-dev mailing list -- dillo-dev(a)mailman3.com > To unsubscribe send an email to dillo-dev-leave(a)mailman3.com

June 22, 2024

Re: dialog box dimensions

by pastebin＠gmx.com

Hi it turns out this has nothing to do with dillo but a [transient] entry in the fluxbox 'apps' file takes care of it https://fluxboxwiki.github.io/category/howtos/en/Editing_the_apps_file.html http://fluxbox.org/help/man-fluxbox-apps.php right clicking on the dillo 'save page as' title bar and 'remember' options sets it up > > >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 > > 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). >

June 22, 2024

Re: HTTPS Proxy Support

by Rodrigo Arias

Hi, On Sat, Jun 22, 2024 at 09:43:00AM +1000, Kevin Koster wrote: >But the proxy approach allows old versions/binaries to keep working >too. If Dillo 3.0.5 had supported it, then the HTTPS issues from >lacking SNI support could have been worked around by running an >'old-style' HTTPS proxy with SNI support on localhost. A related term seems to be "reverse proxy": https://en.wikipedia.org/wiki/Reverse_proxy From the "Fun with Crypto Ancienne" post I understand that you want Dillo to get a HTTP or HTTPS URL and always perform a HTTP GET towards your proxy, as the Mosaic configuration suggests: > https 127.0.0.1 8765 http > http 127.0.0.1 8765 http Other that those old browsers, I don't think you can do this with any (relatively) modern tool. This is what Dillo is currently doing for https and http URLs: hop% http_proxy=http://localhost:1234 dillo http://www.google.com hop% nc -l 1234 GET http://www.google.com/ HTTP/1.1 Host: www.google.com User-Agent: Dillo/3.1.1 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Encoding: gzip, deflate DNT: 1 Referer: http://www.google.com/ Connection: keep-alive hop% http_proxy=http://localhost:1234 dillo https://www.google.com hop% nc -l 1234 CONNECT www.google.com:443 HTTP/1.1 Host: www.google.com:443 While for the latter you'll want: GET https://www.google.com/ HTTP/1.1 Host: www.google.com User-Agent: Dillo/3.1.1 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Encoding: gzip, deflate DNT: 1 Referer: https://www.google.com/ Connection: keep-alive You'll need to instruct Dillo to ignore the HTTPS handling and just treat it as an HTTP GET request to the proxy (using the HTTPS url), so no CONNECT is used. >Sure, or actually I'd suggest using a separate variable/option name >to set that proxy server because using "https_proxy" for both proxy >systems is what's already confused me now with Wget. Something >like "https_endpoint=[hostname]" maybe? I think I would have to see it implemented to determine what would be a good name that prevents users from accidentally misconfiguring it. Best, Rodrigo.

June 22, 2024

Re: HTTPS Proxy Support

by Kevin Koster

Rodrigo Arias <rodarima-Re5JQEeQqe8AvxtiuMwx3w(a)public.gmane.org> wrote: > On Thu, Jun 20, 2024 at 04:07:27PM +1000, Kevin Koster wrote: >>My content-modifying proxy application might be very niche, but I still >>think it would be more widely useful for people running Dillo on very >>old computers. Let me know whether it's something that might be accepted >>for Dillo even if I decide to try implementing it myself. > > Provided that those machines cannot deal with HTTPS traffic, I think is > a reasonable use case. I haven't had time to dig a bit more into this > issue to see if there is a way to make those old machines use TLS > instead Oh there is, the Crypto Ancienne TLS library is designed for this: https://github.com/classilla/cryanc I started work on supporting it for HTTPS in Dillo, and got far enough that I'm sure the library would work for it, though I didn't finish debugging my attempt. That was while Dillo 3.1 looked abandoned so I did it as a HTTPS DPI plug-in, which makes my work obsolete now. But the proxy approach allows old versions/binaries to keep working too. If Dillo 3.0.5 had supported it, then the HTTPS issues from lacking SNI support could have been worked around by running an 'old-style' HTTPS proxy with SNI support on localhost. > I won't oppose to it, but we probably want to ensure that we don't send > plain traffic to a proxy when browsing HTTPS pages by accident. We > should add an option like "allow_insecure_proxy" (false by default) or > similar, so it is harder to leak HTTPS traffic accidentally. Sure, or actually I'd suggest using a separate variable/option name to set that proxy server because using "https_proxy" for both proxy systems is what's already confused me now with Wget. Something like "https_endpoint=[hostname]" maybe?

June 21, 2024

Re: problem with compressed or encrypted url

by Rodrigo Arias

Hi, On Fri, Jun 21, 2024 at 09:52:06AM +1000, Kevin Koster wrote: >pastebin-KK0ffGbhmjU(a)public.gmane.org wrote: >> Hi >> >> someone please tell me what is wrong when i do >> >> dillo https://ubuntu.com/tutorials/configure-ssh-2fa#2-installing-and-configuring… >> >> it seems to be encrypted or compressed? > >It failed the first time for me, then trying a little later it >loads. In between I tried using "wget -S --spider" and the first >time the header showed it was compressed using Brotli compression: >"content-encoding: br" > >On subsequent tries it returned uncompressed data to Wget and >Dillo, which is correct since neither supports Brotli compression. >It appears that the originating Web server is mis-configured to >use Brotli compression even if the client doesn't announce support >for it. >[...] >The difference appears to be whether the page is served from a >cache server. The cache server still latter notices the browser's >Accept-Encoding header and doesn't use Brotli compression. Very good analysis, thanks :-) I reported the issue upstream: https://github.com/canonical/ubuntu.com/issues/13980 Best, Rodrigo.

June 21, 2024

Re: HTTPS Proxy Support

by Rodrigo Arias

Hi Kevin, On Thu, Jun 20, 2024 at 04:07:27PM +1000, Kevin Koster wrote: >On Thu, 20 Jun 2024 10:03:59 +1000 >"Kevin Koster" <dillo(a)ombertech.com> wrote: > >> Rodrigo Arias <rodarima-Re5JQEeQqe8AvxtiuMwx3w(a)public.gmane.org> >> wrote: >> > However, if you start Dillo from a shell where the http_proxy >> > variable is set in the environment, I would imagine it would be >> > already picked by Dillo and the internal wget command. The dpid >> > daemon has to start from this shell, so you should do a "dpidc stop" >> > command before to ensure it. >> >> I'm not sure if we're on the same page, Wget supports http_proxy >> and https_proxy environment variables. The former may or may not >> tunnel HTTPS requests through a Web proxy, but that's not what I >> want since then the proxy can't manipulate the data and the client >> needs to handle the encryption. https_proxy with Wget uses the >> proxy to do all the encryption and therefore those issues don't >> apply. More browsers support the HTTPS tunneling proxy feature, >> but that doesn't achieve anything that I'm interested in >> personally. > >I did some tests and yes the https_proxy environment variable is picked >up by Wget for the downloads DPI. It doesn't affect Dillo itself. The >http_proxy environment variable is picked up by Dillo, but as I say that >doesn't do what I want with Dillo or Wget. > >It appears that GNU Wget's behaviour has changed. Newer versions _do_ >try to tunnel the HTTPS connection through the proxy set to https_proxy >(not what I want), whereas older versions ask that proxy to establish >the HTTPS connection and send data back unencrypted (which is what I >want). So I picked a bad example with Wget. See that blog post for other >examples like Lynx, but I haven't tried them myself. > >I can't find this change in the Wget changelog. One version that works >as I intend it to is GNU Wget 1.9, circa 2003. Looking through the Wget >mailing list archives it seems like many people either considered the >old behaviour a bug or a useless feature, so I may be swimming against >the tide. > >My content-modifying proxy application might be very niche, but I still >think it would be more widely useful for people running Dillo on very >old computers. Let me know whether it's something that might be accepted >for Dillo even if I decide to try implementing it myself. > >Sorry for the confusion. Provided that those machines cannot deal with HTTPS traffic, I think is a reasonable use case. I haven't had time to dig a bit more into this issue to see if there is a way to make those old machines use TLS instead, which I think it would be preferred. I won't oppose to it, but we probably want to ensure that we don't send plain traffic to a proxy when browsing HTTPS pages by accident. We should add an option like "allow_insecure_proxy" (false by default) or similar, so it is harder to leak HTTPS traffic accidentally. In any case, support for https_proxy should be added to Dillo first. Best, Rodrigo.

June 21, 2024

Re: problem with compressed or encrypted url

by pastebin＠gmx.com

Hi Kevin, Thanks - for spending the time figuring this out - it is interesting what you did - i never would have imagined it was 'brotli and a misconfigured server' it never came through uncompressed here - even after a few attempts - i wonder what someone looking at the logs thougth about - so many multiple loadings of a url about secureing sshd lol brotli appears to be a google invention - i wonder about how it got into a misconfigured server :) if it ever comes up for a vote - i vote no to include brotli into dillo ;) On Fri, 21 Jun 2024 09:52:06 +1000 "Kevin Koster" <dillo(a)ombertech.com> wrote: > pastebin-KK0ffGbhmjU(a)public.gmane.org wrote: > > Hi > > > > someone please tell me what is wrong when i do > > > > dillo https://ubuntu.com/tutorials/configure-ssh-2fa#2-installing-and-configuring… > > > > it seems to be encrypted or compressed? > > It failed the first time for me, then trying a little later it > loads. In between I tried using "wget -S --spider" and the first > time the header showed it was compressed using Brotli compression: > "content-encoding: br" > > On subsequent tries it returned uncompressed data to Wget and > Dillo, which is correct since neither supports Brotli compression. > It appears that the originating Web server is mis-configured to > use Brotli compression even if the client doesn't announce support > for it. > > I found another page on the Ubuntu site where the problem still > happens for me: > > ---- > $ wget --spider -S https://ubuntu.com/navigation > Spider mode enabled. Check if remote file exists. > --2024-06-21 09:41:41-- https://ubuntu.com/navigation > Resolving ubuntu.com... 185.125.190.20, 185.125.190.29, 185.125.190.21, ... > Connecting to ubuntu.com|185.125.190.20|:443... connected. > HTTP request sent, awaiting response... > HTTP/1.1 200 > server: nginx/1.14.0 (Ubuntu) > date: Thu, 20 Jun 2024 23:41:14 GMT > content-type: text/html; charset=utf-8 > x-view-name: webapp.views.navigation_nojs > x-clacks-overhead: GNU Terry Pratchett > permissions-policy: interest-cohort=() > cache-control: max-age=60, stale-while-revalidate=86400, stale-if-error=300 > x-frame-options: SAMEORIGIN > x-content-type-options: NOSNIFF > x-vcs-revision: 1718884808-1dd74d9 > x-request-id: c211f00fd2212b0b8771952d7fa04558 > strict-transport-security: max-age=15724800 > link: <https://assets.ubuntu.com>; rel=preconnect; crossorigin, <https://assets.ubuntu.com>; rel=preconnect, <https://res.cloudinary.com>; rel=preconnect > content-encoding: br > x-cache-status: STALE from content-cache-il3/0 > Length: unspecified [text/html] > Remote file exists and could contain further links, > but recursion is disabled -- not retrieving. > ---- > > After retrying a few times I got an unencrypted response: > > ---- > $ wget --spider -S https://ubuntu.com/navigation > Spider mode enabled. Check if remote file exists. > --2024-06-21 09:46:12-- https://ubuntu.com/navigation > Resolving ubuntu.com... 185.125.190.21, 185.125.190.29, 185.125.190.20, ... > Connecting to ubuntu.com|185.125.190.21|:443... connected. > HTTP request sent, awaiting response... > HTTP/1.1 200 > server: nginx/1.14.0 (Ubuntu) > date: Thu, 20 Jun 2024 23:45:45 GMT > content-type: text/html; charset=utf-8 > content-length: 202990 > x-view-name: webapp.views.navigation_nojs > x-clacks-overhead: GNU Terry Pratchett > permissions-policy: interest-cohort=() > cache-control: max-age=60, stale-while-revalidate=86400, stale-if-error=300 > x-frame-options: SAMEORIGIN > x-content-type-options: NOSNIFF > x-vcs-revision: 1718884808-1dd74d9 > x-request-id: 67baf729cf4344e46b689b28c5efb56f > strict-transport-security: max-age=15724800 > link: <https://assets.ubuntu.com>; rel=preconnect; crossorigin, <https://assets.ubuntu.com>; rel=preconnect, <https://res.cloudinary.com>; rel=preconnect > x-cache-status: HIT from content-cache-il3/1 > accept-ranges: bytes > Length: 202990 (198K) [text/html] > Remote file exists and could contain further links, > but recursion is disabled -- not retrieving. > ---- > > The difference appears to be whether the page is served from a > cache server. The cache server still latter notices the browser's > Accept-Encoding header and doesn't use Brotli compression. > > While checking docs for the headers, I found this page has the same > problem (again in both Dillo and Wget): > > ---- > $ wget -S --spider --compression=gzip https://http.dev/compression > Spider mode enabled. Check if remote file exists. > --2024-06-21 09:30:10-- https://http.dev/compression > Resolving http.dev... 34.120.39.70 > Connecting to http.dev|34.120.39.70|:443... connected. > HTTP request sent, awaiting response... > HTTP/1.1 200 OK > content-type: text/html; charset=utf-8 > strict-transport-security: max-age=63072000; includeSubDomains; preload > pragma: public > cache-control: public, max-age=86400 > x-content-type-options: nosniff > x-frame-options: SAMEORIGIN > x-ua-compatible: IE=Edge,chrome=1 > x-xss-protection: 1; mode=block > vary: Accept-Encoding > x-versionid: 8Bp0x4p9 > x-production: True > link: <https://http.dev/css/app.min.css?v=8Bp0x4p9>; rel="preload"; as="style" > x-request-id: fc33d19c-441a-4fab-ae1b-113e5e9028f5 > content-encoding: br > x-cloud-trace-context: a7d7fda8062ff6c0a9a86187afcacecb;o=1 > Content-Length: 8989 > date: Thu, 20 Jun 2024 23:29:42 GMT > server: Google Frontend > via: 1.1 google, 1.1 google > Alt-Svc: h3=":443"; ma=2592000,h3-29=":443"; ma=2592000 > Length: 8989 (8.8K) [text/html] > Remote file exists and could contain further links, > but recursion is disabled -- not retrieving. > ---- > _______________________________________________ > Dillo-dev mailing list -- dillo-dev(a)mailman3.com > To unsubscribe send an email to dillo-dev-leave(a)mailman3.com

June 21, 2024

Re: problem with compressed or encrypted url

by Kevin Koster

pastebin-KK0ffGbhmjU(a)public.gmane.org wrote: > Hi > > someone please tell me what is wrong when i do > > dillo https://ubuntu.com/tutorials/configure-ssh-2fa#2-installing-and-configuring… > > it seems to be encrypted or compressed? It failed the first time for me, then trying a little later it loads. In between I tried using "wget -S --spider" and the first time the header showed it was compressed using Brotli compression: "content-encoding: br" On subsequent tries it returned uncompressed data to Wget and Dillo, which is correct since neither supports Brotli compression. It appears that the originating Web server is mis-configured to use Brotli compression even if the client doesn't announce support for it. I found another page on the Ubuntu site where the problem still happens for me: ---- $ wget --spider -S https://ubuntu.com/navigation Spider mode enabled. Check if remote file exists. --2024-06-21 09:41:41-- https://ubuntu.com/navigation Resolving ubuntu.com... 185.125.190.20, 185.125.190.29, 185.125.190.21, ... Connecting to ubuntu.com|185.125.190.20|:443... connected. HTTP request sent, awaiting response... HTTP/1.1 200 server: nginx/1.14.0 (Ubuntu) date: Thu, 20 Jun 2024 23:41:14 GMT content-type: text/html; charset=utf-8 x-view-name: webapp.views.navigation_nojs x-clacks-overhead: GNU Terry Pratchett permissions-policy: interest-cohort=() cache-control: max-age=60, stale-while-revalidate=86400, stale-if-error=300 x-frame-options: SAMEORIGIN x-content-type-options: NOSNIFF x-vcs-revision: 1718884808-1dd74d9 x-request-id: c211f00fd2212b0b8771952d7fa04558 strict-transport-security: max-age=15724800 link: <https://assets.ubuntu.com>; rel=preconnect; crossorigin, <https://assets.ubuntu.com>; rel=preconnect, <https://res.cloudinary.com>; rel=preconnect content-encoding: br x-cache-status: STALE from content-cache-il3/0 Length: unspecified [text/html] Remote file exists and could contain further links, but recursion is disabled -- not retrieving. ---- After retrying a few times I got an unencrypted response: ---- $ wget --spider -S https://ubuntu.com/navigation Spider mode enabled. Check if remote file exists. --2024-06-21 09:46:12-- https://ubuntu.com/navigation Resolving ubuntu.com... 185.125.190.21, 185.125.190.29, 185.125.190.20, ... Connecting to ubuntu.com|185.125.190.21|:443... connected. HTTP request sent, awaiting response... HTTP/1.1 200 server: nginx/1.14.0 (Ubuntu) date: Thu, 20 Jun 2024 23:45:45 GMT content-type: text/html; charset=utf-8 content-length: 202990 x-view-name: webapp.views.navigation_nojs x-clacks-overhead: GNU Terry Pratchett permissions-policy: interest-cohort=() cache-control: max-age=60, stale-while-revalidate=86400, stale-if-error=300 x-frame-options: SAMEORIGIN x-content-type-options: NOSNIFF x-vcs-revision: 1718884808-1dd74d9 x-request-id: 67baf729cf4344e46b689b28c5efb56f strict-transport-security: max-age=15724800 link: <https://assets.ubuntu.com>; rel=preconnect; crossorigin, <https://assets.ubuntu.com>; rel=preconnect, <https://res.cloudinary.com>; rel=preconnect x-cache-status: HIT from content-cache-il3/1 accept-ranges: bytes Length: 202990 (198K) [text/html] Remote file exists and could contain further links, but recursion is disabled -- not retrieving. ---- The difference appears to be whether the page is served from a cache server. The cache server still latter notices the browser's Accept-Encoding header and doesn't use Brotli compression. While checking docs for the headers, I found this page has the same problem (again in both Dillo and Wget): ---- $ wget -S --spider --compression=gzip https://http.dev/compression Spider mode enabled. Check if remote file exists. --2024-06-21 09:30:10-- https://http.dev/compression Resolving http.dev... 34.120.39.70 Connecting to http.dev|34.120.39.70|:443... connected. HTTP request sent, awaiting response... HTTP/1.1 200 OK content-type: text/html; charset=utf-8 strict-transport-security: max-age=63072000; includeSubDomains; preload pragma: public cache-control: public, max-age=86400 x-content-type-options: nosniff x-frame-options: SAMEORIGIN x-ua-compatible: IE=Edge,chrome=1 x-xss-protection: 1; mode=block vary: Accept-Encoding x-versionid: 8Bp0x4p9 x-production: True link: <https://http.dev/css/app.min.css?v=8Bp0x4p9>; rel="preload"; as="style" x-request-id: fc33d19c-441a-4fab-ae1b-113e5e9028f5 content-encoding: br x-cloud-trace-context: a7d7fda8062ff6c0a9a86187afcacecb;o=1 Content-Length: 8989 date: Thu, 20 Jun 2024 23:29:42 GMT server: Google Frontend via: 1.1 google, 1.1 google Alt-Svc: h3=":443"; ma=2592000,h3-29=":443"; ma=2592000 Length: 8989 (8.8K) [text/html] Remote file exists and could contain further links, but recursion is disabled -- not retrieving. ----

June 20, 2024

problem with compressed or encrypted url

by pastebin＠gmx.com

Hi someone please tell me what is wrong when i do dillo https://ubuntu.com/tutorials/configure-ssh-2fa#2-installing-and-configuring… it seems to be encrypted or compressed? i can get it with curl okay and then dillo on the resulting html is good

June 20, 2024

Re: HTTPS Proxy Support

by Kevin Koster

On Thu, 20 Jun 2024 10:03:59 +1000 "Kevin Koster" <dillo(a)ombertech.com> wrote: > Rodrigo Arias <rodarima-Re5JQEeQqe8AvxtiuMwx3w(a)public.gmane.org> > wrote: > > However, if you start Dillo from a shell where the http_proxy > > variable is set in the environment, I would imagine it would be > > already picked by Dillo and the internal wget command. The dpid > > daemon has to start from this shell, so you should do a "dpidc stop" > > command before to ensure it. > > I'm not sure if we're on the same page, Wget supports http_proxy > and https_proxy environment variables. The former may or may not > tunnel HTTPS requests through a Web proxy, but that's not what I > want since then the proxy can't manipulate the data and the client > needs to handle the encryption. https_proxy with Wget uses the > proxy to do all the encryption and therefore those issues don't > apply. More browsers support the HTTPS tunneling proxy feature, > but that doesn't achieve anything that I'm interested in > personally. I did some tests and yes the https_proxy environment variable is picked up by Wget for the downloads DPI. It doesn't affect Dillo itself. The http_proxy environment variable is picked up by Dillo, but as I say that doesn't do what I want with Dillo or Wget. It appears that GNU Wget's behaviour has changed. Newer versions _do_ try to tunnel the HTTPS connection through the proxy set to https_proxy (not what I want), whereas older versions ask that proxy to establish the HTTPS connection and send data back unencrypted (which is what I want). So I picked a bad example with Wget. See that blog post for other examples like Lynx, but I haven't tried them myself. I can't find this change in the Wget changelog. One version that works as I intend it to is GNU Wget 1.9, circa 2003. Looking through the Wget mailing list archives it seems like many people either considered the old behaviour a bug or a useless feature, so I may be swimming against the tide. My content-modifying proxy application might be very niche, but I still think it would be more widely useful for people running Dillo on very old computers. Let me know whether it's something that might be accepted for Dillo even if I decide to try implementing it myself. Sorry for the confusion.

June 20, 2024

Re: HTTPS Proxy Support

by Kevin Koster

Rodrigo Arias <rodarima-Re5JQEeQqe8AvxtiuMwx3w(a)public.gmane.org> wrote: > On Wed, Jun 19, 2024 at 01:15:52PM +1000, Kevin Koster wrote: >>As mentioned in the discussion about link handlers and webpage >>content rewriting, I once looked into using Web proxy software to >>do the latter. One complication was that Dillo doesn't support >>a feature equivalent to setting the https_proxy environment >>variable for GNU Wget, whereby the proxy acts as the HTTPS >>endpoint for encrypted Web server connections and sends the data >>back to the browser unencrypted. This allows the proxy to >>manipulate page content without needing to transform HTTP requests >>into HTTPS requests and rewrite https:// in page URLs as http://. > > This should be easy to do, as Dillo can forward the http_proxy variable > to the wget command. > > However, if you start Dillo from a shell where the http_proxy variable > is set in the environment, I would imagine it would be already picked by > Dillo and the internal wget command. The dpid daemon has to start from > this shell, so you should do a "dpidc stop" command before to ensure it. I'm not sure if we're on the same page, Wget supports http_proxy and https_proxy environment variables. The former may or may not tunnel HTTPS requests through a Web proxy, but that's not what I want since then the proxy can't manipulate the data and the client needs to handle the encryption. https_proxy with Wget uses the proxy to do all the encryption and therefore those issues don't apply. More browsers support the HTTPS tunneling proxy feature, but that doesn't achieve anything that I'm interested in personally. Anyway Wget https_proxy is only a common example of the feature (which is described in more detail at the blog link), I'm not so much interested in using it when Dillo launches Wget for downloads, but for data retrieved by Dillo itself to display within the browser. >>Besides proxies, for old computers where performance or available >>TLS library versions prevent using modern encryption, this also >>allows the encrypted communications to be offloaded to more modern >>computer. Or using a different encryption library that's optimised >>for old computers, as described here: >> >>http://oldvcr.blogspot.com/2020/11/fun-with-crypto-ancienne-tls-for.html >> >>For using this with old computers, it would be ideal if the HTTPS >>proxy feature was available even if Dillo is compiled without >>linking to a TLS library. Also the https_proxy environment variable >>should be set to the HTTPS proxy hostname when running Wget for >>downloads so that it applies to those as well. > > Sounds doable, but I would have to review how the HTTPS traffic is > handled in Dillo when a proxy is present. I did look into this with Dillo 3.0.5 and I'm confident this HTTPS proxy feature wasn't supported already there, but I never worked out exactly where the feature would fit into that code (which is likely quite different now anyway since moving out of the DPI environment).

June 20, 2024

Re: Option to define external link handler

by Kevin Koster

Rodrigo Arias <rodarima-Re5JQEeQqe8AvxtiuMwx3w(a)public.gmane.org> wrote: > On Wed, Jun 19, 2024 at 10:03:20AM +1000, Kevin Koster wrote: >>This mechanism might suit an idea I've had to do remote downscaling >>of extremely large images, which are increasingly being included in >>web pages. The script would send a list of URLs in all <img> tags >>within the HTML to a remote server (eg. on a VPS), or ideally just >>the ones for large image files, then rewrite the URLs in the HTML >>to point to the remote server where the converted images are >>available over HTTP/S. > > You can create a script that rewrites the <img> src attribute > > <img src="https://foo.com/img1.png"> > > To point to an endpoint of your server: > > <img src="https://yourserver.com/downscale?url=https://foo.com/img1.png"> Yes that would work too, however the idea of sending a URL list was that it allows my server to re-use the HTTPS connection to the image host server while downloading lots of images for a webpage, whereas the way you have it each image request by my server would be a new HTTPS connection, and therefore potentially slower. It's a minor difference though. > And then in the server you simply downscale it. Here is how you could do > it with rules: > > # Script that would rewrite images to a server for downscaling > action downscale filter 'rewrite-img.sh' > define mime header 'Content-Type' > match mime 'text/html' action downscale That should work. I would personally find it clearer to read if there was a character indicating assignment values, since this would make it obvious which words are commands and which are arguments. Such as: # Script that would rewrite images to a server for downscaling action downscale filter='rewrite-img.sh' define mime header='Content-Type' match mime='text/html' action=downscale Using "action" as an argument to "match" as well as the name of a command might still be a little confusing. >>Or a deeper approach would be to apply the same approach as this >>rewrite engine to binary content as well, and have Dillo do it >>transparently via 'rewrite'/convert rules for image MIME types. >>Then the HTML would stay the same and Dillo would trigger a command >>that requested a downscaled image from the converter server instead >>of the original image's server. That would be more elegant, but >>expands the scope of your proposed system a little. > > Rewriting the binary image directly would be possible, but then you > would have wasted the bandwidth bringing it to Dillo, and now you have > to send it to the server to downscale it. No the idea is to reduce the bandwidth usage on Dillo's connection, so for this approach Dillo would have to abort the connection to the image server if the image size was over the limit and fetch it from the script instead, which might do: wget -q -O - "https://yourserver.com/downscale?url=https://foo.com/img1.png" A way to get Dillo to take the replacement URL from the script would be better, but I suspect that would make this system more complicated to implement because then state matters between different connections. Granted I've lost the ability to re-use the HTTPS connection at my server with this approach. I like how it wouldn't affect the performance of fetching small images by waiting for them to be needlessly downloaded by my server first though, which would generally be a bigger advantage overall. Most images are still small enough that I wouldn't down-scale them, just the 1MB+ ones would get that treatment. The surprise 10MB+ ones are the real evil, and just the option to block these outright (abort the connection and don't run any script) would be better than nothing. To complicate things further, it would be good to have a right-click menu option to bypass this rule and allow fetching the full-size image. Alternatively an external handler could be assigned (via the earlier-discussed mechanism) to a script that downloads and opens the image URL in an external image viewer, which might actually be better to use for that. > In any case, imagine you want to downscale it locally anyway. Here is > how I can think about it: > > # Script that would downscale an image and write to stdout > action downscale filter 'downscale-img.sh' > > # Define headers from the HTTP content with shorter names > define mime header 'Content-Type' > define size header 'Content-Length' > > # Downscale big images > match mime =~ 'image/.*' and size > 10K action downscale > > Notice that this can be triggered for any image, not only ones provided > via HTTP/HTTPS, but also via other protocols like gemini that are > adapted to speak HTTP and also provide a Content-Length header. > > I added the =~ and > operators, as the former would match a regex and the > latter will use a numeric comparator. You can assume that the default if > the header is not present is to make any comparison fail. > > I have also added the "define" keyword to define properties like "mime" or > "size" which are parsed from the HTTP headers and are shorter and easier > to write. That looks good. Maybe I'd find it clearer without the whitespace between operators as with my '=' example above. >>Maybe since it still requires a remote Web server this problem >>would be better solved via a Web proxy (I did look into Squid >>before, but drowned in confusing documentation). But I just thought >>I'd mention it as an example of a more complex usage for this >>proposed rewrite system. > > But then you will need to pass all the traffic through the server so it > performs the substitution there. > > Another solution which may be better is to mark from Dillo which > requests are being done from img elements (filtering them before going > to the network). > > If Dillo marks those requests in the HTTP headers for example, then you > could do: > > # Script that transforms image HTTP requests to a server that > # downscales the image > action downscale filter 'downscale-req.sh' > > define source header 'Dillo-Request-Source' > > # Downscale images comming from <img> elements > match source 'img' action downscale Yes, that's neat. > This would have the benefit that Dillo already performs the parsing of > the HTML for you, and only the images that are loaded are passed to the > downscaling server. Additionally, cookies would be sent in the HTTP > request, so you can access login protected images this way too. Good point, although for my usage login protected images wouldn't be much of a concern.

June 19, 2024

Re: HTTPS Proxy Support

by Rodrigo Arias

Hi, On Wed, Jun 19, 2024 at 01:15:52PM +1000, Kevin Koster wrote: >As mentioned in the discussion about link handlers and webpage >content rewriting, I once looked into using Web proxy software to >do the latter. One complication was that Dillo doesn't support >a feature equivalent to setting the https_proxy environment >variable for GNU Wget, whereby the proxy acts as the HTTPS >endpoint for encrypted Web server connections and sends the data >back to the browser unencrypted. This allows the proxy to >manipulate page content without needing to transform HTTP requests >into HTTPS requests and rewrite https:// in page URLs as http://. This should be easy to do, as Dillo can forward the http_proxy variable to the wget command. However, if you start Dillo from a shell where the http_proxy variable is set in the environment, I would imagine it would be already picked by Dillo and the internal wget command. The dpid daemon has to start from this shell, so you should do a "dpidc stop" command before to ensure it. >Besides proxies, for old computers where performance or available >TLS library versions prevent using modern encryption, this also >allows the encrypted communications to be offloaded to more modern >computer. Or using a different encryption library that's optimised >for old computers, as described here: > >http://oldvcr.blogspot.com/2020/11/fun-with-crypto-ancienne-tls-for.html > >For using this with old computers, it would be ideal if the HTTPS >proxy feature was available even if Dillo is compiled without >linking to a TLS library. Also the https_proxy environment variable >should be set to the HTTPS proxy hostname when running Wget for >downloads so that it applies to those as well. Sounds doable, but I would have to review how the HTTPS traffic is handled in Dillo when a proxy is present. Best, Rodrigo.

June 19, 2024

Re: Option to define external link handler

by Rodrigo Arias

Hi, On Wed, Jun 19, 2024 at 10:03:20AM +1000, Kevin Koster wrote: >> Notice that the HTTP content can be compressed. So, for example, this >> simple rewrite script: >> >> #!/bin/sh >> sed 's_www.youtube.com_inv.vern.cc_g' >> >> Would only work well in the SED node *after* the HTTP content is >> uncompressed and the headers removed. The rewrite rules should indicate >> in which position of the chain they apply. > >This mechanism might suit an idea I've had to do remote downscaling >of extremely large images, which are increasingly being included in >web pages. The script would send a list of URLs in all <img> tags >within the HTML to a remote server (eg. on a VPS), or ideally just >the ones for large image files, then rewrite the URLs in the HTML >to point to the remote server where the converted images are >available over HTTP/S. You can create a script that rewrites the <img> src attribute <img src="https://foo.com/img1.png"> To point to an endpoint of your server: <img src="https://yourserver.com/downscale?url=https://foo.com/img1.png"> And then in the server you simply downscale it. Here is how you could do it with rules: # Script that would rewrite images to a server for downscaling action downscale filter 'rewrite-img.sh' define mime header 'Content-Type' match mime 'text/html' action downscale >Or a deeper approach would be to apply the same approach as this >rewrite engine to binary content as well, and have Dillo do it >transparently via 'rewrite'/convert rules for image MIME types. >Then the HTML would stay the same and Dillo would trigger a command >that requested a downscaled image from the converter server instead >of the original image's server. That would be more elegant, but >expands the scope of your proposed system a little. Rewriting the binary image directly would be possible, but then you would have wasted the bandwidth bringing it to Dillo, and now you have to send it to the server to downscale it. You probably want to use the previous approach for this case. In any case, imagine you want to downscale it locally anyway. Here is how I can think about it: # Script that would downscale an image and write to stdout action downscale filter 'downscale-img.sh' # Define headers from the HTTP content with shorter names define mime header 'Content-Type' define size header 'Content-Length' # Downscale big images match mime =~ 'image/.*' and size > 10K action downscale Notice that this can be triggered for any image, not only ones provided via HTTP/HTTPS, but also via other protocols like gemini that are adapted to speak HTTP and also provide a Content-Length header. I added the =~ and > operators, as the former would match a regex and the latter will use a numeric comparator. You can assume that the default if the header is not present is to make any comparison fail. I have also added the "define" keyword to define properties like "mime" or "size" which are parsed from the HTTP headers and are shorter and easier to write. >Maybe since it still requires a remote Web server this problem >would be better solved via a Web proxy (I did look into Squid >before, but drowned in confusing documentation). But I just thought >I'd mention it as an example of a more complex usage for this >proposed rewrite system. But then you will need to pass all the traffic through the server so it performs the substitution there. Another solution which may be better is to mark from Dillo which requests are being done from img elements (filtering them before going to the network). If Dillo marks those requests in the HTTP headers for example, then you could do: # Script that transforms image HTTP requests to a server that # downscales the image action downscale filter 'downscale-req.sh' define source header 'Dillo-Request-Source' # Downscale images comming from <img> elements match source 'img' action downscale This would have the benefit that Dillo already performs the parsing of the HTML for you, and only the images that are loaded are passed to the downscaling server. Additionally, cookies would be sent in the HTTP request, so you can access login protected images this way too. Working on these examples is very helpful to design the rule system, so feel free to mention more cases. Best, Rodrigo.

June 19, 2024

HTTPS Proxy Support

by Kevin Koster

As mentioned in the discussion about link handlers and webpage content rewriting, I once looked into using Web proxy software to do the latter. One complication was that Dillo doesn't support a feature equivalent to setting the https_proxy environment variable for GNU Wget, whereby the proxy acts as the HTTPS endpoint for encrypted Web server connections and sends the data back to the browser unencrypted. This allows the proxy to manipulate page content without needing to transform HTTP requests into HTTPS requests and rewrite https:// in page URLs as http://. Besides proxies, for old computers where performance or available TLS library versions prevent using modern encryption, this also allows the encrypted communications to be offloaded to more modern computer. Or using a different encryption library that's optimised for old computers, as described here: http://oldvcr.blogspot.com/2020/11/fun-with-crypto-ancienne-tls-for.html For using this with old computers, it would be ideal if the HTTPS proxy feature was available even if Dillo is compiled without linking to a TLS library. Also the https_proxy environment variable should be set to the HTTPS proxy hostname when running Wget for downloads so that it applies to those as well.

June 19, 2024

Re: Option to define external link handler

by Kevin Koster

Rodrigo Arias <rodarima-Re5JQEeQqe8AvxtiuMwx3w(a)public.gmane.org> wrote: > The solution with the new design would involve: > > 1) Open a "gemini:" link > 2) The request is routed to the gemini: dpi handler (like now) > 3) The gemini plugin returns the .gmi file as-is as an HTTP response, > instead of converting it to HTML > 4) The .gmi mime type matches a rewrite rule and is rewritten into HTML > in the SED node. > > Now, if we open a .gmi via HTTP: > > 1) Open a "https:" link > 2) The request is routed to the usual HTTP/IO/TLS chain > 3) The HTTP server returns the .gmi file as-is as an HTTP response. > 4) The .gmi mime type matches a rewrite rule, and is rewritten into HTML > in the SED node. > > Notice that the HTTP content can be compressed. So, for example, this > simple rewrite script: > > #!/bin/sh > sed 's_www.youtube.com_inv.vern.cc_g' > > Would only work well in the SED node *after* the HTTP content is > uncompressed and the headers removed. The rewrite rules should indicate > in which position of the chain they apply. This mechanism might suit an idea I've had to do remote downscaling of extremely large images, which are increasingly being included in web pages. The script would send a list of URLs in all <img> tags within the HTML to a remote server (eg. on a VPS), or ideally just the ones for large image files, then rewrite the URLs in the HTML to point to the remote server where the converted images are available over HTTP/S. Or a deeper approach would be to apply the same approach as this rewrite engine to binary content as well, and have Dillo do it transparently via 'rewrite'/convert rules for image MIME types. Then the HTML would stay the same and Dillo would trigger a command that requested a downscaled image from the converter server instead of the original image's server. That would be more elegant, but expands the scope of your proposed system a little. Maybe since it still requires a remote Web server this problem would be better solved via a Web proxy (I did look into Squid before, but drowned in confusing documentation). But I just thought I'd mention it as an example of a more complex usage for this proposed rewrite system.

June 19, 2024

Re: Option to define external link handler

by Rodrigo Arias

Hi Alex, On Tue, Jun 18, 2024 at 03:28:20PM +0200, a1ex(a)dismail.de wrote: >> This also allows patching the HTML of sites so you can fix them to >> work better (or at all) in Dillo. This is also done by Firefox from >> the webcompat[2] project in what they call "interventions", as >> sometimes page authors don't fix them or take a long time, so they >> patch it from the browser directly. You can open about:compat to see >> the long list of patches, here[3] is one for YouTube. > >This would be very impressive, a real step forward for Dillo in my >opinion. Do you think this is something that would be relatively >straight-forward to implement, or is it more of a long-term goal with >lots of work required to get there? Either way, sounds like there are >exciting times ahead for Dillo! Adding a mechanism to rewrite the HTML is surprisingly not super complicated, as the internal design of Dillo is centered around the CCC, the "Concomitant Control Chain", which is basically a chain of bi-directional pipes connected together to pass data around. Here is how Dillo currently receives data from the a TLS server (AFAIK). I'm only drawing the incoming direction, but the outgoing link is similar. Net +--------+ +-------+ +------+ +-------+ ---->| TLS IO |--->| IO |--->| HTTP |--->| CACHE |-... +--------+ +-------+ +------+ +-------+ src/tls.c src/IO.c src/http.c src/capi.c And adding a new rewrite module (named SED in the diagram) would require rerouting the chain to add a new element (not hard): Net +--------+ +-------+ +------+ +=====+ +-------+ ---->| TLS IO |--->| IO |--->| HTTP |---># SED #--->| CACHE |-... +--------+ +-------+ +------+ +=====+ +-------+ src/tls.c src/IO.c src/http.c | src/capi.c | +---------+ | rulesrc | | ... | +---------+ The module can then forward the content parsed from the HTTP module to the appropriate scripts defined in the rules, and then read the output and forward it to the next steps in the chain. When no rules apply, it can just forward the content to the cache as-is. Now, the interesting part is that we can place another SED module between the IO and the HTTP nodes, so we can rewrite the HTML content *and* the HTTP headers too. This would allow for example writing a plugin that matches a given mime type and on-the-fly rewrites it into an HTML file changing the Content-Type header. This is already done by the plugins, but they mix the two things together. For example we can display a .gmi file served via the "gemini:" protocol, but we cannot display a local .gmi file. Same for manual pages with the "man:" protocol, which cannot open manual pages served via "file:" or "http(s):". The solution with the new design would involve: 1) Open a "gemini:" link 2) The request is routed to the gemini: dpi handler (like now) 3) The gemini plugin returns the .gmi file as-is as an HTTP response, instead of converting it to HTML 4) The .gmi mime type matches a rewrite rule and is rewritten into HTML in the SED node. Now, if we open a .gmi via HTTP: 1) Open a "https:" link 2) The request is routed to the usual HTTP/IO/TLS chain 3) The HTTP server returns the .gmi file as-is as an HTTP response. 4) The .gmi mime type matches a rewrite rule, and is rewritten into HTML in the SED node. Notice that the HTTP content can be compressed. So, for example, this simple rewrite script: #!/bin/sh sed 's_www.youtube.com_inv.vern.cc_g' Would only work well in the SED node *after* the HTTP content is uncompressed and the headers removed. The rewrite rules should indicate in which position of the chain they apply. As a side note, keep in mind that all of these pieces work in stream mode. Each node reads a bit of data, process it and sends it to the next node of the chain, without the need to store the whole thing in memory. Same with that sed command I wrote as an example. Best, Rodrigo.

June 18, 2024

Re: Option to define external link handler

by a1ex＠dismail.de

On Mon, 17 Jun 2024 18:23:32 +0200 Rodrigo Arias <rodarima(a)gmail.com> wrote: > >> Executing a user script is fine, but I also want to be able to > >> rewrite the page and bring it back to Dillo for display, which > >> requires more cooperation. > > > >I'm curious what the use-case for this is. Sounds interesting. > > For example, you could write a filter program that parses HTML and > rewrites the links to JS hungry websites to alternative ones, in the > same way libredirect[1] works. > > [1]: https://libredirect.github.io/ > > This also allows patching the HTML of sites so you can fix them to > work better (or at all) in Dillo. This is also done by Firefox from > the webcompat[2] project in what they call "interventions", as > sometimes page authors don't fix them or take a long time, so they > patch it from the browser directly. You can open about:compat to see > the long list of patches, here[3] is one for YouTube. This would be very impressive, a real step forward for Dillo in my opinion. Do you think this is something that would be relatively straight-forward to implement, or is it more of a long-term goal with lots of work required to get there? Either way, sounds like there are exciting times ahead for Dillo! Thanks! Alex

June 18, 2024

Re: Option to define external link handler

by Rodrigo Arias

Hi, On Mon, Jun 17, 2024 at 02:57:44PM +0200, a1ex(a)dismail.de wrote: >> So there is no need to download the file completely before it is >> piped to the tools. > >I don't think mupdf will open a file piped from stdin. Neither does >nsxiv. Maybe I'm missing something. Apparently that's the case, although it should be possible to do: https://mupdf.readthedocs.io/en/1.22.0/progressive-loading.html However, Okular and Zathura seem to be able to open PDFs from the standard input as a pipe. Same with feh for images. >It is possible to determine the Content-Type without downloading the >file with something like: > >curl -XHEAD -s -w '%{content_type}' $url Yes, but it will require another GET request to download the actual file. I think we can just begin a GET request from Dillo, parse the HTTP headers, select the appropriate handler from the mime, and either pipe the content to it or write it to a file and then pass the file path. The first option would allow doing it without waiting for the whole file to download. In fact, it should be possible to not download more than what is being consumed by the handler program. One of the Dillo main objectives is to support slow download speeds (or metered) gracefully. >> Executing a user script is fine, but I also want to be able to rewrite >> the page and bring it back to Dillo for display, which requires more >> cooperation. > >I'm curious what the use-case for this is. Sounds interesting. For example, you could write a filter program that parses HTML and rewrites the links to JS hungry websites to alternative ones, in the same way libredirect[1] works. [1]: https://libredirect.github.io/ This also allows patching the HTML of sites so you can fix them to work better (or at all) in Dillo. This is also done by Firefox from the webcompat[2] project in what they call "interventions", as sometimes page authors don't fix them or take a long time, so they patch it from the browser directly. You can open about:compat to see the long list of patches, here[3] is one for YouTube. [2]: https://webcompat.com/ [3]: https://hg.mozilla.org/mozilla-central/rev/1fa7de8dec52 This already happened to Dillo with Hacker News, and there are still some minor issues not solved. The matching rules should apply those corrections only to the set of matching URLs. Best, Rodrigo.

June 17, 2024

Re: Option to define external link handler

by a1ex＠dismail.de

Hi Rodrigo, > >Just for fun, here is a version which uses curl instead of wget. This > >has the advantage that curl can output the Content-Type from the > >server, and we can use this to perform actions instead of relying on > >the file extension. Another advantage is that curl can tell us the > >output filename, so we don't have to mess around to get that > >anymore. > > These examples are very useful to test the ideas of rules and > actions. Here is how I could imagine it being written: > > action youtube label "Open YouTube in MPV" shell "mpv $url" > action audio label "Open audio in MPV" shell "mpv $url" > action video label "Open video in MPV" shell "mpv $url" > action image label "Open image in NSXIV" download shell "nsxiv > $out" action mupdf label "Open PDF in MuPDF" download shell "mupdf > $out" action default open-new-tab "$url" > > match url "outu" action youtube > match url "\.(mp3|ogg)$" action audio > match url "\.(mkv|mp4|webm)$" action video > # From here on Dillo needs to fetch the headers > match mime-type "image" action image > match mime-type "pdf" action mupdf > # Catchall for non-matched urls > match any action default This looks pretty reasonable. I guess the trick is to not make things too complicated, and yet still make it flexible enough. > Although, we may use Dillo to download the content on the fly, like > this: > > action image label "Open image in NSXIV" pipe "nsxiv -" > action mupdf label "Open PDF in MuPDF" pipe "mupdf -" > > So there is no need to download the file completely before it is piped > to the tools. I don't think mupdf will open a file piped from stdin. Neither does nsxiv. Maybe I'm missing something. It is possible to determine the Content-Type without downloading the file with something like: curl -XHEAD -s -w '%{content_type}' $url Also, it may be desirable to restrict the download filesize to a reasonable limit, which can also be determined with a similar method. > Anyway, I need to think more about it. I also need to consider how > this could be moved out of Dillo, so we don't bring more complexity > to it. > > Executing a user script is fine, but I also want to be able to rewrite > the page and bring it back to Dillo for display, which requires more > cooperation. I'm curious what the use-case for this is. Sounds interesting. > Just a small comment, you can use `exec` to avoid nesting the ifs as > it won't return: > > if echo $1 | grep outu; then > exec $youtube "$1" > fi > > Or exit: > > if echo $1 | grep outu; then > $youtube "$1" > exit $? > fi Oops! I should know better than that, but there is is.. Thanks for pointing it out. Regards, Alex

June 17, 2024

Re: Option to define external link handler

by Rodrigo Arias

Hi Alex, On Sun, Jun 16, 2024 at 06:54:41PM +0200, a1ex(a)dismail.de wrote: >> Sure, here is a very basic example which mainly just goes by the >> extension in the URL to handle some common filetypes. I suppose that >> for more complex links in which the filetype can't be parsed like >> this, you could curl the link into the 'file' command to determine >> the type: curl -s "https://example.com/filename" | file - >> But that's overkill for my needs. >> There are many ways to improve on this, but hopefully it at >> least illustrates the concept. > >Just for fun, here is a version which uses curl instead of wget. This >has the advantage that curl can output the Content-Type from the >server, and we can use this to perform actions instead of relying on >the file extension. Another advantage is that curl can tell us the >output filename, so we don't have to mess around to get that anymore. These examples are very useful to test the ideas of rules and actions. Here is how I could imagine it being written: action youtube label "Open YouTube in MPV" shell "mpv $url" action audio label "Open audio in MPV" shell "mpv $url" action video label "Open video in MPV" shell "mpv $url" action image label "Open image in NSXIV" download shell "nsxiv $out" action mupdf label "Open PDF in MuPDF" download shell "mupdf $out" action default open-new-tab "$url" match url "outu" action youtube match url "\.(mp3|ogg)$" action audio match url "\.(mkv|mp4|webm)$" action video # From here on Dillo needs to fetch the headers match mime-type "image" action image match mime-type "pdf" action mupdf # Catchall for non-matched urls match any action default Although, we may use Dillo to download the content on the fly, like this: action image label "Open image in NSXIV" pipe "nsxiv -" action mupdf label "Open PDF in MuPDF" pipe "mupdf -" So there is no need to download the file completely before it is piped to the tools. On the other hand, I can already spot a problem. When we right-click on a link to find out which actions are available, some of them require the mime type to be known, which would require a request to the server. So we cannot determine which actions will match beforehand. Maybe a better way is to define the set of menu entries first, which could also be altered by match rules: menu label "Open in default program" tag open menu label "Save in notes" tag save-notes Then we use the information of which menu item was selected *and* the clicked url to do the full handling: action youtube shell "mpv $url" action audio shell "mpv $url" action video shell "mpv $url" action image download shell "nsxiv $out" action mupdf download shell "mupdf $out" action save-notes shell "echo $url >> ~/.dillo/notes.txt && echo Saved" action default open-new-tab "$url" match tag open { match url "outu" action youtube match url "\.(mp3|ogg)$" action audio match url "\.(mkv|mp4|webm)$" action video # From here on Dillo needs to fetch the headers match mime-type "image" action image match mime-type "pdf" action mupdf } match tag save-notes action save-notes match any action default So when the user clicks "Save in notes" it doesn't go through the normal "open with" rules, but only matches the save-notes rule. Anyway, I need to think more about it. I also need to consider how this could be moved out of Dillo, so we don't bring more complexity to it. Executing a user script is fine, but I also want to be able to rewrite the page and bring it back to Dillo for display, which requires more cooperation. ># temporary file location >tmp_dir="/tmp/dillo" > ># youtube. checks for "outu" string in URL >if echo $1 | grep outu >then $youtube "$1" >else Just a small comment, you can use `exec` to avoid nesting the ifs as it won't return: if echo $1 | grep outu; then exec $youtube "$1" fi Or exit: if echo $1 | grep outu; then $youtube "$1" exit $? fi Best, Rodrigo.

June 16, 2024

Re: Option to define external link handler

by a1ex＠dismail.de

On Sun, 16 Jun 2024 13:07:38 +0200 <a1ex(a)dismail.de> wrote: > On Sat, 15 Jun 2024 22:16:12 +0200 > Rodrigo Arias <rodarima(a)gmail.com> wrote: > > > Thanks! I'm interested in how you are using a script to match > > several URLs and do some actions automatically, not sure if you > > would be interesting in sharing it (or some parts). > > > Sure, here is a very basic example which mainly just goes by the > extension in the URL to handle some common filetypes. I suppose that > for more complex links in which the filetype can't be parsed like > this, you could curl the link into the 'file' command to determine > the type: curl -s "https://example.com/filename" | file - > But that's overkill for my needs. > There are many ways to improve on this, but hopefully it at > least illustrates the concept. Just for fun, here is a version which uses curl instead of wget. This has the advantage that curl can output the Content-Type from the server, and we can use this to perform actions instead of relying on the file extension. Another advantage is that curl can tell us the output filename, so we don't have to mess around to get that anymore. --------------------------------------------------------------------- #!/bin/sh # Example Dillo URL action handler script using curl # handlers youtube="mpv" audio="mpv" video="mpv" image="nsxiv" pdf="mupdf" # temporary file location tmp_dir="/tmp/dillo" # youtube. checks for "outu" string in URL if echo $1 | grep outu then $youtube "$1" else # audio. uses file extension from URL if echo $1 | tail -c -5 | grep -e mp3 -e ogg then $audio "$1" else # video. uses file extension from URL if echo $1 | tail -c -5 | grep -e mkv -e mp4 -e webm then $video "$1" else # use curl to download the file, and save Content-Type and filename if [ ! -d $tmp_dir ] ; then mkdir $tmp_dir ; fi curl -s --write-out "%{content_type} \n%{filename_effective}" \ --remote-name --output-dir "$tmp_dir" "$1" > $tmp_dir/file_info set the filename based on curl output to file_info filename=$(tail -1 $tmp_dir/file_info) # images. checks content type from file_info if head -1 $tmp_dir/file_info | grep image ; then $image "$filename" fi # pdf. checks content type from file_info if head -1 $tmp_dir/file_info | grep pdf ; then $pdf "$filename" fi fi fi fi -------------------------------------------------------------------- Regards, Alex

June 16, 2024

Re: Option to define external link handler

by a1ex＠dismail.de

On Sat, 15 Jun 2024 22:16:12 +0200 Rodrigo Arias <rodarima(a)gmail.com> wrote: > Thanks! I'm interested in how you are using a script to match several > URLs and do some actions automatically, not sure if you would be > interesting in sharing it (or some parts). Sure, here is a very basic example which mainly just goes by the extension in the URL to handle some common filetypes. I suppose that for more complex links in which the filetype can't be parsed like this, you could curl the link into the 'file' command to determine the type: curl -s "https://example.com/filename" | file - But that's overkill for my needs. There are many ways to improve on this, but hopefully it at least illustrates the concept. --------------------------------------------------------------------- #!/bin/sh # Example Dillo URL action handler script # handlers youtube="mpv" audio="mpv" video="mpv" image="nsxiv" pdf="mupdf" # temporary file location tmp_dir="/tmp/dillo" # routine to download link and define $file dl() { if [ ! -d $tmp_dir ] ; then mkdir $tmp_dir ; fi wget "$1" --no-use-server-timestamps -P $tmp_dir file="$tmp_dir/$(ls -tp $tmp_dir | grep -v /$ | head -1)" } # youtube if echo $1 | grep outu then $youtube "$1" else # audio if echo $1 | tail -c -5 | grep -e mp3 -e ogg then $audio "$1" else # video if echo $1 | tail -c -5 | grep -e mkv -e mp4 -e webm then $video "$1" else # images if echo $1 | tail -c -5 | grep -e jpg -e jpeg -e png -e gif -e tif then dl "$1" $image "$file" else # pdf if echo $1 | tail -c -5 | grep pdf then dl "$1" $pdf "$file" fi ; fi ; fi ; fi ; fi ----------------------------------------------------------------------- Regards, Alex

June 16, 2024

Re: Option to define external link handler

by Rodrigo Arias

Hi Alex, On Sat, Jun 15, 2024 at 01:31:31PM +0200, a1ex(a)dismail.de wrote: > >> I've made a proof of concept. It is still ugly, but it seems to be >> working: >> >> https://github.com/dillo-browser/dillo/pull/199 > >Very cool! I have briefly tested this and it seems to work fine. Will >continue testing to see if any issues come up. Thanks! I'm interested in how you are using a script to match several URLs and do some actions automatically, not sure if you would be interesting in sharing it (or some parts). >> And here is how it looks like: https://0x0.st/XcyR.png > >I did a double-take when I saw this. Hello from a fellow vaporwave fan! >I happen to have several macroblank tracks in my playlist currently :) Nice to hear :-) Best, Rodrigo.

June 15, 2024

Re: Option to define external link handler

by a1ex＠dismail.de

> I've made a proof of concept. It is still ugly, but it seems to be > working: > > https://github.com/dillo-browser/dillo/pull/199 Very cool! I have briefly tested this and it seems to work fine. Will continue testing to see if any issues come up. > And here is how it looks like: https://0x0.st/XcyR.png I did a double-take when I saw this. Hello from a fellow vaporwave fan! I happen to have several macroblank tracks in my playlist currently :) Regards, Alex

June 15, 2024

Re: Option to define external link handler

by Rodrigo Arias

Hi Alex, On Fri, Jun 14, 2024 at 05:25:16PM +0200, a1ex(a)dismail.de wrote: >> The previous examples could be written in ~/.dillo/rulesrc as: >> >> action "Open with MPV" shell "mpv $url" >> action "Open with Feh" shell "feh -- $url" >> action "Open with Firefox" shell "firefox $url" >> >> Which only defines a set of available actions, and by default they >> appear on the link menu as you suggest. I think using a small >> language is a more elegant solution than trying to squeeze the menu >> label and the command in a single dillorc option. > >I like this approach, but not sure how much I can help with it. I've made a proof of concept. It is still ugly, but it seems to be working: https://github.com/dillo-browser/dillo/pull/199 The syntax is the one I commented before. Here is my rulesrc file: action "Open with MPV" shell "mpv $url" action "Open with MPV (only audio)" shell "mpv --no-video $url" action "Open with Firefox" shell "firefox $url" And here is how it looks like: https://0x0.st/XcyR.png >For now, I have taken the example you gave and made barebones patch to >add an external handler to the link menu. It works quite well for me, >in fact its something I'll probably be using every day. A real time saver. > >Its obviously nowhere near as featureful as what you are proposing, but >for the time being, it gets the job done :) Thanks for the patch. I will try to have something merged soon to at least cover this feature. But if I it gets stuck, I wouldn't mind merging your patch or something similar. Best, Rodrigo.

June 14, 2024

Re: Option to define external link handler

by a1ex＠dismail.de

Hi Rodrigo, > >But, these can be two separate features, with optional external link > >handlers acting as an override for the built-in handling. > > Yes, they can be two separate features. I don't have a strong opinion > about it yet, I'll have to think about the consequences of having two > systems. > > On the other hand, I think we can design a very simple rule language > just to model the actions that can later be extended to other more > complex rules without breaking the compatibility with previous > configurations. This way we cover all uses with a unified syntax. > > The previous examples could be written in ~/.dillo/rulesrc as: > > action "Open with MPV" shell "mpv $url" > action "Open with Feh" shell "feh -- $url" > action "Open with Firefox" shell "firefox $url" > > Which only defines a set of available actions, and by default they > appear on the link menu as you suggest. I think using a small > language is a more elegant solution than trying to squeeze the menu > label and the command in a single dillorc option. I like this approach, but not sure how much I can help with it. For now, I have taken the example you gave and made barebones patch to add an external handler to the link menu. It works quite well for me, in fact its something I'll probably be using every day. A real time saver. Its obviously nowhere near as featureful as what you are proposing, but for the time being, it gets the job done :) Here is the patch for anyone interested, hopefully not too mangled. Sent as an attachment as well, just in case. I haven't gotten around to setting up git send-email yet. diff -u dillorc.orig dillorc --- dillorc.orig Wed Jun 12 21:25:35 2024 +++ dillorc Fri Jun 14 16:37:49 2024 @@ -46,6 +46,9 @@ # height of the visible page area. #scroll_step=100 +# Set the external link handler +#ext_handler="mpv" + #------------------------------------------------------------------------- # RENDERING SECTION #------------------------------------------------------------------------- diff -u src/orig/menu.cc src/menu.cc --- src/orig/menu.cc Fri Jun 14 16:14:55 2024 +++ src/menu.cc Fri Jun 14 16:21:34 2024 @@ -122,6 +122,21 @@ } /** + * Open URL in external handler + */ +static void Menu_open_url_ex_cb(Fl_Widget*, void *user_data) +{ + DilloUrl *url = (DilloUrl *)user_data; + char str[500]; + strcpy(str, prefs.ext_handler); + strcat(str, " "); + strcat(str, URL_STR_(url)); + strcat(str, "> /dev/null 2>&1 &"); + puts(str); + system(str); +} + +/** * Add bookmark */ static void Menu_add_bookmark_cb(Fl_Widget*, void *user_data) @@ -432,8 +447,8 @@ static Fl_Menu_Item link_menu[] = { {"Open link in new tab", 0, Menu_open_url_nt_cb,0,0,0,0,0,0}, - {"Open link in new window", 0, Menu_open_url_nw_cb,0,FL_MENU_DIVIDER,0,0, - 0,0}, + {"Open link in new window", 0, Menu_open_url_nw_cb,0,0,0,0,0,0}, + {"Open with external", 0, Menu_open_url_ex_cb,0,FL_MENU_DIVIDER,0,0,0,0}, {"Bookmark this link", 0, Menu_add_bookmark_cb,0,0,0,0,0,0}, {"Copy link location", 0, Menu_copy_urlstr_cb,0,FL_MENU_DIVIDER,0,0,0,0}, {"Save link as...", 0, Menu_save_link_cb,0,0,0,0,0,0}, diff -u src/orig/prefs.c src/prefs.c --- src/orig/prefs.c Fri Jun 14 16:14:55 2024 +++ src/prefs.c Fri Jun 14 16:24:11 2024 @@ -26,6 +26,7 @@ #define PREFS_HTTP_REFERER "host" #define PREFS_HTTP_USER_AGENT "Dillo/" VERSION #define PREFS_THEME "none" +#define PREFS_EXT_HANDLER "mpv" /*----------------------------------------------------------------------------- * Global Data @@ -71,6 +72,7 @@ prefs.http_strict_transport_security = TRUE; prefs.http_force_https = FALSE; prefs.http_user_agent = dStrdup(PREFS_HTTP_USER_AGENT); + prefs.ext_handler = dStrdup(PREFS_EXT_HANDLER); prefs.limit_text_width = FALSE; prefs.adjust_min_width = TRUE; prefs.adjust_table_min_width = TRUE; @@ -151,6 +153,7 @@ dFree(prefs.http_proxyuser); dFree(prefs.http_referer); dFree(prefs.http_user_agent); + dFree(prefs.ext_handler); dFree(prefs.no_proxy); dFree(prefs.save_dir); for (i = 0; i < dList_length(prefs.search_urls); ++i) diff -u src/orig/prefs.h src/prefs.h --- src/orig/prefs.h Fri Jun 14 16:14:55 2024 +++ src/prefs.h Fri Jun 14 16:24:44 2024 @@ -45,6 +45,7 @@ char *http_proxyuser; char *http_referer; char *http_user_agent; + char *ext_handler; char *no_proxy; DilloUrl *start_page; DilloUrl *home; diff -u src/orig/prefsparser.cc src/prefsparser.cc --- src/orig/prefsparser.cc Fri Jun 14 16:14:55 2024 +++ src/prefsparser.cc Fri Jun 14 16:25:40 2024 @@ -187,6 +187,7 @@ { "adjust_table_min_width", &prefs.adjust_table_min_width, PREFS_BOOL, 0 }, { "load_images", &prefs.load_images, PREFS_BOOL, 0 }, { "load_background_images", &prefs.load_background_images, PREFS_BOOL, 0 }, + { "ext_handler", &prefs.ext_handler, PREFS_STRING, 0 }, { "load_stylesheets", &prefs.load_stylesheets, PREFS_BOOL, 0 }, { "middle_click_drags_page", &prefs.middle_click_drags_page, PREFS_BOOL, 0 }, mpv is just used as a common example. I'm using this with a custom shell script which does some basic parsing and takes various actions depending on the URL. Regards, Alex

June 14, 2024

Re: Option to define external link handler

by Rodrigo Arias

Hi, On Thu, Jun 13, 2024 at 09:59:03PM +0200, a1ex(a)dismail.de wrote: >> I have some ideas of how to do it, but I would like to ask you to >> give concrete examples of that feature so I can test it with those >> programs. > >For me, it could be a number of filetypes, plus things like youtube or >other media links. These would be opened in various programs. >Obviously, many programs can't directly open a URL and will fail. > >Why not just have 3 generic options and let the user decide: > >link_handler_1="" >link_handler_2="" >link_handler_3="" > >or whatever name is more suitable. > >If the option is undefined, it doesn't show up in the link menu. Maybe it would be more suitable to follow the syntax of the "search_url" option, which can be used multiple times to define a list of things, so we don't need a predefined number of options. You probably want to set a list of actions with names too: action=Open with MPV;mpv "$url" action=Open with Feh;feh -- "$url" action=Open with Firefox;firefox "$url" Then let the shell expand $url from the envionment, previously set by Dillo with setenv(). What I don't like is that we are mixing the menu label and the command line in the same option value. And we also have to take into account how the shell will interact with the quotes and other symbols (#). >Even if there was only one handler option, personally I would just >have it call a shell script which parses the URL and extension and takes >appropriate action. That would be something like this: action=Open with script;/path/to/script.sh And then the script can use $url and possibly other variables from the environment set by Dillo. >This doesn't have to be a 'one size fits all' feature, and I think most >Dillo users are advanced enough to use this to their advantage. > >Your ideas above regarding Dillo handling the logic for various file >and content types are excellent, and also complicated :) > >But, these can be two separate features, with optional external link >handlers acting as an override for the built-in handling. Yes, they can be two separate features. I don't have a strong opinion about it yet, I'll have to think about the consequences of having two systems. On the other hand, I think we can design a very simple rule language just to model the actions that can later be extended to other more complex rules without breaking the compatibility with previous configurations. This way we cover all uses with a unified syntax. The previous examples could be written in ~/.dillo/rulesrc as: action "Open with MPV" shell "mpv $url" action "Open with Feh" shell "feh -- $url" action "Open with Firefox" shell "firefox $url" Which only defines a set of available actions, and by default they appear on the link menu as you suggest. I think using a small language is a more elegant solution than trying to squeeze the menu label and the command in a single dillorc option. For now I would only focus on a single rule: action <name> shell <command> Then we can do other things like this to pipe the page to some program: action "Open in editor" pipe "gvim -" Or this, to only show "Download video" on YouTube: match url "http[s]://[www\.]youtube\.com" { action "Download video" shell "yt-dlp -f 18 -- $url" } But see how the syntax is the same, so we don't break the compatibility with previously defined rules. >> A similar feature has been implemented in dilloNG: >> >> https://github.com/w00fpack/dilloNG/commit/7bd6b1c4592466d6e717eaf795e98b7c… >> >> But as it is currently implemented is not very extensible, only a >> "media player" and a "media downloader" options are posible. > >Thanks for pointing this out, looks like a good template for testing. >If it works well, I'll post a demo patch for anyone interested. Thanks, Rodrigo

June 13, 2024

Re: Option to define external link handler

by a1ex＠dismail.de

> When downloading a file, it is often not only the URL what is needed > to retrieve it. A lot of sites require the session cookies and less > frequently the user agent. So it would be nice to allow passing that > information to the external tool. > > It may be nice to have multiple options, so for example I could > define an action for YouTube videos and another for PDF files. > > However, I would like to support a workflow in which specific URLs > are matched and the appropriate tool is selected to handle it. For > example, I could open YouTube URLs directly into MPV (or similar) by > just clicking on a link without even going to the "right-click > open > in MPV" menu. > > This has the problem that sometimes the URL is not enough, you need > to determine other things. For example, the server may reply that the > URL I just clicked on is in fact a PDF. It would be nice to be able > to tell Dillo to download the file and open it in my PDF viewer > *after* the server has replied with the MIME type. It should be > posible to directly pipe the server reply into the tool, no need to > wait for the download to finish. > Now, going back to your specific case, it may be good to have a > simpler solution first that can later be extended to the more general > approach, so we don't have to wait too long. > > I have some ideas of how to do it, but I would like to ask you to > give concrete examples of that feature so I can test it with those > programs. For me, it could be a number of filetypes, plus things like youtube or other media links. These would be opened in various programs. Obviously, many programs can't directly open a URL and will fail. Why not just have 3 generic options and let the user decide: link_handler_1="" link_handler_2="" link_handler_3="" or whatever name is more suitable. If the option is undefined, it doesn't show up in the link menu. Even if there was only one handler option, personally I would just have it call a shell script which parses the URL and extension and takes appropriate action. This doesn't have to be a 'one size fits all' feature, and I think most Dillo users are advanced enough to use this to their advantage. Your ideas above regarding Dillo handling the logic for various file and content types are excellent, and also complicated :) But, these can be two separate features, with optional external link handlers acting as an override for the built-in handling. > A similar feature has been implemented in dilloNG: > > https://github.com/w00fpack/dilloNG/commit/7bd6b1c4592466d6e717eaf795e98b7c… > > But as it is currently implemented is not very extensible, only a > "media player" and a "media downloader" options are posible. Thanks for pointing this out, looks like a good template for testing. If it works well, I'll post a demo patch for anyone interested. Regards, Alex

June 13, 2024

Re: Option to define external link handler

by Rodrigo Arias

Hi Alex, On Thu, Jun 13, 2024 at 05:52:55PM +0200, a1ex(a)dismail.de wrote: >Hi Rodrigo and list, > >Thanks for all the recent improvements! > >I have one more feature which I would like to propose, or hopefully at >least get some guidance with. An option to open a link with an external >program. This could be a custom downloader, or whatever else the user >wants. > >Ideally it would be a setting in dillorc, something like: >external_downloader="/usr/bin/some_command -x -y -z" > >And in the right-click Link menu there would be an option to open the >link with the external program, something like "Open link with >external app". > >I can envision various workflows, especially repetitive ones, in which >this would be a real time-saver. There is nothing really wrong with the >built-in downloader, but it's not always ideal. Obviously it's possible >to copy the link and use it in whatever program, but that results in >extra clicks / key-presses. > >Is there any interest in a feature like this? Certainly!, it is one of the firsts issues I opened back in 2020: https://github.com/dillo-browser/dillo/issues/3 However, there are several concerns that we may want to take into account. When downloading a file, it is often not only the URL what is needed to retrieve it. A lot of sites require the session cookies and less frequently the user agent. So it would be nice to allow passing that information to the external tool. It may be nice to have multiple options, so for example I could define an action for YouTube videos and another for PDF files. However, I would like to support a workflow in which specific URLs are matched and the appropriate tool is selected to handle it. For example, I could open YouTube URLs directly into MPV (or similar) by just clicking on a link without even going to the "right-click > open in MPV" menu. This has the problem that sometimes the URL is not enough, you need to determine other things. For example, the server may reply that the URL I just clicked on is in fact a PDF. It would be nice to be able to tell Dillo to download the file and open it in my PDF viewer *after* the server has replied with the MIME type. It should be posible to directly pipe the server reply into the tool, no need to wait for the download to finish. There is an issue to cover this (and other things): https://github.com/dillo-browser/dillo/issues/56 Those tools may not only take care of downloading the file, they can also perform some substitutions in HTML or CSS files and send them back to Dillo, allowing arbitrary modifications of pages. Now, going back to your specific case, it may be good to have a simpler solution first that can later be extended to the more general approach, so we don't have to wait too long. I have some ideas of how to do it, but I would like to ask you to give concrete examples of that feature so I can test it with those programs. >I've been looking at the source, but am not really seeing a way to >easily replace the current download program (or even where it is >defined). If anyone has hints on how to do this, I'd appreciate the >help. Or, even better, someone more talented could step up and implement >the feature :) A similar feature has been implemented in dilloNG: https://github.com/w00fpack/dilloNG/commit/7bd6b1c4592466d6e717eaf795e98b7c… But as it is currently implemented is not very extensible, only a "media player" and a "media downloader" options are posible. Best, Rodrigo.

June 13, 2024

Option to define external link handler

by a1ex＠dismail.de

Hi Rodrigo and list, Thanks for all the recent improvements! I have one more feature which I would like to propose, or hopefully at least get some guidance with. An option to open a link with an external program. This could be a custom downloader, or whatever else the user wants. Ideally it would be a setting in dillorc, something like: external_downloader="/usr/bin/some_command -x -y -z" And in the right-click Link menu there would be an option to open the link with the external program, something like "Open link with external app". I can envision various workflows, especially repetitive ones, in which this would be a real time-saver. There is nothing really wrong with the built-in downloader, but it's not always ideal. Obviously it's possible to copy the link and use it in whatever program, but that results in extra clicks / key-presses. Is there any interest in a feature like this? I've been looking at the source, but am not really seeing a way to easily replace the current download program (or even where it is defined). If anyone has hints on how to do this, I'd appreciate the help. Or, even better, someone more talented could step up and implement the feature :) Regards, Alex

June 13, 2024

Re: unwanted change in behavior of Dillo Download dialog

by pastebin＠gmx.com

Hi, yes - it id fixed from master (dpi/downloads.cc) thanks On Wed, 12 Jun 2024 21:38:51 +0200 Rodrigo Arias <rodarima(a)gmail.com> wrote: > Hi, > > On Wed, Jun 12, 2024 at 09:06:47PM +0200, Rodrigo Arias wrote: > >Thanks, I can reproduce it. I opened an issue on GitHub: > > > >https://github.com/dillo-browser/dillo/issues/196 > > Should be fixed in master now (5db6c99). > > Rodrigo > _______________________________________________ > Dillo-dev mailing list -- dillo-dev(a)mailman3.com > To unsubscribe send an email to dillo-dev-leave(a)mailman3.com

June 12, 2024

Re: unwanted change in behavior of Dillo Download dialog

by Rodrigo Arias

Hi, On Wed, Jun 12, 2024 at 09:06:47PM +0200, Rodrigo Arias wrote: >Thanks, I can reproduce it. I opened an issue on GitHub: > >https://github.com/dillo-browser/dillo/issues/196 Should be fixed in master now (5db6c99). Rodrigo

June 12, 2024

Re: unwanted change in behavior of Dillo Download dialog

by Rodrigo Arias

Hi, On Wed, Jun 12, 2024 at 12:03:09PM -0600, pastebin(a)gmx.com wrote: >Hi, > >using fltk-1.3.9 and dillo-3.1.1 on a linux machine > >when i click 'done' on one of multiple 'save as links' it gives following and the box disappears > >> *** Error in `/usr/local/dillo-3.1.x/lib/dillo/dpi/downloads/downloads.dpi': munmap_chunk(): invalid pointer: 0x000000000040783f *** > >if i cp the downloads.dpi from my old dillo-3.1/dillo-3.0.5 into /usr/local/dillo-3.1.x/lib/dillo/dpi/downloads/downloads.dpi it is fine and no error Thanks, I can reproduce it. I opened an issue on GitHub: https://github.com/dillo-browser/dillo/issues/196 Rodrigo.

June 12, 2024

Re: unwanted change in behavior of Dillo Download dialog

by pastebin＠gmx.com

Hi, using fltk-1.3.9 and dillo-3.1.1 on a linux machine when i click 'done' on one of multiple 'save as links' it gives following and the box disappears > *** Error in `/usr/local/dillo-3.1.x/lib/dillo/dpi/downloads/downloads.dpi': munmap_chunk(): invalid pointer: 0x000000000040783f *** if i cp the downloads.dpi from my old dillo-3.1/dillo-3.0.5 into /usr/local/dillo-3.1.x/lib/dillo/dpi/downloads/downloads.dpi it is fine and no error --- On Tue, 11 Jun 2024 16:55:49 -0600 pastebin(a)gmx.com wrote: > > after saving a number of html from a duck search (save link as) - clicking on done on Dillo Download dialog closes All the downloads not just the one the done was clicked on > > this is very inconvenient as any downloads that were aborted can no longer be identified > > > > _______________________________________________ > Dillo-dev mailing list -- dillo-dev(a)mailman3.com > To unsubscribe send an email to dillo-dev-leave(a)mailman3.com

June 12, 2024

unwanted change in behavior of Dillo Download dialog

by pastebin＠gmx.com

after saving a number of html from a duck search (save link as) - clicking on done on Dillo Download dialog closes All the downloads not just the one the done was clicked on this is very inconvenient as any downloads that were aborted can no longer be identified

June 11, 2024

Re: double-linked list error

by Rodrigo Arias

Hi, On Mon, Jun 10, 2024 at 04:55:02PM -0600, pastebin(a)gmx.com wrote: >Hi > >i get this - but page looks okay even with error Strange, cannot reproduce with 3.1.1. Which system is this and how are you building Dillo?, can you compress and attach the config.log of the build directory? Try to build with the address sanitizer enabled using: $ ../configure 'CFLAGS=-O0 -g -fsanitize=address' 'CXXFLAGS=-O0 -g -fsanitize=address' And try again with: $ ASAN_OPTIONS=new_delete_type_mismatch=0 dillo https://www.gasbuddy.com/station/30609 Then copy the output if it shows errors. Rodrigo.

June 11, 2024

double-linked list error

by pastebin＠gmx.com

Hi i get this - but page looks okay even with error --- dillo is a a script with following in it /ram/dillo-3.1.x is just cp -af /usr/local/dillo-3.1.1/bin/dillo /ram/dillo-3.1.x /ram/dillo-3.1.x "$@" -- /html > dillo https://www.gasbuddy.com/station/30609 /html > *** Error in `/ram/dillo-3.1.x': corrupted double-linked list: 0x000000000299c220 *** ======= Backtrace: ========= /lib/libc.so.6(+0x70bbb)[0x7fbbebd88bbb] /lib/libc.so.6(+0x76f46)[0x7fbbebd8ef46] /lib/libc.so.6(+0x772cc)[0x7fbbebd8f2cc] /lib/libc.so.6(+0x77da0)[0x7fbbebd8fda0] /ram/dillo-3.1.x[0x441ea9] /ram/dillo-3.1.x[0x41ce18] /ram/dillo-3.1.x[0x41ef57] /ram/dillo-3.1.x[0x40b941] /lib/libc.so.6(__libc_start_main+0xf1)[0x7fbbebd382c1] /ram/dillo-3.1.x[0x40c23a] ======= Memory map: ======== 00400000-004e2000 r-xp 00000000 01:00 20 /ram/dillo-3.1.x 006e2000-006e3000 r--p 000e2000 01:00 20 /ram/dillo-3.1.x 006e3000-006e6000 rw-p 000e3000 01:00 20 /ram/dillo-3.1.x 006e6000-006e7000 rw-p 00000000 00:00 0 023cc000-02a54000 rw-p 00000000 00:00 0 [heap] 7fbbdc000000-7fbbdc021000 rw-p 00000000 00:00 0 7fbbdc021000-7fbbe0000000 ---p 00000000 00:00 0 7fbbe4000000-7fbbe4021000 rw-p 00000000 00:00 0 7fbbe4021000-7fbbe8000000 ---p 00000000 00:00 0 7fbbe8e41000-7fbbe8e42000 ---p 00000000 00:00 0 7fbbe8e42000-7fbbe9642000 rw-p 00000000 00:00 0 7fbbe9642000-7fbbe9656000 r-xp 00000000 08:01 7212598 /lib/libresolv-2.24.so 7fbbe9656000-7fbbe9855000 ---p 00014000 08:01 7212598 /lib/libresolv-2.24.so 7fbbe9855000-7fbbe9856000 r--p 00013000 08:01 7212598 /lib/libresolv-2.24.so 7fbbe9856000-7fbbe9857000 rw-p 00014000 08:01 7212598 /lib/libresolv-2.24.so 7fbbe9857000-7fbbe9859000 rw-p 00000000 00:00 0 7fbbe9859000-7fbbe985e000 r-xp 00000000 08:01 7212607 /lib/libnss_dns-2.24.so 7fbbe985e000-7fbbe9a5d000 ---p 00005000 08:01 7212607 /lib/libnss_dns-2.24.so 7fbbe9a5d000-7fbbe9a5e000 r--p 00004000 08:01 7212607 /lib/libnss_dns-2.24.so 7fbbe9a5e000-7fbbe9a5f000 rw-p 00005000 08:01 7212607 /lib/libnss_dns-2.24.so 7fbbe9a5f000-7fbbe9a69000 r-xp 00000000 08:01 7212606 /lib/libnss_files-2.24.so 7fbbe9a69000-7fbbe9c69000 ---p 0000a000 08:01 7212606 /lib/libnss_files-2.24.so 7fbbe9c69000-7fbbe9c6a000 r--p 0000a000 08:01 7212606 /lib/libnss_files-2.24.so 7fbbe9c6a000-7fbbe9c6b000 rw-p 0000b000 08:01 7212606 /lib/libnss_files-2.24.so 7fbbe9c6b000-7fbbe9c71000 rw-p 00000000 00:00 0 7fbbe9c83000-7fbbe9c84000 ---p 00000000 00:00 0 7fbbe9c84000-7fbbea484000 rw-p 00000000 00:00 0 7fbbea484000-7fbbea49d000 r--s 00000000 08:01 11668165 /usr/local/var/cache/fontconfig/cabbd14511b9e8a55e92af97fb3a0461-le64.cache-4 7fbbea49d000-7fbbea4c3000 r--s 00000000 08:01 11668163 /usr/local/var/cache/fontconfig/2c204173d3592afc30a350ed81f64c67-le64.cache-4 7fbbea4c3000-7fbbea52b000 r--s 00000000 08:01 11668169 /usr/local/var/cache/fontconfig/21a99156bb11811cef641abeda519a45-le64.cache-4 7fbbea52b000-7fbbea59e000 r--s 00000000 08:01 11668180 /usr/local/var/cache/fontconfig/17090aa38d5c6f09fb8c5c354938f1d7-le64.cache-4 7fbbea59e000-7fbbea5a8000 r-xp 00000000 08:01 11668429 /usr/local/lib/libXrandr.so.2.2.0 7fbbea5a8000-7fbbea7a7000 ---p 0000a000 08:01 11668429 /usr/local/lib/libXrandr.so.2.2.0 7fbbea7a7000-7fbbea7a8000 r--p 00009000 08:01 11668429 /usr/local/lib/libXrandr.so.2.2.0 7fbbea7a8000-7fbbea7a9000 rw-p 0000a000 08:01 11668429 /usr/local/lib/libXrandr.so.2.2.0 7fbbea7a9000-7fbbeaa03000 r--p 00000000 08:01 7472391 /lib/locale/locale-archive 7fbbeaa03000-7fbbeab25000 r-xp 00000000 08:01 11670811 /usr/local/lib/libglib-2.0.so.0.5800.3 7fbbeab25000-7fbbead24000 ---p 00122000 08:01 11670811 /usr/local/lib/libglib-2.0.so.0.5800.3 7fbbead24000-7fbbead25000 r--p 00121000 08:01 11670811 /usr/local/lib/libglib-2.0.so.0.5800.3 7fbbead25000-7fbbead26000 rw-p 00122000 08:01 11670811 /usr/local/lib/libglib-2.0.so.0.5800.3 7fbbead26000-7fbbead27000 rw-p 00000000 00:00 0 7fbbead27000-7fbbeadba000 r-xp 00000000 08:01 11669992 /usr/local/lib/libharfbuzz.so.0.10501.0 7fbbeadba000-7fbbeafb9000 ---p 00093000 08:01 11669992 /usr/local/lib/libharfbuzz.so.0.10501.0 7fbbeafb9000-7fbbeafbb000 r--p 00092000 08:01 11669992 /usr/local/lib/libharfbuzz.so.0.10501.0 7fbbeafbb000-7fbbeafbc000 rw-p 00094000 08:01 11669992 /usr/local/lib/libharfbuzz.so.0.10501.0 7fbbeafbc000-7fbbeafcb000 r-xp 00000000 08:01 11146623 /usr/lib/libbz2.so.1.0.8 7fbbeafcb000-7fbbeb1ca000 ---p 0000f000 08:01 11146623 /usr/lib/libbz2.so.1.0.8 7fbbeb1ca000-7fbbeb1cb000 r--p 0000e000 08:01 11146623 /usr/lib/libbz2.so.1.0.8 7fbbeb1cb000-7fbbeb1cc000 rw-p 0000f000 08:01 11146623 /usr/lib/libbz2.so.1.0.8 7fbbeb1cc000-7fbbeb2b6000 r-xp 00000000 08:01 11404071 /usr/local/lib64/libfreetype.so.6.16.0 7fbbeb2b6000-7fbbeb4b6000 ---p 000ea000 08:01 11404071 /usr/local/lib64/libfreetype.so.6.16.0 7fbbeb4b6000-7fbbeb4bd000 r--p 000ea000 08:01 11404071 /usr/local/lib64/libfreetype.so.6.16.0 7fbbeb4bd000-7fbbeb4bf000 rw-p 000f1000 08:01 11404071 /usr/local/lib64/libfreetype.so.6.16.0 7fbbeb4bf000-7fbbeb4e6000 r-xp 00000000 08:01 11669801 /usr/local/lib/libexpat.so.1.6.7 7fbbeb4e6000-7fbbeb6e6000 ---p 00027000 08:01 11669801 /usr/local/lib/libexpat.so.1.6.7 7fbbeb6e6000-7fbbeb6e8000 r--p 00027000 08:01 11669801 /usr/local/lib/libexpat.so.1.6.7 7fbbeb6e8000-7fbbeb6e9000 rw-p 00029000 08:01 11669801 /usr/local/lib/libexpat.so.1.6.7 7fbbeb6e9000-7fbbeb6ee000 r-xp 00000000 08:01 11670511 /usr/local/lib/libXdmcp.so.6.0.0 7fbbeb8ed000-7fbbeb8ee000 r--p 00004000 08:01 11670511 /usr/local/lib/libXdmcp.so.6.0.0 7fbbeb8ee000-7fbbeb8ef000 rw-p 00005000 08:01 11670511 /usr/local/lib/libXdmcp.so.6.0.0 7fbbeb8ef000-7fbbeb8f1000 r-xp 00000000 08:01 11670421 /usr/local/lib/libXau.so.6.0.0 7fbbeb8f1000-7fbbebaf0000 ---p 00002000 08:01 11670421 /usr/local/lib/libXau.so.6.0.0 7fbbebaf0000-7fbbebaf1000 r--p 00001000 08:01 11670421 /usr/local/lib/libXau.so.6.0.0 7fbbebaf1000-7fbbebaf2000 rw-p 00002000 08:01 11670421 /usr/local/lib/libXau.so.6.0.0 7fbbebaf2000-7fbbebb16000 r-xp 00000000 08:01 11670187 /usr/local/lib/libxcb.so.1.1.0 7fbbebb16000-7fbbebd16000 ---p 00024000 08:01 11670187 /usr/local/lib/libxcb.so.1.1.0 7fbbebd16000-7fbbebd17000 r--p 00024000 08:01 11670187 /usr/local/lib/libxcb.so.1.1.0 7fbbebd17000-7fbbebd18000 rw-p 00025000 08:01 11670187 /usr/local/lib/libxcb.so.1.1.0 7fbbebd18000-7fbbebeab000 r-xp 00000000 08:01 7212647 /lib/libc-2.24.so 7fbbebeab000-7fbbec0aa000 ---p 00193000 08:01 7212647 /lib/libc-2.24.so 7fbbec0aa000-7fbbec0ae000 r--p 00192000 08:01 7212647 /lib/libc-2.24.so 7fbbec0ae000-7fbbec0b0000 rw-p 00196000 08:01 7212647 /lib/libc-2.24.so 7fbbec0b0000-7fbbec0b4000 rw-p 00000000 00:00 0 7fbbec0b4000-7fbbec0d1000 r-xp 00000000 08:01 11403797 /usr/local/gcc-12.2.0/lib64/libgcc_s.so.1 7fbbec0d1000-7fbbec2d0000 ---p 0001d000 08:01 11403797 /usr/local/gcc-12.2.0/lib64/libgcc_s.so.1 7fbbec2d0000-7fbbec2d1000 r--p 0001c000 08:01 11403797 /usr/local/gcc-12.2.0/lib64/libgcc_s.so.1 7fbbec2d1000-7fbbec2d2000 rw-p 0001d000 08:01 11403797 /usr/local/gcc-12.2.0/lib64/libgcc_s.so.1 7fbbec2d2000-7fbbec3d5000 r-xp 00000000 08:01 7212565 /lib/libm-2.24.so 7fbbec3d5000-7fbbec5d4000 ---p 00103000 08:01 7212565 /lib/libm-2.24.so 7fbbec5d4000-7fbbec5d5000 r--p 00102000 08:01 7212565 /lib/libm-2.24.so 7fbbec5d5000-7fbbec5d6000 rw-p 00103000 08:01 7212565 /lib/libm-2.24.so 7fbbec5d6000-7fbbec7e7000 r-xp 00000000 08:01 11403802 /usr/local/gcc-12.2.0/lib64/libstdc++.so.6.0.30 7fbbec7e7000-7fbbec9e6000 ---p 00211000 08:01 11403802 /usr/local/gcc-12.2.0/lib64/libstdc++.so.6.0.30 7fbbec9e6000-7fbbec9f1000 r--p 00210000 08:01 11403802 /usr/local/gcc-12.2.0/lib64/libstdc++.so.6.0.30 7fbbec9f1000-7fbbec9f4000 rw-p 0021b000 08:01 11403802 /usr/local/gcc-12.2.0/lib64/libstdc++.so.6.0.30 7fbbec9f4000-7fbbec9f7000 rw-p 00000000 00:00 0 7fbbec9f7000-7fbbeca62000 r-xp 00000000 08:01 11670815 /usr/local/lib/libmbedcrypto.so.2.13.0 7fbbeca62000-7fbbecc62000 ---p 0006b000 08:01 11670815 /usr/local/lib/libmbedcrypto.so.2.13.0 7fbbecc62000-7fbbecc65000 r--p 0006b000 08:01 11670815 /usr/local/lib/libmbedcrypto.so.2.13.0 7fbbecc65000-7fbbecc67000 rw-p 0006e000 08:01 11670815 /usr/local/lib/libmbedcrypto.so.2.13.0 7fbbecc67000-7fbbecc69000 rw-p 00000000 00:00 0 7fbbecc69000-7fbbecc7f000 r-xp 00000000 08:01 11670814 /usr/local/lib/libmbedx509.so.2.13.0 7fbbecc7f000-7fbbece7e000 ---p 00016000 08:01 11670814 /usr/local/lib/libmbedx509.so.2.13.0 7fbbece7e000-7fbbece7f000 r--p 00015000 08:01 11670814 /usr/local/lib/libmbedx509.so.2.13.0 7fbbece7f000-7fbbece80000 rw-p 00016000 08:01 11670814 /usr/local/lib/libmbedx509.so.2.13.0 7fbbece80000-7fbbeceb6000 r-xp 00000000 08:01 11670813 /usr/local/lib/libmbedtls.so.2.13.0 7fbbeceb6000-7fbbed0b6000 ---p 00036000 08:01 11670813 /usr/local/lib/libmbedtls.so.2.13.0 7fbbed0b6000-7fbbed0b8000 r--p 00036000 08:01 11670813 /usr/local/lib/libmbedtls.so.2.13.0 7fbbed0b8000-7fbbed0b9000 rw-p 00038000 08:01 11670813 /usr/local/lib/libmbedtls.so.2.13.0 7fbbed0b9000-7fbbed0d4000 r-xp 00000000 08:01 7210323 /lib/libz.so.1.2.12 7fbbed0d4000-7fbbed2d4000 ---p 0001b000 08:01 7210323 /lib/libz.so.1.2.12 7fbbed2d4000-7fbbed2d5000 r--p 0001b000 08:01 7210323 /lib/libz.so.1.2.12 7fbbed2d5000-7fbbed2d6000 rw-p 0001c000 08:01 7210323 /lib/libz.so.1.2.12 7fbbed2d6000-7fbbed409000 r-xp 00000000 08:01 11670488 /usr/local/lib/libX11.so.6.3.0 7fbbed409000-7fbbed609000 ---p 00133000 08:01 11670488 /usr/local/lib/libX11.so.6.3.0 7fbbed609000-7fbbed60a000 r--p 00133000 08:01 11670488 /usr/local/lib/libX11.so.6.3.0 7fbbed60a000-7fbbed60f000 rw-p 00134000 08:01 11670488 /usr/local/lib/libX11.so.6.3.0 7fbbed60f000-7fbbed611000 r-xp 00000000 08:01 7212575 /lib/libdl-2.24.so 7fbbed611000-7fbbed811000 ---p 00002000 08:01 7212575 /lib/libdl-2.24.so 7fbbed811000-7fbbed812000 r--p 00002000 08:01 7212575 /lib/libdl-2.24.so 7fbbed812000-7fbbed813000 rw-p 00003000 08:01 7212575 /lib/libdl-2.24.so 7fbbed813000-7fbbed82b000 r-xp 00000000 08:01 7212584 /lib/libpthread-2.24.so 7fbbed82b000-7fbbeda2a000 ---p 00018000 08:01 7212584 /lib/libpthread-2.24.so 7fbbeda2a000-7fbbeda2b000 r--p 00017000 08:01 7212584 /lib/libpthread-2.24.so 7fbbeda2b000-7fbbeda2c000 rw-p 00018000 08:01 7212584 /lib/libpthread-2.24.so 7fbbeda2c000-7fbbeda30000 rw-p 00000000 00:00 0 7fbbeda30000-7fbbeda32000 r-xp 00000000 08:01 11670420 /usr/local/lib/libXinerama.so.1.0.0 7fbbeda32000-7fbbedc31000 ---p 00002000 08:01 11670420 /usr/local/lib/libXinerama.so.1.0.0 7fbbedc31000-7fbbedc32000 r--p 00001000 08:01 11670420 /usr/local/lib/libXinerama.so.1.0.0 7fbbedc32000-7fbbedc33000 rw-p 00002000 08:01 11670420 /usr/local/lib/libXinerama.so.1.0.0 7fbbedc33000-7fbbedc6d000 r-xp 00000000 08:01 11670352 /usr/local/lib/libfontconfig.so.1.7.0 7fbbedc6d000-7fbbede6d000 ---p 0003a000 08:01 11670352 /usr/local/lib/libfontconfig.so.1.7.0 7fbbede6d000-7fbbede6f000 r--p 0003a000 08:01 11670352 /usr/local/lib/libfontconfig.so.1.7.0 7fbbede6f000-7fbbede70000 rw-p 0003c000 08:01 11670352 /usr/local/lib/libfontconfig.so.1.7.0 7fbbede70000-7fbbede85000 r-xp 00000000 08:01 11670483 /usr/local/lib/libXft.so.2.2.0 7fbbede85000-7fbbee084000 ---p 00015000 08:01 11670483 /usr/local/lib/libXft.so.2.2.0 7fbbee084000-7fbbee085000 r--p 00014000 08:01 11670483 /usr/local/lib/libXft.so.2.2.0 7fbbee085000-7fbbee086000 rw-p 00015000 08:01 11670483 /usr/local/lib/libXft.so.2.2.0 7fbbee086000-7fbbee097000 r-xp 00000000 08:01 11668476 /usr/local/lib/libXext.so.6.4.0 7fbbee097000-7fbbee296000 ---p 00011000 08:01 11668476 /usr/local/lib/libXext.so.6.4.0 7fbbee296000-7fbbee297000 r--p 00010000 08:01 11668476 /usr/local/lib/libXext.so.6.4.0 7fbbee297000-7fbbee298000 rw-p 00011000 08:01 11668476 /usr/local/lib/libXext.so.6.4.0 7fbbee298000-7fbbee29d000 r-xp 00000000 08:01 11669750 /usr/local/lib/libXfixes.so.3.1.0 7fbbee29d000-7fbbee49c000 ---p 00005000 08:01 11669750 /usr/local/lib/libXfixes.so.3.1.0 7fbbee49c000-7fbbee49d000 r--p 00004000 08:01 11669750 /usr/local/lib/libXfixes.so.3.1.0 7fbbee49d000-7fbbee49e000 rw-p 00005000 08:01 11669750 /usr/local/lib/libXfixes.so.3.1.0 7fbbee49e000-7fbbee4a7000 r-xp 00000000 08:01 11669710 /usr/local/lib/libXcursor.so.1.0.2 7fbbee4a7000-7fbbee6a6000 ---p 00009000 08:01 11669710 /usr/local/lib/libXcursor.so.1.0.2 7fbbee6a6000-7fbbee6a7000 r--p 00008000 08:01 11669710 /usr/local/lib/libXcursor.so.1.0.2 7fbbee6a7000-7fbbee6a8000 rw-p 00009000 08:01 11669710 /usr/local/lib/libXcursor.so.1.0.2 7fbbee6a8000-7fbbee6b1000 r-xp 00000000 08:01 11670007 /usr/local/lib/libXrender.so.1.3.0 7fbbee6b1000-7fbbee8b0000 ---p 00009000 08:01 11670007 /usr/local/lib/libXrender.so.1.3.0 7fbbee8b0000-7fbbee8b1000 r--p 00008000 08:01 11670007 /usr/local/lib/libXrender.so.1.3.0 7fbbee8b1000-7fbbee8b2000 rw-p 00009000 08:01 11670007 /usr/local/lib/libXrender.so.1.3.0 7fbbee8b2000-7fbbee99e000 r-xp 00000000 08:01 11671628 /usr/local/lib/libfltk.so.1.3 7fbbee99e000-7fbbeeb9d000 ---p 000ec000 08:01 11671628 /usr/local/lib/libfltk.so.1.3 7fbbeeb9d000-7fbbeeba4000 r--p 000eb000 08:01 11671628 /usr/local/lib/libfltk.so.1.3 7fbbeeba4000-7fbbeeba7000 rw-p 000f2000 08:01 11671628 /usr/local/lib/libfltk.so.1.3 7fbbeeba7000-7fbbeebad000 rw-p 00000000 00:00 0 7fbbeebad000-7fbbeebdf000 r-xp 00000000 08:01 11670803 /usr/local/lib/libpng16.so.16.37.0 7fbbeebdf000-7fbbeedde000 ---p 00032000 08:01 11670803 /usr/local/lib/libpng16.so.16.37.0 7fbbeedde000-7fbbeeddf000 r--p 00031000 08:01 11670803 /usr/local/lib/libpng16.so.16.37.0 7fbbeeddf000-7fbbeede0000 rw-p 00032000 08:01 11670803 /usr/local/lib/libpng16.so.16.37.0 7fbbeede0000-7fbbeee03000 r-xp 00000000 08:01 11671833 /usr/local/lib/libjpeg.so.62.0.0 7fbbeee03000-7fbbef002000 ---p 00023000 08:01 11671833 /usr/local/lib/libjpeg.so.62.0.0 7fbbef002000-7fbbef003000 r--p 00022000 08:01 11671833 /usr/local/lib/libjpeg.so.62.0.0 7fbbef003000-7fbbef004000 rw-p 00023000 08:01 11671833 /usr/local/lib/libjpeg.so.62.0.0 7fbbef004000-7fbbef027000 r-xp 00000000 08:01 7212620 /lib/ld-2.24.so 7fbbef028000-7fbbef036000 r--s 00000000 08:01 11668159 /usr/local/var/cache/fontconfig/e13b20fdb08344e0e664864cc2ede53d-le64.cache-4 7fbbef036000-7fbbef095000 r--s 00000000 08:01 11668170 /usr/local/var/cache/fontconfig/fd87326b613ebe77f25eb19df36139c6-le64.cache-4 7fbbef095000-7fbbef109000 rw-p 00000000 00:00 0 7fbbef112000-7fbbef11b000 r--s 00000000 08:01 11668160 /usr/local/var/cache/fontconfig/6409bdcbd64ae572186a9417ac64abbb-le64.cache-4 7fbbef11b000-7fbbef13c000 r--s 00000000 08:01 11668182 /usr/local/var/cache/fontconfig/8d4af663993b81a124ee82e610bb31f9-le64.cache-4 7fbbef13c000-7fbbef14a000 r--s 00000000 08:01 11668172 /usr/local/var/cache/fontconfig/d62e99ef547d1d24cdb1bd22ec1a2976-le64.cache-4 7fbbef14a000-7fbbef170000 r--s 00000000 08:01 11668173 /usr/local/var/cache/fontconfig/f6b893a7224233d96cb72fd88691c0b4-le64.cache-4 7fbbef170000-7fbbef1e3000 r--s 00000000 08:01 11668176 /usr/local/var/cache/fontconfig/df311e82a1a24c41a75c2c930223552e-le64.cache-4 7fbbef204000-7fbbef211000 rw-p 00000000 00:00 0 7fbbef211000-7fbbef219000 r--s 00000000 08:01 11668158 /usr/local/var/cache/fontconfig/7ef2298fde41cc6eeb7af42e48b7d293-le64.cache-4 7fbbef219000-7fbbef222000 r--s 00000000 08:01 11668174 /usr/local/var/cache/fontconfig/f349e9996a5320f6dd491cedd2b1f964-le64.cache-4 7fbbef222000-7fbbef226000 rw-p 00000000 00:00 0 7fbbef226000-7fbbef227000 r--p 00022000 08:01 7212620 /lib/ld-2.24.so 7fbbef227000-7fbbef228000 rw-p 00023000 08:01 7212620 /lib/ld-2.24.so 7fbbef228000-7fbbef229000 rw-p 00000000 00:00 0 7ffc4fee4000-7ffc4ff05000 rw-p 00000000 00:00 0 [stack] 7ffc4ff0a000-7ffc4ff0d000 r--p 00000000 00:00 0 [vvar] 7ffc4ff0d000-7ffc4ff0f000 r-xp 00000000 00:00 0 [vdso] ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall]

June 10, 2024

Re: [PATCH] User defined new tab page

by Rodrigo Arias

Hi, 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! Merged in https://github.com/dillo-browser/dillo/pull/188 Empty URLs are used when parsing something like href="", so we cannot return an invalid URL in a_URL_new(), otherwise that causes a segfault in other parts (see #190). So for now, I'm only making it invalid if the base URL is NULL, which covers the case when you set new_tab_page="", causing the newly open tab to just open a blank tab instead of "http:/". Rodrigo.

June 9, 2024

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

by pastebin＠gmx.com

Hi, i have fltk-1.3.4-2 installed - i will upgrade to latest fltk-1.3.9 and see what happens question for Charles what version fltk? is it even fltk related? what repetive text do you get repeated? is it a sub dir in your dillo save dir? or a file name? On Sat, 8 Jun 2024 21:31:32 +0200 Rodrigo Arias <rodarima(a)gmail.com> wrote: > Hi, > > On Sat, Jun 08, 2024 at 10:04:40AM -0600, pastebin(a)gmx.com wrote: > >> Which version of Dillo and FLTK do you have? Cannot reproduce with > >> Dillo 3.1.1 and FLTK 1.3.9. it isn't reproducible for anything i can do to try to make it happen it hasn't happened yet with 3.1.0 and fltk-1.3.4-2 i will update to dillo-3.1.1 and fltk-1.3.9 > >> > >> I'm thinking it may be related to file access permissions, > > > >i'm thinking it has to do with 'accidentally hitting an arrow key > >before i want to type a file name to save' but nothing is reproducable > > I reviewed the code and it doesn't seem this is likely to be on Dillo > side, as we only call fl_file_chooser() of FLTK: > > https://github.com/dillo-browser/dillo/blob/e89a2293ebb3331dca46f5edf010823… > > Please report your FLTK version, as it may be already solved on 1.3.9 > and that could explain why I don't see it. > > Rodrigo. > _______________________________________________ > Dillo-dev mailing list -- dillo-dev(a)mailman3.com > To unsubscribe send an email to dillo-dev-leave(a)mailman3.com

June 8, 2024

Re: Dillo screenshot (and disguised posting via NNTP test retry)

by Rodrigo Arias

Hi, On Sat, May 18, 2024 at 02:01:18PM +0042, yeti wrote: >Dillo can be found in PkgSrc/www and in Pkgsrc-wip and the later one >uses FLTK-1.4, so I gave that a shot first. It's a not fine tuned X11 >setup in a VM. I typically use my NetBSDs (VMs and real ones) via SSH >and Mosh, so I've not put much love in setting up Modular-Xorg for it. > >https://yeti.tilde.institute/dillo-screenshots/20240517-234326__dillo__from… Nice! I hope they release FLTK 1.4 this year. It should fix some issues with missing glyphs and DPI (as dot-per-inch) scaling. Rodrigo.

June 8, 2024

Re: Version 3.1.1 released

by Rodrigo Arias

Hi, On Sat, Jun 08, 2024 at 03:15:06PM +0042, yeti wrote: >(But this substance free post just shall be a test about the ML being >writable via NNTP now.) It seems to be working, I can see this header: > X-Injected-Via-Gmane: http://gmane.org/ I contacted gmane some time ago to make the list writeable from NNTP, and they seem to have changed something as now it seems to work :-) Rodrigo.

June 8, 2024

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

by Rodrigo Arias

Hi, On Sat, Jun 08, 2024 at 10:04:40AM -0600, pastebin(a)gmx.com wrote: >> Which version of Dillo and FLTK do you have? Cannot reproduce with >> Dillo 3.1.1 and FLTK 1.3.9. >> >> I'm thinking it may be related to file access permissions, > >i'm thinking it has to do with 'accidentally hitting an arrow key >before i want to type a file name to save' but nothing is reproducable I reviewed the code and it doesn't seem this is likely to be on Dillo side, as we only call fl_file_chooser() of FLTK: https://github.com/dillo-browser/dillo/blob/e89a2293ebb3331dca46f5edf010823… Please report your FLTK version, as it may be already solved on 1.3.9 and that could explain why I don't see it. Rodrigo.

June 8, 2024

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

by pastebin＠gmx.com

Hi On Sat, 8 Jun 2024 16:49:45 +0200 Rodrigo Arias <rodarima(a)gmail.com> wrote: > Hi, > > On Sat, Jun 08, 2024 at 08:24:25AM -0600, pastebin(a)gmx.com wrote: > >any idea what triggers it? <- Charles and what do you see duplicated ? > > Can you share the output of (with dillo opened): it doesn't happen very ofter and i can't cause it to happen - next time it occurs i will send the strace and a png of it i was 'happy' to see that Charles also saw it happen and wanted to know what he had duplicated in place of my /tmp/tmp/tmp etc > > % ls -ld /html /html/tmp > % ps -fC dillo > > Which version of Dillo and FLTK do you have? Cannot reproduce with Dillo > 3.1.1 and FLTK 1.3.9. > > I'm thinking it may be related to file access permissions, i'm thinking it has to do with 'accidentally hitting an arrow key before i want to type a file name to save' but nothing is reproducable > which user > are you running Dillo with? > > If you can reproduce it systematically you may be able to send us a > trace with strace: > > % dillo & > % strace -f -o trace.log -p $! i will run this strace from a script from now on - hoping it happens :) > ... Reproduce the problem and Ctrl+C > % gzip trace.log > > Then send trace.log.gz, which should contain any file system access > error there. > > Rodrigo. > _______________________________________________ > Dillo-dev mailing list -- dillo-dev(a)mailman3.com > To unsubscribe send an email to dillo-dev-leave(a)mailman3.com

June 8, 2024

'Dillo Downloads' box cutnpaste

by pastebin＠gmx.com

Hi if i have a page of links i cab do a mouse-right-click on one of the url links and i get the 'link menu' and then i can click on 'save link as..' and it saves the html fine in the current directory in most cases and then there is now a 'Dillo Download' box with 'Done' on it on the screen and running the mouse over the filename causes a 'Target File: xxx' box to be displayed with all the files information displayed The problem is when after i run mouse over the saved file name on the 'Dillo Download' box the 'Target File: xxxx) information disappears from the screen when i attempt to cutnpaste the information there can this behavior be changed so that moving the mouse completely from the 'Dillo Download' box and not just the file name location removes the 'Target File: xxx' information from the screen so a cutnpaste can be performed on the information in the 'Target File: xxx' box?

June 8, 2024

Re: Dillo screenshot (and disguised posting via NNTP test retry)

by yeti

Strange. That post was rejected previously and today I wrote something completely different that looked to pass thru after a confirmation exchange via mail. Funny mishap. \o/ -- I do not bite, I just want to play.

June 8, 2024

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

by Rodrigo Arias

Hi, On Sat, Jun 08, 2024 at 08:24:25AM -0600, pastebin(a)gmx.com wrote: >any idea what triggers it? Can you share the output of (with dillo opened): % ls -ld /html /html/tmp % ps -fC dillo Which version of Dillo and FLTK do you have? Cannot reproduce with Dillo 3.1.1 and FLTK 1.3.9. I'm thinking it may be related to file access permissions, which user are you running Dillo with? If you can reproduce it systematically you may be able to send us a trace with strace: % dillo & % strace -f -o trace.log -p $! ... Reproduce the problem and Ctrl+C % gzip trace.log Then send trace.log.gz, which should contain any file system access error there. Rodrigo.

June 8, 2024

Dillo screenshot (and disguised posting via NNTP test)

by yeti

Dillo can be found in PkgSrc/www and in Pkgsrc-wip and the later one uses FLTK-1.4, so I gave that a shot first. It's a not fine tuned X11 setup in a VM. I typically use my NetBSDs (VMs and real ones) via SSH and Mosh, so I've not put much love in setting up Modular-Xorg for it. https://yeti.tilde.institute/dillo-screenshots/20240517-234326__dillo__from… And additionally this message shall test posting via Gmane/NNTP. -- I do not bite, I just want to play.

June 8, 2024

Dillo screenshot (and disguised posting via NNTP test retry)

by yeti

Dillo can be found in PkgSrc/www and in Pkgsrc-wip and the later one uses FLTK-1.4, so I gave that a shot first. It's a not fine tuned X11 setup in a VM. I typically use my NetBSDs (VMs and real ones) via SSH and Mosh, so I've not put much love in setting up Modular-Xorg for it. https://yeti.tilde.institute/dillo-screenshots/20240517-234326__dillo__from… And additionally this message shall test posting via Gmane/NNTP. -- I do not bite, I just want to play.

June 8, 2024

Re: Version 3.1.1 released

by yeti

Rodrigo Arias <rodarima(a)gmail.com> writes: > I just released the 3.1.1 version of Dillo: > > https://dillo-browser.github.io/release/3.1.1/ \o/ > It only includes minor bug fixes, but we can now begin to merge new > features for next 3.2.0 :-) Impatience is among my well known superpowers. (But this substance free post just shall be a test about the ML being writable via NNTP now.) -- 2. Hitchhiker 33: (125) "Six by nine. Forty-two." (126) "That's it. That's all there is."

June 8, 2024