June 2024 - Dillo-dev - lists.mailman3.com

Re: Unexpected behaviour.

by D

2024-06-26 22:26:13 (+0200), Rodrigo Arias wrote: > On Wed, Jun 26, 2024 at 12:47:08AM +0300, D wrote: > > html tag <caption> makes the table wider. > > The caption tag is not supported yet. Do you have a test case? Any <table> with <caption> may serve as test case. --

June 27, 2024

Re: HTTPS Proxy Support

by Kevin Koster

Rodrigo Arias wrote: > On Wed, Jun 26, 2024 at 08:52:37AM +1000, Kevin Koster wrote: >>Rodrigo Arias <rodarima-Re5JQEeQqe8AvxtiuMwx3w-XMD5yJDbdMReXY1tMh2IBg(a)public.gmane.org> wrote: >>This is why I now think it best to avoid the 'https_proxy' name, >>because the behaviour with it will never be consistent with other >>software without changing how Dillo already handles the >>'http_proxy' variable/setting. > > I undertand, but I think this is a good moment to plan how to change how > Dillo handles the http_proxy variable, so it only affects HTTP traffic > and not HTTPS too. > > What about this: > > Setting the env vars as: > http_proxy=http://localhost:1234 > https_proxy= > > Now causes a warning (maybe also in the UI): > > $ dillo https://www.google.com > WARNING: Setting http_proxy to specify the HTTPS proxy is deprecated, > use https_proxy to define it instead. > > But still makes Dillo use the http_proxy both for HTTP and HTTPS for > now. > > Also: > > http_proxy=http://localhost:1234 > https_proxy=http://localhost:1235 > > No warning: > > $ dillo https://www.google.com > > But Dillo uses both proxies independently (like curl or wget), instead > of the current implementation that would use http_proxy for HTTP and > HTTPS. > > Same with the dillorc options http_proxy and https_proxy (new), keeping > the preference for the env vars if defined. Yes that sounds like a good way to bring Dillo into line with other software, and also means that the environment variables apply consistently to downloads since they use Wget. > The only unexpected change may be for a user that had previously set > https_proxy that was not being used by Dillo, and now it would be. But I > think that 1) is unlikely they use a different value for HTTP and HTTPS > and 2) it is probably intended to use the https_proxy for HTTPS anyway. > We could emit a warning about this too, but maybe not needed if we > explain that Dillo will handle now the https_proxy variable. Affected users would have already been seeing inconsistent behaviour with file downloads since Wget is already using https_proxy. > In any case, this should be properly explained in the release notes, > leaving one release with the deprecation warning for users to take time > to change the behavior, before we stop using http_proxy as the HTTPS > proxy. Yep, and obviously in the changelog too, to be better than Wget and its undocumented past switch to tunneling HTTPS connections through https_proxy. > I think this has the benefit of being the implementation most users > would expect, as it is consisten with other tools, while having the > least amount of pain for current users of proxies as they would have > time to realize the deprecation notice. Yes I agree. > That would allow you to specify *only* the https_proxy like this: > > http_proxy= > https_proxy=http://localhost:1235 > > $ dillo https://www.google.com > > No warning and Dillo uses https_proxy for HTTPS and HTTP doesn't use a > proxy. > > And over this change, you can add your specific option in dillorc only > to change the way Dillo communicates with the HTTPS proxy to avoid the > CONNECT, with the "https_proxy_use_http=TRUE" or similar option. That would be fine. > Lastly, a similar option was mentioned by Daniel (curl lead developer) > some time ago: https://stackoverflow.com/a/34268925 It doesn't appear that anyone implemented it in Curl though.

June 26, 2024

Re: dillorc long line word wrap

by pastebin＠gmx.com

Hi, yes i see : the text in the alt is treated differently from the text in the html - i can't cut n paste the alt text but can the html text --- Just for completeness i have the images from this site blocked in /etc/hosts but have the tools/load images checked the result is the same appearance wise On Wed, 26 Jun 2024 23:57:05 +0200 Rodrigo Arias <rodarima(a)gmail.com> wrote: > Hi, > > On Wed, Jun 26, 2024 at 03:22:57PM -0600, pastebin(a)gmx.com wrote: > >2 attached pngs > >first with no cursor movement to right > >second with cursor movement to right > > Thanks, it seems to be caused by the long alt text when images are > disabled. I have opened an issue here: > > https://github.com/dillo-browser/dillo/issues/207 > > Best, > Rodrigo. > _______________________________________________ > Dillo-dev mailing list -- dillo-dev(a)mailman3.com > To unsubscribe send an email to dillo-dev-leave(a)mailman3.com

June 26, 2024

Re: dillorc long line word wrap

by Rodrigo Arias

Hi, On Wed, Jun 26, 2024 at 03:22:57PM -0600, pastebin(a)gmx.com wrote: >2 attached pngs >first with no cursor movement to right >second with cursor movement to right Thanks, it seems to be caused by the long alt text when images are disabled. I have opened an issue here: https://github.com/dillo-browser/dillo/issues/207 Best, Rodrigo.

June 26, 2024

Re: dillorc long line word wrap

by pastebin＠gmx.com

2 attached pngs first with no cursor movement to right second with cursor movement to right On Wed, 26 Jun 2024 22:23:20 +0200 Rodrigo Arias <rodarima(a)gmail.com> wrote: > On Tue, Jun 25, 2024 at 02:05:33PM -0600, pastebin(a)gmx.com wrote: > >Hi, > > > >doesn't this dillorc option make 'long text lines' wrap properly in the dillo display area? > > > ># Set this to YES to limit the word wrap width to the viewport width > >#limit_text_width=NO > >limit_text_width=YES > > > >https://hosted.ap.org/article/e5ac7de893189c11c88137fe9b81829e/shot-16-seco… > > Seems to be rendering fine for me, can you send a screenshot? > _______________________________________________ > Dillo-dev mailing list -- dillo-dev(a)mailman3.com > To unsubscribe send an email to dillo-dev-leave(a)mailman3.com

June 26, 2024

Re: Unexpected behaviour.

by Rodrigo Arias

On Wed, Jun 26, 2024 at 12:47:08AM +0300, D wrote: >html tag <caption> makes the table wider. The caption tag is not supported yet. Do you have a test case?

June 26, 2024

Re: dillorc long line word wrap

by Rodrigo Arias

On Tue, Jun 25, 2024 at 02:05:33PM -0600, pastebin(a)gmx.com wrote: >Hi, > >doesn't this dillorc option make 'long text lines' wrap properly in the dillo display area? > ># Set this to YES to limit the word wrap width to the viewport width >#limit_text_width=NO >limit_text_width=YES > >https://hosted.ap.org/article/e5ac7de893189c11c88137fe9b81829e/shot-16-seco… Seems to be rendering fine for me, can you send a screenshot?

June 26, 2024

Re: HTTPS Proxy Support

by Rodrigo Arias

Hi, On Wed, Jun 26, 2024 at 08:52:37AM +1000, Kevin Koster wrote: >Rodrigo Arias <rodarima-Re5JQEeQqe8AvxtiuMwx3w(a)public.gmane.org> wrote: >>>Also I don't think that 'https_endpoint' actually needs to be set >>>from an environment variable, just a dillorc setting would do. >> >> I also think is good if it is only a dillorc option. I'm not sure if I >> like more something like: >> >> https_proxy=http://localhost:1234 > >Ahh, that's what I was doing wrong with Lynx! I didn't include the >"http://" part (which Wget doesn't require, though I see now that >the Wget manual does say it should be set to a URL, not a >hostname). I really do make a meal of this proxy stuff. Yeah, it is a bit confusing :-) >> # Setting this to TRUE sends HTTPS traffic unencrypted to the proxy. >> # Don't change unless you know what you are doing. >> #https_proxy_use_http=FALSE (default) >> https_proxy_use_http=TRUE >> >> For normal uses, setting the https proxy with https_proxy would make >> more sense than using http_proxy for HTTPS traffic anyway. > >If the 'http_proxy' behaviour changes to only apply to HTTP like >in other software, everyone using the 'http_proxy' setting will >have to change their configuration to set 'https_proxy' as well. >That'd be an annoying behaviour change. > >But otherwise using the setting name 'https_proxy' makes it unclear >how that relates to the 'http_proxy' setting that applies to both >HTTP and HTTPS. Sadly, there is no standard (AFAIK) that specifies how to use those variables, but most software tools seem to use them in a more or less coherent way. And I think new users would expect it to follow the same usage than curl, wget or other browsers. It doesn't have to be annoying, we can slowly deprecate the current mechanism by displaying a warning when only http_proxy is set that https_proxy should be set too, and change the behavior in a new release that is clearly documented in the release notes. >If I set: > >http_proxy=http://localhost:1234 >https_proxy=http://localhost:5678 > >It at least needs a comment explaining the difference between the >settings, if indeed you intend there to be one and the second >setting doesn't override the first entirely. > >Since the 'http_proxy' environment variable overrides the dillorc >'http_proxy' setting, 'https_proxy' implies that the same will >apply to that, and it's anyone's guess which will apply if both >are set since other software (Wget, Lynx) doesn't apply the >'http_proxy' environment variable to https. Exactly, I think the logical behavior makes sense. Having both http_proxy and https_proxy as environment variables *and* dillorc options. Each controlling the HTTP and HTTPS proxy independently. The same in the future for ftp_proxy to route FTP traffic. >This is why I now think it best to avoid the 'https_proxy' name, >because the behaviour with it will never be consistent with other >software without changing how Dillo already handles the >'http_proxy' variable/setting. I undertand, but I think this is a good moment to plan how to change how Dillo handles the http_proxy variable, so it only affects HTTP traffic and not HTTPS too. What about this: Setting the env vars as: http_proxy=http://localhost:1234 https_proxy= Now causes a warning (maybe also in the UI): $ dillo https://www.google.com WARNING: Setting http_proxy to specify the HTTPS proxy is deprecated, use https_proxy to define it instead. But still makes Dillo use the http_proxy both for HTTP and HTTPS for now. Also: http_proxy=http://localhost:1234 https_proxy=http://localhost:1235 No warning: $ dillo https://www.google.com But Dillo uses both proxies independently (like curl or wget), instead of the current implementation that would use http_proxy for HTTP and HTTPS. Same with the dillorc options http_proxy and https_proxy (new), keeping the preference for the env vars if defined. The only unexpected change may be for a user that had previously set https_proxy that was not being used by Dillo, and now it would be. But I think that 1) is unlikely they use a different value for HTTP and HTTPS and 2) it is probably intended to use the https_proxy for HTTPS anyway. We could emit a warning about this too, but maybe not needed if we explain that Dillo will handle now the https_proxy variable. In any case, this should be properly explained in the release notes, leaving one release with the deprecation warning for users to take time to change the behavior, before we stop using http_proxy as the HTTPS proxy. I think this has the benefit of being the implementation most users would expect, as it is consisten with other tools, while having the least amount of pain for current users of proxies as they would have time to realize the deprecation notice. That would allow you to specify *only* the https_proxy like this: http_proxy= https_proxy=http://localhost:1235 $ dillo https://www.google.com No warning and Dillo uses https_proxy for HTTPS and HTTP doesn't use a proxy. And over this change, you can add your specific option in dillorc only to change the way Dillo communicates with the HTTPS proxy to avoid the CONNECT, with the "https_proxy_use_http=TRUE" or similar option. Lastly, a similar option was mentioned by Daniel (curl lead developer) some time ago: https://stackoverflow.com/a/34268925 Best, Rodrigo

June 26, 2024

Re: Feature idea: zoom buttons

by Rodrigo Arias

Hi, On Wed, Jun 26, 2024 at 03:26:59PM +0200, a1ex(a)dismail.de wrote: >Hi Rodrigo, > >On Tue, 25 Jun 2024 21:33:54 +0200 >Rodrigo Arias <rodarima(a)gmail.com> wrote: > >> I just merged support for zoom control: >> >> https://github.com/dillo-browser/dillo/pull/156 > >Thanks very much for making this feature happen! > >One thing which I would suggest is also having optional toolbar buttons >to control this. Yeah, I thought about adding three new menu items in the main menu or under a sub-menu, but I like the idea of Firefox and Chromium where they placed both the [-] [+] buttons inside a main menu item. Not sure how hard it would be to do with FLTK. >I would like to think that the Dillo project strives for maximum >accessibility whenever possible, since pretty much all of the other >features are available with mouse controls. There are a variety of >scenerios where this can be desirable. I would like to make Dillo more accessible, but we would need more developers to help. I checked a bit how to integrate it with orca or other text readers but I don't have much experience on that area. >Maybe I could attempt to kludge together a patch at some point, if >there are no other more qualified takers, of course. Thanks, that would be nice. Best, Rodrigo.

June 26, 2024

Re: Feature idea: zoom buttons

by a1ex＠dismail.de

Hi Rodrigo, On Tue, 25 Jun 2024 21:33:54 +0200 Rodrigo Arias <rodarima(a)gmail.com> wrote: > I just merged support for zoom control: > > https://github.com/dillo-browser/dillo/pull/156 Thanks very much for making this feature happen! One thing which I would suggest is also having optional toolbar buttons to control this. I would like to think that the Dillo project strives for maximum accessibility whenever possible, since pretty much all of the other features are available with mouse controls. There are a variety of scenerios where this can be desirable. Maybe I could attempt to kludge together a patch at some point, if there are no other more qualified takers, of course. Regards, Alex

June 26, 2024