Search results for "plugin" - Dillo-dev

Connection problems on Mac OS X 10.6.7

by jcid＠dillo.org

On Fri, May 27, 2011 at 12:38:43PM -0500, reza farivar wrote: > On Fri, May 27, 2011 at 10:28 AM, Jorge Arellano Cid <jcid(a)dillo.org> wrote: > > > 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?) > > > > 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. > > > > > > 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 > > > > 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 This gets us on track! Dig... In fltk-1.3-rc6, Fl_mac.cxx, it says: <quote> /** * This public function handles all events. It wait a maximum of * 'time' secods for an event. This version returns 1 if events * other than the timeout timer were processed. * * \todo there is no socket handling in this code whatsoever */ int fl_wait( double time ) { do_queued_events( time ); return (got_events); } </quote> so it looks like when there're sockets to watch, there's a busy wait (because it sometimes work). This is for the FLTK devs to answer. As a wild shot I'd try: Fl_cocoa.mm:680 - time_to_wait = 0.0; + time_to_wait = 0.2; Or set it to always 0.1 and see what happens. -- Cheers Jorge.-

May 27, 2011

Re: dpi problem

by Rodrigo Arias

Hi, On Mon, Jun 15, 2026 at 02:33:24AM +0200, Teddi Vazquez wrote: >Hello, I'm trying to add the plugins for gopher and gemini, when i run >the "make install" the next message appears in both: > >echo 'proto.gopher=gopher/gopher.filter.dpi' >> /root/.dillo/dpidrc Don't install with root (sudo) use just "make install" as your user. >dpidc stop || true >** ERROR **: [Dpi_read_comm_keys] No such file or directory >** ERROR **: main: Can't read dpid's port number These errors are expected when there is no dpid daemon running, which is fine if you don't have dillo open. After that "make install" it should work. Otherwise let us know. Best, Rodrigo.

June 15, 2026

Re: FLTK 1.3.0 RC 1 released!

by rogerx.oss＠gmail.com

Dunno about the *other* distros, but Gentoo has several versions of FLTK available including 2.0_pre branch. And, somebody has volunteered a FLTK-1.3_rc1 ebuild on bugs.gentoo.org. Dillo is extremely important on all my platforms as I use Intel P3 CPU's. Using any other browser, and I'm just wasting my CPU cycles with unneeded html scripts -- even with noscript & no-ads plugins for Seamonkey! Maybe hook-up with the FLTK mailing list to see if they're really going to push 1.3? From what I read a week ago, they're devoting all efforts on 1.3 and deprecated 2.0 branch. 2.0 branch might get it's features ported to 1.3. Cheers! -- Roger http://rogerx.freeshell.org/

Dec. 28, 2010

Re: Hardening Dillo with unveil and pledge

by Rodrigo Arias

Hi Alex, On Sat, Jul 20, 2024 at 09:03:48PM +0200, a1ex(a)dismail.de wrote: >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. Ups, I meant $HOME, not /home :-) There is a dGethomedir() function in dlib/dlib.h to help with this, which also works with other systems. >> >+ 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. I can see clear benefits on restricting the file system access, but do you have in mind which type of attack the pledge() configuration would you help mitigate? I think allowing exec and inet is too permissive and would allow an attacker to easily spawn a remote shell as soon as a RCE bug is found. Maybe we can remove exec by spawning first the dpid daemon and then restricting the exec syscall with pledge. Currently it is only started when a request to a dpi plugin via a_Dpi_ccc(). >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. I think is a good idea more OpenBSD people review this part, as I'm not very familiar with pledge(2). However, I'm afraid having this patch only in OpenBSD may cause a negative effect, as we may start receiving bug reports that are only happening on OpenBSD with that patch and cannot be reproduced on Linux or other systems without it. Maybe you can make a hardened Dillo port, so people can still test the non-hardened port to determine if the problem comes from these changes. This could be also controlled by a dillorc option (Dillo shouldn't be able to write dillorc), so it can be disabled for testing. The latter could be applied to upstream Dillo if we allow compiling the pledge part conditionally and would benefit from the CI tests on BSD too. Best, Rodrigo.

July 21, 2024

Patch for xembed updated

by podarcis＠lavabit.com

> Please have a look at the enclosed diff 'xembed_removed_demo.diff', > that removes the *WHOLE* xembed protocol implementation and only > keeps the window creation. > > Still embedding with 'tabbed' works as before. This really makes me > wonder... Update: I just tested Claws Mail (writing this mail with it) from the Ubuntu 12.04 distribution together with the 'Dillo_Viewer' plugin (which was not so easy to get, because it is not longer in this distribution - I had to take it from another distibution, openSuse-12.2) Result: dillo with the *removed xembed support* (see previous posting) integrates perfectly (including resizing) into the Claws Mail preview window! Also does dillo with *my patch*. Just to let you know.. Cheers, podarcis

Jan. 11, 2013

hyphenation in dillo

by corvid＠lavabit.com

Sebastian wrote: > On Mon, Sep 10, corvid wrote: > > I was looking at the src for http://distrowatch.com , and the > > source page is very wide -- wider than any lines, so far as I > > could see. > > There is one line, which is very long (number 54), but the current > release breaks this line into multiple ones. Can someone provide > details about the vsource plugin? The vsource page has <style type="text/css">PRE {white-space: pre-wrap} and the css2 spec says "If 'white-space' is set to 'pre' or 'pre-wrap', any sequence of spaces (U+0020) unbroken by an element boundary is treated as a sequence of non-breaking spaces. However, for 'pre-wrap', a line breaking opportunity exists at the end of the sequence."

Nov. 7, 2012

dillo-2.2 has been released!

by corvid＠lavabit.com

Get it at http://www.dillo.org/download/dillo-2.2.tar.bz2 Some highlights of this release are: - a major overhaul of the cookies subsystem - a reimplementation of the Dillo Plugin (DPI) API - a configurable connection limit - various CSS improvements Anyone using cookies should definitely upgrade, as important security fixes were made in the process of rewriting the cookies module. Pretty much all of the changes that would be of interest to users are mentioned in the ChangeLog ( http://hg.dillo.org/dillo/file/tip/ChangeLog ) In configuration files: dillorc has new options http_max_conns and show_help, and the default for no_proxy has changed. keysrc has new options for save and for various motion commands. You can also use keysym values in the rules now. I think I have the website all updated except for the main page, and Jorge will do the freshmeat stuff.

Feb. 11, 2010

[PATCH] startup window

by thomas-forum＠orgis.org

Am Wed, 1 Apr 2009 09:47:11 +0200 schrieb Hofmann Johannes <Johannes.Hofmann(a)gmx.de>: > Hi, > attached patch adds a proper startup screen for dillo. Oh, is dillo slow enough now that it needs a splash screen distracting the user while waiting for startup? I sort of like the "instant startup" behaviour. A splash startup screen reminds you of the startup _not_ being instant. Especially opening an extra window wastes CPU cycles, even in X11, that could be used on doing the actual work... Of course I'll have to check out a current dillo2 to see how eminent the issue really is. But when we reach the startup speed of e.g. the GIMP with it's endless loading of plugins etc., one can safely declare dillo "just another bloated browser". I don't want to be offensive, just voice my concern... Alrighty then, Thomas.

April 1, 2009

Re: [PATCH v2] Unveil patch

by Diego

Hi. Sorry I can't help dillo more. I'm always very busy with my work. El vie, 2 ago 2024 a las 1:24, Rodrigo Arias (<rodarima(a)gmail.com>) escribió: > > >To-Do: > >- Add prefs parsing to plugins to get 'save_dir' (may need help here) > > I assume you could reuse the same prefs parser from Dillo, but we would > need to link the DPIs with some of the code that is now only being > linked in the browser. > > You could use dParser_parse_rc_line() from dlib/dlib.[hc] ../dlib/dlib.c:int dParser_parse_rc_line(char **line, char **name, char **value) ../dlib/dlib.h:int dParser_parse_rc_line(char **line, char **name, char **value); ./srch dParser_parse_rc_line keys.cc: st = dParser_parse_rc_line(&line, &keycomb, &command); prefsparser.cc: st = dParser_parse_rc_line(&line, &name, &value); ../dpid/dpid.c: st = dParser_parse_rc_line(&line, &service, &path); Salud! Diego

Aug. 2, 2024

keyboard shortcuts non-functioning under KDE 3.5.10

by paul＠claws-mail.org

Hi Jorge, On Thu, 4 Jun 2009 12:23:57 -0400 Jorge Arellano Cid <jcid(a)dillo.org> wrote: > Paul, please let us know what binding are you trying to make, > what is failing and your keysrc. I'm not actually trying to make any. I got on to this problem when talking to Johannes on #claws - dillo1 had 'show controls' and 'reload' in the context menu, which was always very useful in Claws Mail with the plugin, because it runs `dillo -f`, but anyway... Even the default keybindings don't work for me. I don't have a keysrc file, but I did create one, at Johannes suggestion, but this didn't have any effect either. Pressing key-combos has no effect. best regards Paul -- "Thanks to his green candle, the 'Pataphysician can lighten our darkness."

June 4, 2009

Dillo-dev search results for query "plugin"