- Dillo-dev - lists.mailman3.com

Re: [PATCH] Prevent DilloPlain::write() from reading past end of buffer

by 256＠256-32.com

DilloPlain:write() is written in such a way that it can receive a file one part at a time, rather than all at once. As such, it might receive "line 1\r" and then "\nline 2". I'm not sure if that actually happens in practise, and I haven't been able to provoke this behaviour to test it (piping bytes into netcat with a sleep delay didn't do it), but I think the old code would turn that \r\n into 2 line breaks instead of 1, because the function is called separately for both parts. I hope that makes sense. Most of the complexity of my patch consists of dealing with that. Maybe there's still a simpler way to deal with it, though.

Oct. 12, 2026

Re: [PATCH] Prevent DilloPlain::write() from reading past end of buffer

by Rodrigo Arias

Hi, On Thu, Sep 10, 2026 at 02:21:53PM +0100, 256(a)256-32.com wrote: >In src/plain.cc, \r\n sequences are handled with these lines: > >while ( i < MaxBytes ) { > ... > addLine(Start + i - len, len); > if (Start[i] == '\r' && Start[i + 1] == '\n') ++i; > if (i < MaxBytes) ++i; > ... > >So if a \r occurs, skip over the \n if present. But if i + 1 == MaxBytes, >Start[i + 1] is one past the end of the buffer, which is an out-of-bounds read. >This happens if a file ends in \r, or I suppose if a file gets broken up and >parsed with multiple invocations of the function. I think this could >theoretically add a redundant line break to the rendered page. > >My diff fixes this. I have tested it with \r, \r\n, and \n line endings. I >haven't been able to test how it behaves with plaintext pages that are parsed in >multiple invocations, though. > >(Also, and this is unrelated but it bothers me: prefsparser.cc has a comment >saying the `symbols` array is sorted, but it isn't.) > > >diff --git a/src/plain.cc b/src/plain.cc >index 0f5d6a48..e085ab19 100644 >--- a/src/plain.cc >+++ b/src/plain.cc >@@ -142,7 +142,10 @@ void DilloPlain::addLine(char *Buf, uint_t BufSize) > { > int len; > char buf[129]; >- char *end = Buf + BufSize; >+ char *end; >+ >+ if (BufSize > 0 && Buf[BufSize - 1] == '\r') --BufSize; >+ end = Buf + BufSize; > > currentLine++; /* Start at 1 */ > sprintf(buf, "L%ld", currentLine); /* Always fits */ >@@ -181,7 +184,8 @@ void DilloPlain::write(void *Buf, uint_t BufSize, int Eof) > while ( i < MaxBytes ) { > switch ( state ) { > case ST_SeekingEol: >- if (Start[i] == '\n' || Start[i] == '\r') >+ if (Start[i] == '\n' || (Start[i] == '\r' && i + 1 < MaxBytes >+ && Start[i + 1] != '\n')) > state = ST_Eol; > else { > ++i; ++len; >@@ -189,8 +193,7 @@ void DilloPlain::write(void *Buf, uint_t BufSize, int Eof) > break; > case ST_Eol: > addLine(Start + i - len, len); >- if (Start[i] == '\r' && Start[i + 1] == '\n') ++i; >- if (i < MaxBytes) ++i; >+ ++i; Why not just this? diff --git a/src/plain.cc b/src/plain.cc index 0f5d6a48..343cc05c 100644 --- a/src/plain.cc +++ b/src/plain.cc @@ -189,7 +189,8 @@ void DilloPlain::write(void *Buf, uint_t BufSize, int Eof) break; case ST_Eol: addLine(Start + i - len, len); - if (Start[i] == '\r' && Start[i + 1] == '\n') ++i; + if (Start[i] == '\r' && i + 1 < MaxBytes && Start[i + 1] == '\n') + ++i; if (i < MaxBytes) ++i; state = ST_SeekingEol; len = 0; Best, Rodrigo.

Oct. 11, 2026

Re: [PATCH 2/2] form input: try to find defaults for buttons without a value

by Rodrigo Arias

Hi, Sorry for the delay. On Sat, Aug 22, 2026 at 09:24:22AM +0200, Andreas Kemnade wrote: >This also prevents crashes due to resource == NULL >Examples can be found at https://www.pythontutorial.net/python-oop/ >--- > src/form.cc | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > >diff --git a/src/form.cc b/src/form.cc >index 038b94f3..e9b9c984 100644 >--- a/src/form.cc >+++ b/src/form.cc >@@ -538,7 +538,8 @@ void Html_tag_open_input(DilloHtml *html, const char *tag, int tagsize) > } else if (!dStrAsciiCasecmp(type, "button")) { > inp_type = DILLO_HTML_INPUT_BUTTON; > if (value) { We want to always create the button even with no value, so we need the resource. >- init_str = value; >+ label = value ? value : name ? name : "Submit"; From <https://html.spec.whatwg.org/multipage/input.html#button-state-(type=button)>: >If the element has a value attribute, the button's label must be the >value of that attribute; otherwise, it must be the empty string. I would also prefer to leave it empty to make it visible that the value is missing, otherwise you may not realize it has no value. I ended up merging the patch I wrote a while ago when the HTML fuzzer I'm testing triggered the same bug: https://git.dillo-browser.org/dillo/commit/?id=0a5e76decf21b042e6829a3616fe… For the same reason, I want to avoid this: >- if (inp_type != DILLO_HTML_INPUT_UNKNOWN) { >+ if ((inp_type != DILLO_HTML_INPUT_UNKNOWN) && (resource || embed)) { So it crashes when there is not resource and no embed. I added an assert: https://git.dillo-browser.org/dillo/commit/?id=784bedf88b37d70e283dd0490e3b… There should be not more cases left in which we arrive with no resource or embed, but let me know otherwise. Thanks!, Rodrigo.

Oct. 11, 2026

Re: Pasta Market: Changing Consumer Preferences and New Opportunities

by Jesse Lawton

Uhh don't really think this has anything to do with dillo lol On Wed, Oct 07, 2026 at 09:07:55AM +0000, riyaj.reed(a)gmail.com wrote: > The global pasta market is evolving as consumers increasingly seek convenient, versatile, and affordable food options that fit modern lifestyles. Pasta remains a staple across households and foodservice establishments because of its ease of preparation, long shelf life, and ability to complement a wide range of sauces and ingredients. From traditional wheat pasta to whole-grain, gluten-free, organic, and plant-based varieties, manufacturers are expanding their product portfolios to meet changing dietary preferences. > > The pasta market is benefiting from the growing popularity of convenient meal solutions. Busy consumers often prefer foods that can be prepared quickly without compromising taste or versatility. Pasta can be incorporated into numerous cuisines, making it attractive to consumers across different regions. Product innovation is also contributing to market opportunities, with companies introducing new shapes, flavors, ingredients, and packaging formats designed to improve convenience and appeal to health-conscious shoppers. > > Source: https://www.marketresearchfuture.com/reports/pasta-market-2428 > _______________________________________________ > Dillo-dev mailing list -- dillo-dev(a)mailman3.com > To unsubscribe send an email to dillo-dev-leave(a)mailman3.com -- Thanks Jesse Lawton

Oct. 7, 2026

Pasta Market: Changing Consumer Preferences and New Opportunities

by riyaj.reed＠gmail.com

The global pasta market is evolving as consumers increasingly seek convenient, versatile, and affordable food options that fit modern lifestyles. Pasta remains a staple across households and foodservice establishments because of its ease of preparation, long shelf life, and ability to complement a wide range of sauces and ingredients. From traditional wheat pasta to whole-grain, gluten-free, organic, and plant-based varieties, manufacturers are expanding their product portfolios to meet changing dietary preferences. The pasta market is benefiting from the growing popularity of convenient meal solutions. Busy consumers often prefer foods that can be prepared quickly without compromising taste or versatility. Pasta can be incorporated into numerous cuisines, making it attractive to consumers across different regions. Product innovation is also contributing to market opportunities, with companies introducing new shapes, flavors, ingredients, and packaging formats designed to improve convenience and appeal to health-conscious shoppers. Source: https://www.marketresearchfuture.com/reports/pasta-market-2428

Oct. 7, 2026

Re: How minimalist should Dillo be?

by 256＠256-32.com

Thank you for replying. I'm aware you're busy, so please don't feel obligated to respond immediately; this thread will still be here in October. On Sat, Sep 26, 2026 at 02:05:34PM +0200, Rodrigo Arias wrote: > I'll suggest implementing first the tests that fail due to unsupported cache > support. Take a look at https://github.com/dillo-browser/testsuite (pending > to be moved to our server) and see if there is something in WPT that we can > reuse to test dillo (without JS). I've had a quick look through the WPT repository. It has some caching-related HTTP tests, but seemingly not that many that are relevant to Dillo. I'm tempted to write my own HTTP testing system; I've already done so before, although that was for a server rather than a client. Maybe I'll adapt some things from WPT. > The layout engine has nothing to do with expires. I'm aware, I mentioned it as a separate thing.

Sept. 26, 2026

Re: How minimalist should Dillo be?

by Rodrigo Arias

Hi, I will be unable to work on Dillo or reply for the next weeks, probably around mid-October I can come back. On Fri, Sep 25, 2026 at 05:09:47PM +0100, 256(a)256-32.com wrote: >I want to improve Dillo in a bunch of ways, most urgently by adding support for >the "expires" HTTP header field, and improving the HTML/CSS rendering. I'm >worried, though, that if I submit a huge patch to do one of these things it'd >get rejected for not being minimalist enough. The current blocker from implementing this is the infrastructure to test that new features work fine. I wrote dilloc with this kind of tests in mind so we can do more complicated HTTP tests and see if it works properly. Until we don't have the tests I don't think I want to implement new features we cannot test (other than manually). I'll suggest implementing first the tests that fail due to unsupported cache support. Take a look at https://github.com/dillo-browser/testsuite (pending to be moved to our server) and see if there is something in WPT that we can reuse to test dillo (without JS). We can merge the failing tests first, then focus on the implementation in dillo for expires and other headers and check that the test pass. In the testsuite we can use python or other high-level tools that make writing tests easier than C (that is why it is separated from the dillo code). >My question is, would substantially fleshing out the layout and style >engines be seen as going against the spirit of Dillo? The layout engine has nothing to do with expires. I would recommend not touching the layout engine for now (mostly for the same reason, lack of tests). >Would it push too far against the 1.44MB limit? It is unlikely that you will pass that limit with handwritten code, as gzip will compress your code with the current codebase. Don't worry too much about that, there are stuff pending to be removed that will make some room and I have some provisions to make more room if that limit is reached. Thanks!, Rodrigo.

Sept. 26, 2026

Re: How minimalist should Dillo be?

by a1ex＠dismail.de

256(a)256-32.com wrote: > My question is, would substantially fleshing out the layout and style > engines be seen as going against the spirit of Dillo? Would it push > too far against the 1.44MB limit? It's important to keep Dillo as lean as possible for sure, but at this point 1.44MB seems completely arbitrary. If it's getting in the way of real progress, then it's self-defeating to keep that limit. Speaking as someone who has various vintage computers with floppy drives (some of which even run Dillo), I wonder if there is a single person in the world who actually NEEDS to use floppy disks to transport the source code, even in the most impoverished / low-tech areas. In any case, they could transport the source on TWO floppies instead! The idea of poor kids in sub-saharan Africa using Dillo on ancient computers is cute, but they are all probably using smartphones now. (I don't speak for the Dillo project, this is just my personal opinion) Regards, Alex

Sept. 26, 2026

How minimalist should Dillo be?

by 256＠256-32.com

I want to improve Dillo in a bunch of ways, most urgently by adding support for the "expires" HTTP header field, and improving the HTML/CSS rendering. I'm worried, though, that if I submit a huge patch to do one of these things it'd get rejected for not being minimalist enough. DilloNG (which is abandoned) and Dillo+ are both hosted on GitHub, and I'd rather not use that site. I don't want to fork the browser and deal with all the overhead of hosting and distribution. And I definitely don't want to write my own browser from scratch. My question is, would substantially fleshing out the layout and style engines be seen as going against the spirit of Dillo? Would it push too far against the 1.44MB limit?

Sept. 25, 2026

Re: Rendering math in Wikipedia

by Ethan James Sue

Thank you very much, works perfectly! ________________________________ From: Rodrigo Arias <rodarima(a)gmail.com> Sent: Tuesday, September 22, 2026 5:02 PM To: Dillo development <dillo-dev(a)mailman3.com> Subject: [Dillo-dev] Re: Rendering math in Wikipedia Attention : courriel externe | external email Hi, On Sun, Sep 20, 2026 at 06:53:50PM +0000, Ethan James Sue wrote: >Dear fellow Dillo users, > >When math equations are rendered in Wikipedia, they seem to render >three times. For example, in the attached screenshot, it says "p i", >then the markdown "{\displaystyle p^{i}}", and then the image. I see >that SVG support for Wikipedia math formulas was added in 2025, so I >wonder if this is a known issue with a workaround. Yes, is a known issue. >Any advice would be appreciated! Try this CSS rule to hide the MathML and LaTeX output: echo '.mwe-math-mathml-a11y { display: none !important; }' >> ~/.dillo/style.css Best, Rodrigo. _______________________________________________ Dillo-dev mailing list -- dillo-dev(a)mailman3.com To unsubscribe send an email to dillo-dev-leave(a)mailman3.com

Sept. 22, 2026