Search results for "plugin" - Dillo-dev

Re: Option to define external link handler

by Rodrigo Arias

Hi Diego On Sat, Jul 13, 2024 at 01:36:19PM +0200, Diego wrote: >I think a good way is to reduce functionality to a minimum. Not to make a >full scripting language, but rather moderately complex hook rules that can >call external scripts or DPIs with complex functionality. This is not a scripting language, just a way to describe rules that can be transformed in quick operations at runtime. We won't be reinventing JS. >Another mistake that can be made is to replace the DPI infrastructure. I >think a cooperation between the two is better. There is no plan to remove the support for DPI plugins, just to increase the capabilities for hooking. >DPIs and authorized scripts can set temporary rules and be called by dillo >on events. >Fixed rules in a rules file call complex scripts or DPIs. That's more or less the idea. >The problem with the DPI infrastructure is that it is an unfinished >infrastructure with very little documentation. There are other structural problems, please check the related issues. https://github.com/dillo-browser/dillo/issues/65 https://github.com/dillo-browser/dillo/issues/56 Best, Rodrigo.

4 months

Re: dpid

by Jorge Arellano Cid

On Sat, 6 Dec 2003, Ferdi Franceschini wrote: > Hi Jorge, > > On Fri, Dec 05, 2003 at 09:25:20AM -0300, Jorge Arellano Cid wrote: > > > > Hi Ferdi, > > > > I've catched an API problem inside the capi/cache that may be > > the cause for the fork-hog. This note is just to keep you from > > wasting time reviewing it. I'll write to you soon. > Great. It _was_ the cause! There was a race condition hidden behind the lack of dpi-cache connection (the part we blamed) and a slightly broken API (the cloaked problem). As a matter of fact this bug had remained unnoticed maybe for years. In my patched tree (which is under test), the bug is fixed (both parts) and dillo works even better than before. > I think I have a new solution to the inf loop caused when a connection is not > accepted on a dpi socket for any reason. This new solution does not require > any code changes to the plugins. I will post more info to dillo-dev but I need > to experiment a bit first. That's good news. Cheers Jorge.-

20 years, 11 months

Re: dpid doesn't work if configured with "--program-suffix=-new"

by Kevin Koster

Detlef Vollmann wrote: > for the time being I'd like to install the current dillo version, > next to the old existing one. > So I configured with "--program-suffix=-new". > Browsing works fine, but plugins (including bm or file) can't be > started, as the binary is called "dpid-new" but dillo tries to > start "dpid". > > It probaly wouldn't work anyway as $HOME/.dillo is hardcoded > and there's no way to give a separate configuration directory > (and sharing .dillo between different version is probably not > a good idea). What about starting Dillo with: HOME=~/dillo-new dillo Then there's a script in the source code root directory called install-dpi-local. Running (from the Dillo source code dir): mkdir ~/dillo-new HOME=~/dillo-new ./install-dpi-local should install dpid and plug-ins to the ~/dillo-new/.dillo/dpi directory where dillo will find them when started in its own home. Alternatively you could manually make symlinks (if supported by your file system) in ~/dillo-new/.dillo/dpi to the "-new" binaries at their installed locations.

3 months, 2 weeks

Re: [Dillo-dev] Cookie locks?

by Lars Clausen

On Fri, 25 Apr 2003, Jorge Arellano Cid wrote: > > > Lars, > >> >> I understand unrestricted access to cookie jars can be bad for your >> health, but it's annoying that you can't have two Dillos using cookies >> at the same time. I usually have a Dillo running permanently, and when >> I get a URL in my mail, I can click on it to open another Dillo >> (quickly!) -- but that Dillo can't use cookies, which is frequently >> (e.g. in bugzilla) necessary. Could we do a write-lock on it? > > Actually, we plan (with Jörgen) to make of cookies a dpi server. Now *that* would be a good use of the dpi server. Shouldn't be horribly hard, and then the plugin can have a nice admin interface if it wants to. -Lars is still miffed about the bookmarks menu. -- Lars Clausen (http://shasta.cs.uiuc.edu/~lrclause)| Hårdgrim of Numenor "I do not agree with a word that you say, but I |---------------------------- will defend to the death your right to say it." | Where are we going, and --Evelyn Beatrice Hall paraphrasing Voltaire | what's with the handbasket?

21 years, 6 months

Re: Hardening Dillo with unveil and pledge

by a1ex＠dismail.de

Hi Rodrigo, On Sat, 20 Jul 2024 16:34:47 +0200 Rodrigo Arias <rodarima(a)gmail.com> wrote: > >+ if (unveil("/home", "rwc") == -1) { > > We may want to constraint this a bit further, so a malicious actor > cannot read anything from /home/.config. Maybe only /home/.dillo and > the downloads directory would be suitable? Absolutely, that was my initial intention, but just wanted to keep the example patch as simple as possible. There are a number of things in $HOME which we probably don't want the browser having access to. > >+ if (pledge("stdio rpath wpath cpath inet unix dns tty proc > >prot_exec", > > Does this work with plugins, when the dpid daemon is not running?, as > I believe it has to fork and exec the dpid program. I started with a mindset of "whats the bare minimum of permissions we can get away with". But its clear that we would need "exec" as well for full functionality. At some point I may try to submit an improved patch to the OpenBSD ports maintainers. Unfortunately that won't do much for users of Linux and other systems. -Alex

3 months, 3 weeks

Connection problems on Mac OS X 10.6.7

by jcid＠dillo.org

On Thu, May 26, 2011 at 03:42:04PM -0500, reza farivar wrote: > On Thu, May 26, 2011 at 3:18 PM, Johannes Hofmann > > > [...] > > Did you take special care to compile fltk-1.3 with X11 backend? > > If not, you might run the dillo as native Cocoa application. > > In that case you were more successful then me. > > For me dillo with Cocoa-fltk starts, but does not load any remote > > pages. There seem to be severe issues with the way fltk handles events > > in the Cocoa case. > > > > Hmm, maybe I should try recompiling fltk with X11 backend...But my current > native version is so close to working with no problems... Yes, it's amazing how close it is from working native. Are plugins working OK? (e.g. can you browse the filesystem?) Do you know how to use gdb? It would be great to know in what functions the busy wait happens. It could be a timeout or anything. For this: gdb ./dillo <when locked on high CPU usage, hit Ctrl-c> bt This can hint us on what may be happening. -- Cheers Jorge.-

13 years, 5 months

--xid option

by jcid＠dillo.org

On Mon, May 18, 2009 at 11:14:14PM +0200, Johannes Hofmann wrote: > On Mon, May 18, 2009 at 01:48:43PM -0400, Jorge Arellano Cid wrote: > > On Mon, May 18, 2009 at 01:18:11AM +0200, Johannes Hofmann wrote: > > > Hi, > > > > > > attached patch tries to implement the missing --xid option that is > > > used to embed dillo into the claws mailer. > > > The right way to do this would probabely be to implement the > > > complete XEMBED protocol which is also mentioned in > > > doc/fltk-problems.doc. > > > However a simple XReparentWindow() seems to work more or less here. > > > Please test. > > > > It seems like you forgot to commit xembed.{hh,cc} to the repo. > > e.g. hg add xembed.hh xembed.cc > > Oh yes. Should be fixed now. > Btw. I managed to install the claws mail client including the dillo > plugin and it seems to work fine now with dillo2. That's why I just > committed the xembed stuff. This is very good. I'll have to dig for the sylpheed contact to let them know. Does anybody here know the email? -- Cheers Jorge.-

15 years, 5 months

[Dillo-dev]Re: dillo: umask(0) in dpid/main.c?

by Jorge Arellano Cid

On Sun, Nov 28, 2004 at 01:03:23PM +0100, Richard Zidlicky wrote: > Hi, Hi. > I stumbled upon this as I noticed that bookmarks and saved files > are world writable. Is there still a good reason to set umask > to 0 for all plugins? Good question! Basically the umask(0) call is there because the "Linux Programming Second Edition Unleashed" recommends so as a standard for daemons ;). Now, looking into it, it makes much more sense to use 077 as a mask for dpis (i.e. only allowing the owner). > > Another detail I noticed while checking file creation > is this: > --- dillo-0.8.3/src/cookies.c.rz 2004-11-28 12:39:33.000000000 +0100 > +++ dillo-0.8.3/src/cookies.c 2004-11-28 12:40:22.000000000 +0100 > @@ -100,7 +100,7 @@ > > if ((F_in = fopen(filename, "r+")) == NULL) { > /* Create the file */ > - fd = open(filename, O_WRONLY | O_CREAT | O_TRUNC, S_IRUSR | S_IWUSR); > + fd = open(filename, O_WRONLY | O_CREAT | O_TRUNC, S_IRUSR | S_IWUSR, 0777); > if (fd != -1) { > if (init_str) > write(fd, init_str, strlen(init_str)); Well, with the proper mask set to 0077 this would not be required. If the need to add explicit permissions arise, it'd be 0077 too. Comments are welcome. -- Cheers Jorge.-

19 years, 11 months

--xid option

by Johannes.Hofmann＠gmx.de

On Wed, May 27, 2009 at 05:25:15PM -0400, Jorge Arellano Cid wrote: > On Tue, May 26, 2009 at 08:17:53PM +0200, Johannes Hofmann wrote: > > On Tue, May 19, 2009 at 08:24:14PM +0200, Johannes Hofmann wrote: > > > On Tue, May 19, 2009 at 01:34:56PM -0400, Jorge Arellano Cid wrote: > > > > On Mon, May 18, 2009 at 11:14:14PM +0200, Johannes Hofmann wrote: > > > > > On Mon, May 18, 2009 at 01:48:43PM -0400, Jorge Arellano Cid wrote: > > > > > > On Mon, May 18, 2009 at 01:18:11AM +0200, Johannes Hofmann wrote: > > > > > > > Hi, > > > > > > > > > > > > > > attached patch tries to implement the missing --xid option that is > > > > > > > used to embed dillo into the claws mailer. > > > > > > > The right way to do this would probabely be to implement the > > > > > > > complete XEMBED protocol which is also mentioned in > > > > > > > doc/fltk-problems.doc. > > > > > > > However a simple XReparentWindow() seems to work more or less here. > > > > > > > Please test. > > > > > > > > > > > > It seems like you forgot to commit xembed.{hh,cc} to the repo. > > > > > > e.g. hg add xembed.hh xembed.cc > > > > > > > > > > Oh yes. Should be fixed now. > > > > > Btw. I managed to install the claws mail client including the dillo > > > > > plugin and it seems to work fine now with dillo2. That's why I just > > > > > committed the xembed stuff. > > > > > > > > This is very good. > > > > > > > > I'll have to dig for the sylpheed contact to let them know. > > > > Does anybody here know the email? > > > > > > I already contacted them on irc (#claws on freenode). > > > It would be good if this get's some testing as there seems to be > > > some interaction with the WM in use. I now tested it successful > > > on dwm, twm, and fvwm. > > > Also there are probabely more elegant ways to do it, but > > > for now I think it's better than nothing. > > > > More testing showed that the current implementation has severe > > problems. > > The thing is that the window manager that I use (dwm) is one of the > > few non-reparenting WMs. Most others reparent new windows and that > > can create races with the reparentin we do. > > There also seems to be a problem with keyboard events in that case. > > Is there anyone on the list with in-depth X11 knowledge who could > > help with the xembed stuff? > > Not me. > > I've seen new patches in the repo so I assume this is more > or less being improved. Please let me know how it goes. I figured out some more how this is supposed to work with xtrace and the testsocket example from gtk2. For me it now works reliably with claws under kde3. An open issue is that claws eats up all key presses it has defined as hotkeys (including 'p' and 'u'), but the same thing happens when I embed the example plugin from gtk instead of dillo. > > AFAIS the current repo is almost dillo-2.1. I'd freeze here > and only accept bug fixes and polish from now. Opinions? Ok for me. Cheers, Johannes

15 years, 5 months

Re: [Dillo-dev] Bug 433

by Andreas Schweitzer

Just to clarify a bit the stuff that is now in the arcives ;-) On Fri, Mar 21, 2003 at 06:51:47PM -0800, Geek wrote: > Thank you - the problem is solved. I completely removed using "make uninstall" > then using my trusty Midnight Commander, hunted down all the remnants and > directories and removed them. I re-downloaded Dillo, installed from scratch and > it seems fine now. > > I had tried reinstalling one already to no avail, but I had not removed /.dillo > before, in order to keep my bookmarks, cookies and rc file. Now careful ! I meant to remove ONLY a possible bm_srv12 sitting in there. > So I guess the lesson here is - when upgrading Dillo, wipe *everything* old > Dillo out completely, first. No, not wipe everything. Just make sure, that any new executable gets installed in the BEGINNING of $PATH. (this is really not that surprising :-) ...) And that you don't have any old executables in ~/.dillo/ dillo searches (at least the bookmarkserver for now) first in ~/.dillo/ and then in $PATH. This can be handy for developing plugins but can be confusing, too. Cheers, Andreas -- **************************** NEW ADDRESS ****************************** Hamburger Sternwarte Universitaet Hamburg Gojenbergsweg 112 Tel. ++49 40 42891 4016 D-21029 Hamburg, Germany Fax. ++49 40 42891 4198

21 years, 7 months

Dillo-dev search results for query "plugin"