- Dillo-dev - lists.mailman3.com

Always show tab-bar

by a1ex＠dismail.de

Hi, I have added a section to my Dillo patches blog post about modding the tab-bar: https://alex.envs.net/blog/dillo/ Basically, I think it would be nice to have an option to always show the tab-bar. Is there any interest in such a feature? Regards, Alex

March 5, 2026

Re: [Issue]: Web search prefix lenght

by Rodrigo Arias

Hi, On Sun, Mar 01, 2026 at 06:47:12PM -0300, Juan M Sevilla wrote: >Hi, I'm using prefixes to search using different websites, but noticed >that this prefix cannot be 1 nor more than 2 characters long. > >For example, I configured Wikipedia in English and Spanish, the former >with prefix "wien" and the latter just "wi". In my dillorc, the English >version is first, so Dillo always uses this one to search, whether I >type "wi hola" or "wien hola". > >I've also set a dictionary with prefix "d", but Dillo always searches >on DuckDuckGo, which has the prefix "dd". > >I wonder if prefixes could be longer or shorter. On Firefox, I'm using >from 1 to 4 characters, the longer ones mainly to differentiate the >English from the Spanish version (Wikipedia; Wiktionary; WordReference >Translate, Dictionaries, Synonim). There is no character limit but Dillo matches the first search entry that starts with the prefix. So "wi" will match both "wi" and "wien". The first match is used. One option is to use prefixes that are not substrings of other prefixes (like wes and wen). I think it makes sense to change the behavior to match only the complete prefix, as the user can write the shortened version manually. So that "wi" won't match "wien", but only "wi". I uploaded the patch here: https://git.dillo-browser.org/dillo/log/?h=match-prefix-exactly Let me know if that works for your. >Otherwise, I can live with the 2-character length, but it would be >great if it was stated on the dillorc file, something like: > >> (the prefix serves to search from the Location Bar. e.g. "dd dillo >> image" and it must be 2 characters long) > >Thank you! I've been using Dillo for six months and I like it very >much :D Glad to read that :) Best, Rodrigo.

March 2, 2026

[Issue]: Web search prefix lenght

by Juan M Sevilla

Hi, I'm using prefixes to search using different websites, but noticed that this prefix cannot be 1 nor more than 2 characters long. For example, I configured Wikipedia in English and Spanish, the former with prefix "wien" and the latter just "wi". In my dillorc, the English version is first, so Dillo always uses this one to search, whether I type "wi hola" or "wien hola". I've also set a dictionary with prefix "d", but Dillo always searches on DuckDuckGo, which has the prefix "dd". I wonder if prefixes could be longer or shorter. On Firefox, I'm using from 1 to 4 characters, the longer ones mainly to differentiate the English from the Spanish version (Wikipedia; Wiktionary; WordReference Translate, Dictionaries, Synonim). Otherwise, I can live with the 2-character length, but it would be great if it was stated on the dillorc file, something like: > (the prefix serves to search from the Location Bar. e.g. "dd dillo > image" and it must be 2 characters long) Thank you! I've been using Dillo for six months and I like it very much :D

March 1, 2026

FLTK 1.4 experimental support

by Rodrigo Arias

Hi, I pushed the fltk-1.4 branch to support building dillo with FLTK >= 1.4. It needs the configure flag --enable-experimental-fltk: https://git.dillo-browser.org/dillo/log/?h=fltk-1.4 The objective is to allow early adopters to build dillo so we can unblock the next 3.3.0 release. There are known problems with scrolling and with font hinting and antialiasing which I will be focusing later. For know I'm interested in testing that dillo can build correctly with FLTK 1.4 on different platforms. To build, use this with the path to fltk-config binary of FLTK 1.4: % ../configure --enable-experimental-fltk FLTK_CONFIG=/.../fltk-config Or manually specify the flags with FLTK_CFLAGS, FLTK_CXXFLAGS and FLTK_LIBS variables. Dillo should report the FLTK version: % dillo -v Dillo v3.2.0-162-g6142b99f Libraries: fltk/1.4.4 jpeg/3.1.2 png/1.6.53 webp/1.6.0 zlib/1.3.1 brotli/1.1.0 OpenSSL/3.6.0 Features: +GIF +JPEG +PNG +SVG +WEBP +BROTLI +XEMBED +TLS +IPV6 +CTL Let me know if you encounter any problems during the build. Patches that solve rendering problems are very much welcome. Best, Rodrigo.

Feb. 22, 2026

Re: [PATCH] Use FL_FOREGROUND_COLOR for widget selection color

by Rodrigo Arias

Hi, On Fri, Feb 20, 2026 at 01:14:33PM +0000, a1ex(a)dismail.de wrote: >Hi, > >Currently Dillo uses a fixed color (black) for the widget selection >color, which includes checkmarks and radio buttons. When using a dark >color scheme, these selections can be invisible or hard to see. Instead, >use the foreground color from dillorc to ensure visibility. > >Patch is attached. Thanks!, merged. >Also, I put up a little blog post with some other Dillo patches, >hopefully someone here will find it interesting! I welcome any feedback. >https://alex.envs.net/blog/dillo Cool! Best, Rodrigo.

Feb. 20, 2026

[PATCH] Use FL_FOREGROUND_COLOR for widget selection color

by a1ex＠dismail.de

Hi, Currently Dillo uses a fixed color (black) for the widget selection color, which includes checkmarks and radio buttons. When using a dark color scheme, these selections can be invisible or hard to see. Instead, use the foreground color from dillorc to ensure visibility. Patch is attached. Also, I put up a little blog post with some other Dillo patches, hopefully someone here will find it interesting! I welcome any feedback. https://alex.envs.net/blog/dillo Regards, Alex

Feb. 20, 2026

Re: Patches for two use-after-free bugs

by Rodrigo Arias

Hi, >I will test it a bit with ASan enabled and merge it if nothing breaks. Merged in 9562d30a: https://git.dillo-browser.org/dillo/log/ Best, Rodrigo.

Feb. 1, 2026

Re: Patches for two use-after-free bugs

by Rodrigo Arias

Hi Magnus, On Sun, Jan 25, 2026 at 11:53:08AM -0700, Nopey Nope wrote: >Thanks for the guidance, Rodrigo! > >Had a better idea on how to fix the socketdata use-after-free; new >attached patch 0002 fixes the bug by only freeing the queued sockdata >if it's exclusively owned by the server queue. > >I've added information in the commit summaries as suggested. > >I also added an assert in Http_socket_enqueue, which makes explicit >the precondition that socketdata can only be queued to one server at a >time. >This assert has not tripped, and hopefully never will; I thought it >helped illustrate the relation between servers and socketdatas. Thanks a lot!, they both look good. I'll leave the assert in Http_socket_enqueue but remove the message string as it causes a warning in gcc and I don't think is needed for this case. https://git.dillo-browser.org/dillo/log/?h=fix-uaf I will test it a bit with ASan enabled and merge it if nothing breaks. Best, Rodrigo.

Jan. 31, 2026

Re: Patches for two use-after-free bugs

by Nopey Nope

Thanks for the guidance, Rodrigo! Had a better idea on how to fix the socketdata use-after-free; new attached patch 0002 fixes the bug by only freeing the queued sockdata if it's exclusively owned by the server queue. I've added information in the commit summaries as suggested. I also added an assert in Http_socket_enqueue, which makes explicit the precondition that socketdata can only be queued to one server at a time. This assert has not tripped, and hopefully never will; I thought it helped illustrate the relation between servers and socketdatas. Magnus On Sat, Jan 24, 2026 at 2:10 PM Rodrigo Arias <rodarima(a)gmail.com> wrote: > > Hi Magnus, > > On Sat, Jan 24, 2026 at 11:13:25AM -0800, Nopey Nope wrote: > >Hello! > > > >Find attached two patches, which each fix a use-after-free bug. > > > >I've also attached a crashing html document for each, but please be > >aware that these reproducer documents link urls from external web > >servers. > >The reproducers crash reliably on my x86_64 Void Linux laptop, but > >I've not tested them elsewhere. I've also attached a crash log with > >asan reporting of each. > > > >Thank you > >-Magnus L > > > >p.s. I've also opened github PR 449 with these same changes, but > >figured I should send the patches via email as well-- if only for > >practice :) > > Thanks a lot for the patches and reproducers! > > I saw the PR but I only had time to look at the "Fix use-after-free in > openssl cert popup" commit which seems good. We are moving away from > GitHub so it would be nice to send future patches here (or a link to a > git repo/branch to fetch with git). > > It would help to describe what is the condition that triggers the UAF in > the Http_server patch and why the change helps, so that it is easier to > review. > > Perhaps it would be a good idea to put that information it in the commit > summary of both patches so we can see it via git blame. > > Best, > Rodrigo. > _______________________________________________ > Dillo-dev mailing list -- dillo-dev(a)mailman3.com > To unsubscribe send an email to dillo-dev-leave(a)mailman3.com

Jan. 25, 2026

Re: Patches for two use-after-free bugs

by Rodrigo Arias

Hi Magnus, On Sat, Jan 24, 2026 at 11:13:25AM -0800, Nopey Nope wrote: >Hello! > >Find attached two patches, which each fix a use-after-free bug. > >I've also attached a crashing html document for each, but please be >aware that these reproducer documents link urls from external web >servers. >The reproducers crash reliably on my x86_64 Void Linux laptop, but >I've not tested them elsewhere. I've also attached a crash log with >asan reporting of each. > >Thank you >-Magnus L > >p.s. I've also opened github PR 449 with these same changes, but >figured I should send the patches via email as well-- if only for >practice :) Thanks a lot for the patches and reproducers! I saw the PR but I only had time to look at the "Fix use-after-free in openssl cert popup" commit which seems good. We are moving away from GitHub so it would be nice to send future patches here (or a link to a git repo/branch to fetch with git). It would help to describe what is the condition that triggers the UAF in the Http_server patch and why the change helps, so that it is easier to review. Perhaps it would be a good idea to put that information it in the commit summary of both patches so we can see it via git blame. Best, Rodrigo.

Jan. 24, 2026