Search results for "plugin" - Dillo-dev

Re: dillo plugin patches

by John McCue

On Sat, Nov 01, 2025 at 12:34:17AM +0100, Rodrigo Arias wrote: >Hi, > >I added an exception for your email to the list. Following replies >should get archived. Thanks >On Fri, Oct 31, 2025 at 11:34:04AM -0400, John McCue wrote: [...] >>2. dpi.txt -- Corrects an odd issue on OpenBSD with the >> gopher plugin. Access a gopher hole works fine on first >> try, accessing a 2nd hole does nothing, no data is >> presented. Selecting the "Stop" button in dillo works to >> stop the attempted load. My wild guess is one of the >> casts fixed the issue. > >I cannot reproduce this, with or without the patch. Tested in order: > >- gopher://gopher.quux.org:70/1/ >- gopher://gopher.floodgap.com/ > >If you can reliably reproduce this, you could dump the backtrace while >is "doing nothing" in case it got stuck in some network operation. > I'll try and backtrace, I never did that before, I usually throw printfs all over the place. But ... the version from git clone https://git.dillo-browser.org/plugins/gopher is working after I added this <sys/socket.h> to io.c to compile it. I also checked the original version, that works now, very odd. I will play around with this to see if I could figure out what I may have done differently. [...] >> buf[30] = '\0'; >>- rc = sscanf(buf, "<cmd='auth' msg='%4x' '>", key); >>+ rc = sscanf(buf, "<cmd='auth' msg='%4x' '>", (unsigned int *) key); >The address of key may not be aligned to the size of a word. Some >architectures will cause an invalid access trying to write an int to a >non-aligned address. > >A better solution is to declare key as an unsigned int. I applied your >fixes and then changed the key variables. This sounds fine by me, I just made changes to "get it working" :) [...] >>diff --git a/Makefile b/Makefile >>index 1ff7047..e41e173 100644 >>--- a/Makefile >>+++ b/Makefile >>@@ -13,6 +13,7 @@ $(DPIDRC): >> mkdir -p $(DPI_DIR) >> if [ -f /etc/dillo/dpidrc ]; then cp /etc/dillo/dpidrc $@; \ >> elif [ -f /usr/local/etc/dillo/dpidrc ]; then cp /usr/local/etc/dillo/dpidrc $@; \ >>+ elif [ -f /usr/pkg/etc/dillo/dpidrc ]; then cp /usr/pkg/etc/dillo/dpidrc $@; \ >> else echo "Can't find dpidrc, is dillo installed?"; false; fi > >This is not in our upstream, but I would rather avoid having each >possible path here. I added a DILLO_PREFIX variable, empty by default. >So you can use `make install DILLO_PREFIX=/usr/pkg` to find dpidrc in >your system. By default it only looks at /etc/dillo/dpidrc. Fine by me. >>diff --git a/io.c b/io.c >>index 615f346..f437c2e 100644 >>--- a/io.c >>+++ b/io.c >>@@ -7,6 +7,7 @@ >>#include <fcntl.h> >>#include <netdb.h> >>#include <netinet/in.h> >>+#include <sys/socket.h> > >Applied. > >> >>#include "io.h" >> > >I fixed several other problems and set the C standard to C99 and >enabled POSIX 2001 by default in CFLAGS. I also performed the build >with gcc and clang on Linux with -Werror -Wall -Wextra -pedantic as >well as with -fsanitize=address to see if I catch something while >running the plugin. Nothing so far. > >I pushed it here (we are moving away from GitHub): > > https://git.dillo-browser.org/plugins/gopher/log/?h=fix-bsd > >Let me know if you encounter problems building it on any BSD. After I added this <sys/socket.h> to io.c I can compile it on OpenBSD. I attached the warnings to this email as warn_openbsd.txt in case you want it. I think many of the warnings can be ignored. NetBSD has no warnings and it too works fine. >Thanks!, >Rodrigo. John

2 months, 4 weeks

Re: Firefox bookmarks plugin

by Diego

El mar, 27 ago 2024 a las 23:17, Rodrigo Arias (<rodarima(a)gmail.com>) escribió: > > Hi, > > On Mon, Aug 26, 2024 at 01:31:13AM +0200, Diego wrote: > >Good work and very interesting idea. > > Thanks! > > >If I can suggest a change I would add this lines to dpidrc at Makefile > >the installation > > > ># Default dillo bookmarks dpi > >#bookmarks=bookmarks/bookmarks.dpi > ># ffbm: A Dillo plugin to sync bookmarks with Firefox > >bookmarks=$(DPI_DIR)/$(BIN) > > > > > >maybe it's time to patch dpidrc to make it more descriptive > > > >I sugest this > >dpi_dir=/usr/local/lib/dillo/dpi > > > ># standard dillo distributed DPIs > >#bookmarks=bookmarks/bookmarks.dpi > >#cookies=cookies/cookies.dpi > >#downloads=downloads/downloads.dpi > >#vsource=vsource/vsource.filter.dpi > > The file dpidrc only registers the protocols (ftp: -> ftp dpi), the dpis > are taken from the dpi_dir or ~/.dillo/dpi automatically. > I know. > It doesn't require describing the available dpis in the file. Not sure > what would be the advantage of doing so. For reference. To explain to the user how to switch between a built-in DPI and another DPI for the same service. Maybe a documentation patch better? I can try to write some documentation about it Diego.

1 year, 5 months

Ignore a command line option (for Mac OS bundles)

by rf.opensource＠gmail.com

On Sun, Jun 5, 2011 at 11:31 AM, corvid <corvid(a)lavabit.com> wrote: > > I could use a bit of advice though. In my preliminary experiments, > > I'm having a bit of problem with the dpi related dynamic libraries. > > I can get dillo to run on another machine with libpng, libjpeg and > > zlib copied over to /usr/local/lib, but none of the plugins work. I > > have copied the usr/local/lib/dillo folder too, and also > > /usr/local/bin/dpid and /usr/local/bin/dpic, but still the plugins > > do not work in the target system. Any files I forgot to copy over? > > How about dpidrc? > > > Thanks, yes it works. I had forgotten the following: /usr/local/etc/dillo/dillorc /usr/local/etc/dillo/dpidrc /usr/local/etc/dillo/ Now most of the plugins seem to work, at least bookmarks work fine. There is still a problem remaining though. In the target machine, I cannot open sites that require SSL (for example www.gmail.com, mail.yahoo.com) I'm not sure why it happens. Is there any library that helps in SSL connections that I forgot copying over? BTW, I tried following Makefile to see what happens for make install, but since it is autogenerated by autoconf it's a bit too complex to follow manually :(

14 years, 7 months

claws? (Re: [Dillo-dev] Garbage chars added)

by jcid＠dillo.org

Hi Paul, On Fri, Oct 24, 2008 at 08:21:29AM +0100, Paul wrote: > [...] > "dillo -l -f -x XID URL" these options are known by the Claws Mail team, they > are built into the Claws Mail Dillo Browser plugin - iirc, they first > appeared in Dillo as a result of a discussion between Melvin, the developer > of the plugin, and the Dillo team. The Claws Mail users do know these > options, at least through the plugins preferences page, and, I would imagine, > the majority of them do use these options. imo, having the option to avoid > loading of remote content is crucial in an email app's html message display. Thanks for the info. > Athur F. Ucksayke from #claws is interested what command: "dillo -l -f > -x XID URL" is supposed to do? Is this documented? Not documented. In dillo2: - This enables the SPAM safe mode (no images/resource loading). - It doesn't embed the window because we don't yet know how to do it. - Full screen is ignored - The URL is shown. As this was a "blind workaround" (i.e. not tested), would you mind trying whether it works. It should start a dettached dillo2 window in SPAM safe mode, with browser controls showing. As for proper implementation of those CLI switches in the future, who should I contact? I assume by your email you're a good person to ask. -- Cheers Jorge.-

17 years, 3 months

Re: FWD - dillo gopher plugin issue (reddit)

by Rodrigo Arias

Hi Alex, John, On Thu, Oct 30, 2025 at 12:05:51PM +0000, a1ex(a)dismail.de wrote: > Hi, > > I saw this issue on Reddit today pertaining to the Gopher plugin not > working correctly on OpenBSD. It includes a fix (I haven't tested it): > > https://eddrit.com/r/openbsd/comments/1oj3ljg/dillo_gopher_plugin_issue_wor… Thanks, I saw it as well. Nice frontend btw. > Date: Thu, 30 Oct 2025 11:10:21 -0400 > From: John McCue <jmccue(a)jmcunx.com> > To: a1ex(a)dismail.de > Cc: dillo-dev(a)mailman3.com > Subject: Re: Dillo gopher plugin on OpenBSD issue > > > [...] > > Somehow I missed it seeing there was a list. I found another > issues with the gopher plugin on OpenBSD. > > The issue I am testing is with dpi.c. On OpenBSD, it has to > do with how clang works on OpenBSD. The diffs are below. I can reproduce many issues on Linux with `CC=clang make`. I'm getting a few more warnings that should be easy to solve. > So far, with the changes to io.c and dpi.c, the plugin > works fine on both OpenBSD and NetBSD. > > diff --git a/io.c b/io.c > index 615f346..a10a0b3 100644 > --- a/io.c > +++ b/io.c > @@ -1,3 +1,4 @@ > +#include <sys/param.h> > #include <string.h> > #include <errno.h> > #include <unistd.h> > @@ -8,6 +9,12 @@ > #include <netdb.h> > #include <netinet/in.h> > > +#ifdef OpenBSD I don't think we need to handle OpenBSD differently, but instead make the code portable by targeting C and POSIX standards. > +#include <sys/socket.h> This is always needed as we use socket(), but it should not be needed here as it would be included via <netinet/in.h>, from netinet_in.h(0P): > Inclusion of the <netinet/in.h> header may also make visible all > symbols from <inttypes.h> and <sys/socket.h> Not sure if OpenBSD follows this, otherwise can simply include it unconditionally. > +#include <net/if.h> > +#include <net/route.h> Needed? > +#endif > + Building with: % make CC=clang CFLAGS="-std=c11 -Wall -pedantic" Already reveals many problems. We can probably lower the C standard to C99. I don't have a machine with OpenBSD at hand, can you test if the build succeeds using the current master code in OpenBSD with these CFLAGS? It does on Linux: % git clone https://git.dillo-browser.org/plugins/gopher && cd gopher % make CC=clang CFLAGS="-Wall -std=c99 -D_POSIX_C_SOURCE=200112L" There are many warnings that should be fixed (as below), but the current includes should work otherwise. If not, does adding the extra + #include <sys/socket.h> line solves it? > #include "io.h" > > int read_all(int fd, unsigned char *buf, size_t len) { > > > diff --git a/dpi.c b/dpi.c > index 7b38800..52547f8 100644 > --- a/dpi.c > +++ b/dpi.c > @@ -7,7 +7,7 @@ > #include "io.h" > > static void check_auth() { > - char buf[30]; > + char buf[31]; > int rc; > char key[4], local_key[4]; > char keys[128]; > @@ -16,16 +16,16 @@ static void check_auth() { > rc = read_all(STDIN_FILENO, buf, 29); > if (rc < 0) err(1, "read auth"); > buf[30] = '\0'; > - rc = sscanf(buf, "<cmd='auth' msg='%4x' '>", key); > + rc = sscanf(buf, "<cmd='auth' msg='%4x' '>", (unsigned int *) > key); if (rc < 0) err(1, "auth: %.*s", 29, buf); The patch is badly mangled, better use `git send-patch` or attach it as a file. > if (rc < 1) errx(1, "auth: %.*s", 29, buf); > home = getenv("HOME"); > if (!home) home = "."; > sz = read_file(keys, sizeof(keys), > "%s/.dillo/dpid_comm_keys", home); if (sz < 0) err(1, "read dillo comm > keys"); > - rc = sscanf(keys, "%*d %4x' '>", local_key); > - if (rc < 0) err(1, "comm key: %.*s", sz, keys); > - if (rc < 1) errx(1, "comm key: %.*s", sz, keys); > + rc = sscanf(keys, "%*d %4x' '>", (unsigned int *) local_key); > + if (rc < 0) err(1, "comm key: %.*s", (int) sz, keys); > + if (rc < 1) errx(1, "comm key: %.*s", (int) sz, keys); > if (memcmp(key, local_key, 4)) errx(1, "wrong dillo key"); > } > > @@ -38,7 +38,7 @@ static void get_url(char *url_buf, size_t url_len) { > rc = read_all(STDIN_FILENO, buf, sizeof(buf)); > if (rc < 0) err(1, "read open_url"); > if (strncmp(buf, "<cmd='open_url' url='", 21)) { > - err(1, "bad open_url cmd: %.*s", sizeof(buf), buf); > + err(1, "bad open_url cmd: %.*s", (int) sizeof(buf), > buf); } > len = url_len; > rc = read_some(STDIN_FILENO, url_buf, &len); > @@ -48,7 +48,7 @@ static void get_url(char *url_buf, size_t url_len) { > if (url_buf[i] == '\'' && url_buf[i+1] == ' ') break; > } > if (i > len-3 || strncmp(url_buf + i, "' '>", 4)) { > - err(1, "bad url end: %.*s", len, url_buf); > + err(1, "bad url end: %.*s", (int) len, url_buf); > } > url_buf[i] = '\0'; > } > Thanks!, Rodrigo.

3 months

Connection problems on Mac OS X 10.6.7

by rf.opensource＠gmail.com

On Fri, May 27, 2011 at 12:46 PM, Benjamin Johnson <obeythepenguin(a)gmail.com > wrote: > On Fri, 27 May 2011 13:38:43 -0400, reza farivar <rf.opensource(a)gmail.com> > wrote: > > Yes. Well, the only plugin I could see is the save button on the panel, >> and >> it can successfully navigate the filesystem and save a page correctly. >> > > That one isn't a plugin, actually. Does the bookmarks button work? > > Yes, bookmarks work. (This is a bit of strange implementation of bookmarks, no? took me a bit to find out difference of section and item) > (Dillo's plugins right now are bookmarks, cookies, downloads, view source, > and data/file/ftp/https URIs. They're not Flash-type graphical plugins, but > things that really should be built into the browser.) > > View source works too, and chances are cookies are working (otherwise many servers would complain). I cant find the rest (downloads, etc.) > > Yes, Here's the result. I tried it a couple of times, and this looks like >> the culprit: >> >> #13 0x000000010007d373 in do_queued_events () at style.hh:554 >> #14 0x000000010007ffa0 in fl_mac_flush_and_wait () at style.hh:554 >> #15 0x0000000100083c6f in Fl::run () at style.hh:554 >> >> Those three lines are consistent everytime I break in GDB. The more >> detailed >> ones are different of course. Here's one, just in case: >> >> #0 0x00007fff87967dc5 in tiny_malloc_from_free_list () >> #1 0x00007fff87966fdd in szone_malloc_should_clear () >> #2 0x00007fff8799d32b in szone_memalign () >> #3 0x00007fff879a46eb in malloc_zone_memalign () >> #4 0x00007fff87376608 in CFSortIndexes () >> #5 0x00007fff87376480 in CFQSortArray () >> #6 0x00007fff87386ad2 in __CFRunLoopDoObservers () >> #7 0x00007fff87361da4 in CFRunLoopRunSpecific () >> #8 0x00007fff842457ee in RunCurrentEventLoopInMode () >> #9 0x00007fff842455f3 in ReceiveNextEventCommon () >> #10 0x00007fff842454ac in BlockUntilNextEventMatchingListInMode () >> #11 0x00007fff85739e64 in _DPSNextEvent () >> #12 0x00007fff857397a9 in -[NSApplication >> nextEventMatchingMask:untilDate:inMode:dequeue:] () >> #13 0x000000010007d373 in do_queued_events () at style.hh:554 >> #14 0x000000010007ffa0 in fl_mac_flush_and_wait () at style.hh:554 >> #15 0x0000000100083c6f in Fl::run () at style.hh:554 >> #16 0x0000000100003a85 in main (argc=1, argv=0x7fff5fbff828) at >> dillo.cc:431 >> > > It looks like the problem's somewhere in FLTK. I'll take a look and see > what I can find. > > Cheers, > ~Benjamin > > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev >

14 years, 8 months

website FAQ update

by jcid＠dillo.org

On Thu, May 15, 2008 at 06:49:11PM +0000, corvid wrote: > I made http://www.dillo.org/FAQ.corvid.html > The old FAQ is still at http://www.dillo.org/FAQ.html for now. > > So if you have comments/find mistakes/whatever.... Yes. > Q: I have an addition to the FAQ/website. Whom do I contact? > > Send all such additions, as well as general questions about the website, to > the webmaster J?rgen Viksell. better to use dillo-dev instead nowadays? Please try to contact J?rgen. If he doesn't answer, leave dillo-dev as the only contact until we find somebody else. > Q: Why isn't Dillo-0.8.x rendering some HTML entities (such as &euro)? Please remove this question as it is specific to dillo1. The web site, and all its information should focuse in dillo2. BTW, it'd be good to state in the FAQ that dillo1 is unmaintained. Something like: Q: What's the state of dillo1 (dillo-0.8.x series)? dillo-0.8.x is unmaintained. It depends on an obsolete library and dillo2 has achieved and surpassed all it had to offer. [In the future we may add a link to the Changelog and to the Plans page] > Q: How do I use a different charset with Dillo? > Internationalization and Localization (i18n & l10n) > > FLTK port > [...] With regard to FLTK: s/FLTK/FLTK2/g in the whole FAQ. Several people write me saying they can't compile dillo2 with FLTK1! Let's try to avoid that misunderstanding. And in this particular case, we can re-word it like this: "Since dillo was ported to FLTK2, the UTF-8 character encoding is used internally. Dillo uses the iconv ..." > Q: How do I enable the https (SSL) support plugin for dillo? Well, currently the CVS has it enabled, but it is definitely worth stating that it's a bare-bones plugin. Also, we can't make a release with HTTPS enabled until we solve the dialog spamming that happens on sites with multiple resources. This is, porting the https filter dpi plugin to a dpi server plugin. Before the release, something like: Q: What's the state of HTTPS support? First of all, beware that this is a prototype in alpha state. It will only provide for very basic web page retrievals, POST and GET. We need to port it internally fomr dpi filter to dpi server. If you want to help us to improve the plugin, please let us know! could do it. > Q: What's the status of the FLTK port? I'd say something like: Code using the FLTK2 GUI toolkit was made publically available in September 2007, and progress has since accelerated. It has become the main development branch, and the GTK1 based dillo1 (0.8.x series) went unmantained. Dillo2 provides much more than the old one. Developers are encouraged to try it out. Users are advised to wait until a release is made. _Experienced_ users may try it out. [a link to the CVS page with build directions is needed here] > Q: Why does the page X.Y look strange? It'd be good here to add something about the HTML bug meter: In the lower-right corner of Dillo you'll see a bug-shaped icon. Click on it to see the detected HTML errors. More info [add link to: http://www.dillo.org/help/bug_meter.html] That's it for me. Once done, let it be the new FAQ, and feel free to improve upon! -- Cheers Jorge.-

17 years, 8 months

https plugin status

by onepoint＠starurchin.org

On Sat, Mar 15, 2008 at 01:22:09AM +0000, Jeremy Henty (ie. me) wrote: > I was wrong, the https filter dpi *is* starting. But, its debugging > messages don't appear because it sends them to stdout, which dpid > redirects to the DPI socket. This feels ... somehow ... wrong. And so it is! (Patch submitted in a new thread.) After redirecting the debugging messages to stderr I see: [https dpi]: {In https.filter.dpi} [https dpi]: ***Value of cmd, url or http_query is NULL - cannot continue [https dpi]: { exiting https.dpi} which at least gives some idea of what is going wrong. Jeremy Henty

17 years, 10 months

https plugin status

by onepoint＠starurchin.org

On Sat, Mar 15, 2008 at 02:18:27AM +0000, place wrote: > It appears that Capi_dpi_build_cmd() needs to test for "proto.https" > instead of "https"... Or maybe Capi_url_uses_dpi() should be checking for "https" and *not* adding the "proto." prefix? I'm just guessing here, I'm still figuring out this code. Regards, Jeremy Henty

17 years, 10 months

https plugin status

by Christian.Kellermann＠nefkom.net

Hi, nevermind the last post the dpid_tag _is_ syntactically correct. Why should http_query be missing though? Shouldn't it at least be the same as url? Kind regards, Christian -- You may use my gpg key for replies: pub 1024D/47F79788 2005/02/02 Christian Kellermann (C-Keen)

17 years, 10 months

Dillo-dev search results for query "plugin"