Search results for "plugin" - Dillo-dev

Connection problems on Mac OS X 10.6.7

by rf.opensource＠gmail.com

On Fri, May 27, 2011 at 1:08 PM, Jorge Arellano Cid <jcid(a)dillo.org> wrote: > 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. > Interesting find. Indeed if you look at FL_wait in FL_x.cxx, they issue a select system call that can identify socket events, while the mac version seems to only be a timeout based mechanism. I just emailed Manolo Gouy from FLTK (he seems in charge of the Mac section), and I'll let you know. BTW, FL_mac.cxx seems to be deprecated, and their most recent developments is in FL_cocoa.mm. > > 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.- > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev >

13 years, 10 months

Unused?: the url tag in the DPI start_send_page command

by jcid＠dillo.org

On Sun, Dec 09, 2012 at 04:14:01PM +0000, Jeremy Henty wrote: > > Everything that sends the start_send_page DPI command also sends a url > attribute with it, but I think this attribute is always ignored. > > Dillo processes the command in capi.c but it does nothing with it > because the Cache is already set up to receive the following raw data. > So it doesn't look at any attributes. The only other thing that > receives a start_send_page is the view source DPI and it doesn't look > at any of the attributes either (it extracts a url from the previous > tag in the stream, which it then sends back to Dillo to be ignored). View source shows the URL as page title. > So what is this attribute for? Future use? Or is it something that > just never got used? In general terms, there were ideas that went unused, and some extensions that were necessary to solve an unforeseen situation; as dpi authentication to avoid a local socket spoofing attack. The dpi framework is the same for several quite different dpi programs (aka plugins). The interface was kept more or less uniform, and each dpi chooses whether to use the info or not. -- Cheers Jorge.-

12 years, 3 months

Feature Request

by Johannes.Hofmann＠gmx.de

On Sat, Nov 08, 2008 at 04:19:19PM -0500, me at swva wrote: > On Sat, 8 Nov 2008, Johannes Hofmann wrote: > >> Hi, >> >> On Sat, Nov 08, 2008 at 03:40:08PM -0500, me at swva wrote: >>> >>> Dillo, alone of all browsers I know, cannot handle "www.site.xyz.com," >>> by simply converting it on the fly to "http://www.site.xyz.com" >> >> It works fine for me. >> Do you have an example where it doesn't work for you? >> What version of dillo are you using? > > Iirc, it has *always* done this to me, on all machines, for years out of > mind, on all URLs. > > Just to check, I did this as root : > > [root@Hbsk2 btth]# rpm -q dillo > dillo-0.8.6-7.fc9.i386 > [root@Hbsk2 btth]# yum update dillo > Loaded plugins: refresh-packagekit > updates-newkey | 2.3 kB 00:00 > updates | 2.6 kB 00:00 > fedora | 2.4 kB 00:00 > Setting up Update Process > No Packages marked for Update > [root@Hbsk2 btth]# dillo-0.8.6 is no longer supported and you should consider to upgrade to dillo-2.0. But nevertheless for me it also works with dillo-0.8.6. If you enter "google.com" in the location bar and hit return it doesn't go to google?

16 years, 4 months

[PATCH] startup window

by jcid＠dillo.org

On Wed, Apr 01, 2009 at 08:11:32PM +0200, Hofmann Johannes wrote: > On Wed, Apr 01, 2009 at 04:49:44PM +0000, corvid wrote: > > Thomas wrote: > > > 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... > > > > I agree with Thomas here. > > > > me too - check the date :) Good one! I should have suggested using Gecko... :-) -- Cheers Jorge.-

16 years

Cookies performance

by Johannes.Hofmann＠gmx.de

On Tue, Jan 12, 2010 at 07:06:12PM +0000, corvid wrote: > Johannes wrote: > > 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. > > It looks like it checks it through a_Dpip_check_auth() when it > gets or sets a msg. As for whether it needs to, I don't know. > > I tried a little gprof, but a modest amount of browsing and > accepting cookies wasn't enough for the dpi to use up enough > time for gprof to generate stats. Yah, I don't think it's CPU bound. There must be something else. I will have a look at it.

15 years, 2 months

Re: dns over tls or dns over https

by Rodrigo Arias

Hi, On Sat, Jun 01, 2024 at 01:27:07PM -0600, pastebin(a)gmx.com wrote: >Hi > >could someone give me an idea about dillo using 'dns over tls' or 'dns >over https'? or using dnssec? The mobilized fork has added support for it, as it is provided by libcurl (which they have switched to): > 20240522: New tarball. To enable DNS-over-HTTPS (DoH), you can now set > the preference dns_over_https_url. https://www.toomanyatoms.com/software/mobilized_dillo.html My recommendation is to setup a local resolver on your machine, so all name resolution is handled by it, not just Dillo. Then you can use whatever mechanism you want (DoH, DoT, DNSSEC...). This would be especially useful if you download a file with Dillo, as it would launch an external wget process. Or if you use any plugin that performs network operations on its own. Here are some docs (even if you don't use Arch): https://wiki.archlinux.org/title/DNS-over-HTTPS https://wiki.archlinux.org/title/DNSSEC I didn't check on my own how well that works, but I would rather keep it out of Dillo if posible. >what about dillo using mbed-tls vs openssl? >the configuration only shows a --disable-mbedtls The DNS resolution is done prior to interacting with any TLS library. There is also a --disable-openssl switch to search for mbed TLS only, see ./configure --help. Best, Rodrigo.

10 months

Re: Dillo not rendering HTML with comments before <!DOCTYPE>

by Kevin Koster

On Thu, 25 Apr 2024 21:36:04 +0200 Rodrigo Arias <rodarima(a)gmail.com> wrote: > We can improve the content detection to handle both HTML and > XML-style comments, but I prefer to defer it after the 3.1.0 release. > Websites shouldn't rely on the browser to guess the content type, it > should be stated in the HTTP header or the meta tag. So I don't > consider this a priority that should block the release for longer. Yes, that's reasonable. > If you want to work on it, feel free to do so :-) I might have a go at it then. > >I've built Dillo from that branch and pages on www.lemis.com now > >render correctly, thanks! If I save the homepage as lemis.xhtml it > >still shows as plain text when loaded with file://, though it is > >rendered if the comments before <!DOCTYPE> are removed or if the > >original file is saved as lemis.html. Not much of an issue, but it > >could cause confusion for someone. > > I pushed another patch that should fix this issue. It is caused > primarily by the ".xhtml" extension not being recognized by the file > plugin, which then tries to detect the doctype and fails in the same > way, falling back to text/plain. All working well now, thanks again.

11 months, 1 week

current plans

by itsme_410＠yahoo.com

--- On Thu, 4/19/12, corvid at lavabit.com <corvid at lavabit.com> wrote: > From: corvid at lavabit.com <corvid at lavabit.com> > Subject: Re: [Dillo-dev] current plans > To: "Globe Trotter" <itsme_410 at yahoo.com> > Date: Thursday, April 19, 2012, 12:11 AM > > the current plans page has a > number of items which are said to be at least > > in prototype: is there a way to access these > prototypes? assuming that > > they are still part of the plans to move them to > dillo? > > > > any time for a new major release yet? > > My understanding for prototype items are: > > Throttle rendering: Jorge must've done something at some > point, but I > don't know what. > Graphical plugins framework: Maybe this refers to something > from dpi > ancient history. > Image backgrounds: I think I remember Jorge mentioning > trying something > quickly a year or two ago, but I never saw the code or > anything. > Javascript: In addition to the link, I can say that I > think...Jeremy? was > interested in getting something working, but may have been > too busy to do > so. > > As for a release, I for one have been on vacation of > late... > > Thanks very much! I would like to request that you consider releasing more often so that more users may continue to be interested in dillo.....

12 years, 11 months

Dillo + Partial Javascript Support

by matopoftheworld＠live.co.uk

Hi I have a cnm minibook which is part of a little Linux laptop family of mini laptops that use low powered Mipsel processors running Lnux. An unofficial site is here: http://linuxlaptopforum.ark2webdesign.co.uk/index.php One of the users has come up with a Linux distro called 3MX which uses IceWeseal but has also Dillo. The reason for this is because IceWeasel is a bit slow due to the low spec processor. Dillo runs far better than IceWeasel and would be an ideal replacement if it had the functionality of Javascript. Rather than somebody trying to get full Javascript suport for Dillo, I was thinking along the lines of partial Javascript support. The bare minimum would be to access websites that use Javascript to allow logins to forums etc. If any more functionality could be added so that for example social network sites like facebook or bebo then that would be great.On a personal note, I don't mind the lack of CSS when displaying pages on Dillo due to the small screen size of the minibook so any Javascript concerning that is not necessary. It is theoritcally possible as I use the noscript plugin on Firefox on my home PC which blocks javascript from certain 3rd party sites from running. I was wondering if anybody had any thoughts if the above is achievable and if so what would be the best Javascript engine to use with Dillo to achive this? Thanks in advance alsaf. _________________________________________________________________ Share your photos with Windows Live Photos ? Free. http://clk.atdmt.com/UKM/go/134665338/direct/01/

15 years, 11 months

patch: close windows from menubar

by jcid＠dillo.org

On Wed, Oct 08, 2008 at 05:04:29PM +0200, Joerg Sonnenberger wrote: > On Wed, Oct 08, 2008 at 03:32:42PM +0100, Jeremy Henty wrote: > > On Wed, Oct 08, 2008 at 01:09:48PM +0200, Joerg Sonnenberger wrote: > > > > > ... why would you want dillo1 and dillo2 at the same time. > > > > I don't know. But when you start saying "No-one could *possibly* want > > to do that, so let's stop supporting it" then you are riding for a > > fall. Why make ourselves hostages to fortune? Why not make *sure* we > > avoid the problem rather than gambling that we've second-guessed our > > entire user base? Murphy's law applies, so play it safe unless > > there's a compelling reason not to. > > You are adding the overhead of changing user behavior though. The claws > backend might be a good reason, frankly it is the only one I see so far. OK, just checked Debian and Ubuntu and both have the dillo viewer plugin for sylpheed with a dependency on the plain "dillo" package. Looking around in the FLTK docs, there's this function: CreatedWindow::set_xid() It looks promising. Unfortunately I haven't found a full code example to make it work. If somebody knows how to use it, it'd be simple to make a "drop in" replacement for dillo1, and avoid the problems discussed in this thread. BTW, I'm inclined to using dillorc/dillo/2.0 in the release. -- Cheers Jorge.-

16 years, 5 months

Dillo-dev search results for query "plugin"