Search results for "plugin" - Dillo-dev

keyboard shortcuts non-functioning under KDE 3.5.10

by paul＠claws-mail.org

Hi, I've got recent code from mercurial, June 1st. No keyboard shortcuts are working for me using KDE 3.5.10. I was speaking to Johannes Hofmann about this problem, he asked me what my locale was (it's en-GB.UTF-8) and also asked me to report the problem here. Do you need more information from me? Whilst I'm here I would like to say thanks to Johannes for sorting out the --xid option, Claws Mail now has a dillo plugin again! with regards Paul -- "Thanks to his green candle, the 'Pataphysician can lighten our darkness."

16 years, 7 months

Cookies performance

by Johannes.Hofmann＠gmx.de

On Tue, Jan 12, 2010 at 05:42:03PM +0000, corvid wrote: > Johannes wrote: > > I noticed that since the recent DPI update pages which use > > cookies load slower (e.g. fltk.org) > > Do others also see that? It could also be OS specific. > > I thought it seemed weirdly slow _sometimes_. > I'll have to throw some gprof at it and hope for something > simple and embarrassing. > > (I wonder whether it would be easy to do valgrind with dpid and the > plugins.) I did some truss on the cookies dpi and found that it is reading ~/.dillo/dpid_comm_keys quite often. Maybe that is related.

16 years

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

by Detlef Vollmann

Hello, 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). But it would be cleaner not to support "--program-suffix". Detlef

1 year, 6 months

Ignore a command line option (for Mac OS bundles)

by obeythepenguin＠gmail.com

On Sun, 05 Jun 2011 15:54:56 -0400, corvid <corvid(a)lavabit.com> wrote: > reza wrote: >> 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? > > openssl? libssl and libcrypto (and Dillo needs to be compiled with --enable-ssl) ~Benjamin

14 years, 7 months

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.-

14 years, 8 months

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/

15 years, 1 month

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.

1 year, 6 months

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

13 years

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."

13 years, 2 months

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.

15 years, 11 months

Dillo-dev search results for query "plugin"