Search results for "plugin" - Dillo-dev

Future of dillo2

by 4winter＠informatik.uni-hamburg.de

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Diego wrote: >> With my recent patch (dpid-cleanup-and-DPIPATH.dillo2) one can use the >> attached script to run dillo in-tree which is nice if you just want to >> try it out but should also be useful for development purposes (easily >> manage different branches without the need to install them somewhere). > > The patch seems good to me, but i have not look it very deep or test it. Some more testing turned out that it's not enough to add another path to search for dpis. With no dpidrc fill_services_list fails: [dpid]: dpid.c:467: fill_services_list: Fatal error [dpid]: - Can't find the directory for dpis. This seems very non-plugin-like to me. What's the point in being able to have dpis in ~/.dillo/... but to actually use them you have to add them to your ~/.dillo/dpidrc. I mean it's okay up to this point, but consider you have one custom dpi in ~/.dillo/... : * in order to use it you have to create a custom dpidrc too * judging by a quick look at dpid.c/register_service I'd say that you have to copy the content of the system wide dpidrc file too since your custom one takes preference over the system wide one * now there's a package installed containing one more dpi. It might be doable to update the system wide dpidrc via a post-install script within the package (though thats error prone, you have to remove your entries on package removal etc.) * but what about the custom dpircs? You cannot have the post-install script modify those as well (well, you could, but naaa) > The idea is that each dpi can have its own files in its directory > (preferences, data, cache files ... ). I could go with preferences and data files, but caching feels like a no-no to me since on most installations the user is unable to write into those directories. Justus - -- gpg key fingerprint: C82D 382A AB38 1A54 5290 19D6 A0F9 B035 686C 6996 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIKgZ9oPmwNWhsaZYRAjL+AJ9SjhWBUNh5WcO51GkJLaqtDyjFEwCeMQkz jkTcvl8xIbP3EedZP8T72fc= =xAX5 -----END PGP SIGNATURE-----

16 years, 6 months

web bug save?

by Johannes.Hofmann＠gmx.de

On Fri, Dec 25, 2009 at 05:46:22PM +0000, corvid wrote: > bb wrote: > > *On http://www.dillo.org/ I found the item News and a remark: > > > > 03-Jul-2009 Dillo-2.1.1 has been released to provide a security fix for > > malicious images. I am not shure what is meant with **malicious images? > > Are this so called Web bugs? If yes - how is the blocking done? > > Here's the advisory about the image size problem: > http://www.ocert.org/advisories/ocert-2009-008.html > > > I think there are some strategies possible to prevent a browser from a > > Web Bug attack: > > > > 1. Dont allow to load gifs or pngs from another URL as the actual page > > comes from. (I think to remember that firefox **originally **had such an > > option - not available in the actual version.) > > Here's the beginning of a thread and a patch experimenting with this: > http://lists.auriga.wearlab.de/pipermail/dillo-dev/2009-September/006844.ht… > (the "same host" option was found to be useless, but I'm still interested in > "same domain") > > > 2. I think one might prepare HTML/CSS not to load such gifs or pngs > > smaller than say about 5x5. Do you think such a measure is feasible in > > Dillo and could that really stop Web Bugs? But I think that there should > > not be a problem to make Web Bugs larger than 1x1pixel as long as they > > are transparent - may be I am wrong, I am just a simple minded user, not > > a web professional. So such a limit might be useless? > > Here's a post and patch experimenting with rejecting images with a dimension > of 0: > http://lists.auriga.wearlab.de/pipermail/dillo-dev/2009-December/007101.html > > > Are there other ideas? I am highly interested in that Web Bug problem. > > I'm glad to hear this, since user interest may encourage things to happen... > Absolutely. We really need to address this. Maybe we can do some more research again about what other browsers or plugins do about this. Cheers, Johannes

14 years, 10 months

SSL in the browser

by james.from.wellington＠gmail.com

I've got gmail going, using the ~/.dillo/certs certificate store. It took a bit of poking around, so I'm attaching my notes to myself in case they're useful for someone else. On 10/23/14, Johannes Hofmann <johannes.hofmann at gmx.de> wrote: > On Tue, Oct 21, 2014 at 04:42:24PM +0000, eocene wrote: >> Jorge wrote: >> > Oh, as our mailsearch doesn't work anymore, is there >> > and URL to the original thread (Gmane style) or something? >> > >> > I'd like to remember what the main point of having SSL inside >> > the browser were. I'm getting old. ;) >> >> Looking briefly, I couldn't find relevant discussion. Possibly it >> was off list. My recollection is that, at the time, it had to do with >> seeing how SSL was becoming more and more central to browsing with >> things like 'HTTPS Everywhere' and 'HTTP Strict Transport Security' >> coming along and the issue of privacy gaining increasing public >> awareness. >> >> As for this effort now, I started just by wondering what it would >> look like if I integrated Benjamin's code and took out the windows >> stuff. It was working pretty well very quickly. And now I like how >> much more respectful of servers and resources Dillo can be when >> HTTPS is integrated with the http_max_conns queuing and >> http_persistent_conns. I think Johannes mentioned something about >> Dillo and Tor not working together so well with HTTPS in a dpi, >> but I don't know the details there. > > There is a potential loophole if you start dillo in a torified > environment and dpid is running outside. Then https connections go > via the non-torified https plugin. It's a small detail, but it > happened to me. > I'm mostly interested in getting SSL support from unmaintained > experimental state to properly supported and maintained option. > > Cheers, > Johannes > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev at dillo.org > http://lists.dillo.org/cgi-bin/mailman/listinfo/dillo-dev >

10 years

Re: Does :hover work in 3.1.1?

by Steinar Bang

>>>>> Rodrigo Arias <rodarima(a)gmail.com>: > You may want to check: > https://dillo-browser.github.io/dillo.org.html > And: > https://dillo-browser.github.io/release/3.1.0/ Right! I knew that actually, from the mastodon post that brought dillo back into my attention. But when looking for stuff I am lazy and I google rather than remembering, and google still throw up the old pages. I'll link to the updated dillo doc from the oldalbum README when I release the non-javascript version. That should help the teensiest bit, at least (also it's a place I can click to to get there). >> If :hover doesn't work I will have to do it a different way: maybe with >> a separate settings page containing a form...? > I recommend you just don't use a drop down, just an static navigation > menu which would work fine with CSS disabled. Yup, the simplest way would be to have just two links in the <nav> one for each locale/language. But that would be too much clutter, I think...? > You could also use a <select> input with a form but it looks more > complicated. Yes, it is. But it's the road I've started to travel. :-) (remains to see if I will travel it to the end or cut my losses and do something simpler...:-) ) I have some copy-pastable code. I did the authservice login and basic self-service pages non-javascript (authservice started as a forms based login plugin for nginx, using apache shiro), and I have stuff I can copy paste from there: https://github.com/steinarb/authservice I don't like JSP or JSF (feels complicated and cluttered) so I did a simple DIY templating with jersey and jsoup (I write HTML pages and read them into jersey resources with jsoup and replace elment content and fill forms). I was looking for sort of the same feel I had when using CGI.pm back in the day: the state is contained in the form data and used to populate the form in the returned HTML, and jsoup gave me that. The use of jersey is because JAX-RS gives a convenient API to tailor responses (HTTP headers and stuff).

3 months, 2 weeks

[Dillo-dev]RPM question, and how close is 0.8.0?

by Kelson Vibber

At 08:21 AM 2/3/2004, Jorge Arellano Cid wrote: > I'll start working on it after the 0.8.0 release. Any idea how soon that's coming? I've started making the necessary changes for the RPM spec based on the current CVS version. With luck I'll be able to start building as soon as the tarball is ready. I've posted some test RPMs at http://www.hyperborea.org/software/dillo/pre.html if anyone's interested. Question: I noticed that several of the included DPIs (https, ftp, download) require wget. However, the main browser does not require wget. That leads to several choices as far as RPM dependencies go: 1. Include all DPIs in the dillo package. Don't require wget. 2. Include all DPIs in the dillo package. Do require wget. 3. Separate the FTP, HTTPS, and download DPIs into a separate package (something like "dillo-protocols") and set that package to require wget. Advantages: #1: Simple installation, most linux distros probably already include wget #2: Simple installation, lets you know about wget if you haven't installed it already. #3: If you don't want wget, you're not forced to install it. If you want the plugin, you're told wget is needed. Problems: #1: If you don't have wget, installing won't tell you that you need it. #2: If you don't want to use those DPIs and you don't want wget, you need to install it anyway. #3: Installing is more complicated, because you have to download and upgrade two RPMs. I don't think #1 is really an option, because it means people can install dillo via RPM and not everything will work. I'm inclined to choose #2 over #3, just because of the simplicity. If someone just wants to install Dillo, they already have to look through a list of about 10 different RPMs for the right system, and sometimes people miss the one they need. I occasionally get requests to add an RPM for a system that's already on the list. On the other hand, some people might consider wget to be unnecessary if they're not going to be using those DPIs. Anyway, has anyone got any thoughts on this issue? Kelson Vibber www.hyperborea.org

20 years, 9 months

Various minor patches

by jcid＠dillo.org

On Wed, Jan 30, 2008 at 10:51:19AM -0300, Jorge Arellano Cid wrote: > On Sun, Jan 27, 2008 at 05:10:19PM +0100, Christian Kellermann wrote: > > * Johannes Hofmann <Johannes.Hofmann(a)gmx.de> [080125 20:21]: > > > On Mon, Jan 21, 2008 at 04:03:47PM +0100, Christian Kellermann wrote: > > > > > On Sun, Jan 13, 2008 at 05:07:04PM +0100, Thomas-Martin Seck wrote: > > > > > > 1) detect_libiconv.diff > > > > > > > > > > > > src/decode.c uses iconv_open but - at least on FreeBSD - libiconv > > > > > > is not in the default linker path, making the build abort. Add > > > > > > a simple test to configure.in to check for libiconv's presence > > > > > > and usability and a substitution for ICONV_LIBS to src/Makefile.am. > > > > > > > > > > Very nice! The same problem exists on DragonFly... > > > > > > > > This breaks configure for me (OpenBSD/386 -stable). seems the test does not use the LDFLAGS=-L/usr/local/lib... My knowledge (and motivation) to fiddle with this autoconf hell is limited, so I'd kindly hand the ball over to someone else. > > > > > > What exactly is breaking? Can you provide config.log? > > > > > > Here on DragonFly linking was failing with unresolved symbols, > > > but it turned out that the problem was caused by a libiconv > > > package that was no longer needed. The iconv stuff is now handled > > > in libc on DragonFly... > > > > I have attached the log. Seems like the function signature differs > > on OpenBSD a bit. The testcase modified as such that it includes > > <iconv.h> and calling iconv_open("",""); works for me when doint > > it manually. > > > > I don't know what happens here... > > > > Kind regards, > > Does it fail with current CVS? Sorry, from the log it's clear it doesn't. This page seems to have good info: http://synflood.at/blog/index.php?/plugin/tag/bsd (my understanding of German is barely for survival. ;). -- Cheers Jorge.-

16 years, 9 months

dillo 2.1

by Johannes.Hofmann＠gmx.de

Hi Tomas, On Mon, Jun 22, 2009 at 05:12:07PM +0300, Tomas R wrote: > Been testing dillo 2.1 for some time and would like to share my > experience. > > It's really great to see some basic css support (appearance of most if > not all websites has improved alot), properly resized images, > redirection and basic authentication working now :) > > Anyway, even dillo improved alot recently there still seems to be some > issues. Here are some I've noticed after testing this release for few > days: > Rendering > 1) ubuntu.lt > Not sure if it's dillo fault or website's malformed stylesheet, but > with default dillo settings some of the lithuanian characters are not > displayed. This can be fixed by just adding "* {font-family: > serif !important}" to the style.css. Here is a pic with some of the > places where letters are missing marked in red: > http://img4.imageshack.us/img4/2227/ubuntult.png I guess the problem is that the font simply does not contain those glyphs. There are some rules how this case should be handled, but dillo does not implement them currently. > 2) gmail > It's nice that login works now, but with default dillo settings the > size of most of the text is 1px. This can be partially fixed by adding > font_min_size to dillorc, but it's obviously a dillo bug as this > doesn't happen with links-hacked. I don't have a gmail account, so I can't reproduce it, but there seems to be a general bug in the CSS code that makes fonts smaller than in other browsers. > 3) google > What's with the textarea in the top left corner of the page? And just > for information: signing out doesn't work because it requires basic > javascript support (works with links-hacked). That textarea is in the google page. It's just hidden due to a "display: none" CSS directive which is not supported yet by dillo. Actually I'd like to know the reason why it is there before hiding it. > 4) Black on black, white on white... > http://www.nma-fallout.com/forum/viewtopic.php?t=42776&start=2660&sid=a5712… > For some reason black font color is used here and we get black text on > black background in some posts (doesn't happen with links-hacked). Oh. This is just horrible HTML / CSS, it's full of bugs! The reason for black on black is: <body bgcolor="#000000" text="#C0C0C0" link="#33CC00" vlink="#33CC00" /> I.e. body is immediately closed. But there is tons of other bugs on this page. > http://www.acetoneteam.org/ > Background color is not set here and if we have "body > {background-color: white}" rule in our style.css file, we get white > text on white background. dillo does not handle color definitions of the form rgb(255,255,255) yet. I guess we can fix that. > 5) http://ubuntuforums.org/showthread.php?p=6592005 > What's with the PINK blocks? If that's more of a "feature" then a bug, > can the color be changed by using some css rule? I can't find pink blocks on that page. Where exactly do you see them? Maybe post a screenshot. > 6) http://www.binaryworld.skynet.lt/DUK.html > If we use one link with fragment identifier in the page, all the others > are marked as visited too. Not sure how this should be handled correctly. Someone will have to check the specs. > 7) Authentication > Basic authentication does work now, but at first the server displays a > message saying "wrong credentials or browser doesn't > understand how to supply the credentials" and only then a window > pops up asking for the credentials... > > UI > 1) Positioning the tab close button on the top RIGHT corner of the > browser isn't a good thing because: > a) The distance between the most commonly used buttons and the tab > close button is pretty big (especially when widescreen monitors are > pretty common nowadays); > b) It only allows closing the active tab; > I think it would be much better if all tabs had close buttons or at > least the button was placed near the last tab. Agreed. Patch welcome :) > 2) Trivial but... because the setting to enable/disable image loading > now is in the wrench menu it is two clicks away instead of one as it > used to be in dillo 2.0. Maybe css settings could be left where they are > now, but the setting for enabling/disabling images could be moved where > it was in dillo 2.0? > 3) UPPERCASE letters should be used in the File menu to define keyboard > shortcuts, because now L looks like I (Open url... ctrl+l) > 4) Don't you think "Are you sure you want to close the browser?" > message is pretty annoying? Which one exactly? When exiting dillo with multiple tabs/windows open? I don't think dillo asks a lot for confirmation, but I normally use multiple Ctrl-q's to close all tabs and windows and quit. > > Other: > It seems whoever designed the new website theme has no idea what > READABILITY means... It looks like someone just used some stupid online > color picker, which just picks some similar colors to the one user > chooses. The old website looked MUCH MUCH better. Imho, it's a > regression... Hm I like the new design, but I agree that readability might be a problem. Let's see what other say. > > PS: how to install dillo 2.1 claws-mail plugin? Just install claws and the dillo plugin from source or packages depending on your distribution. Then make sure that dillo-2.1 is the dillo binary in your PATH. Cheers, Johannes

15 years, 4 months

dillo-2.1.tar.bz2

by jcid＠dillo.org

Hi, Working on: 1.- Solve the OpenSSL license issue and upload rc3. On Thu, Jun 18, 2009 at 05:24:25PM +0200, Devid Antonio Filoni wrote: > On Wed, Jun 17, 2009 at 11:45 PM, Jorge Arellano Cid<jcid(a)dillo.org> wrote: > > On Wed, Jun 17, 2009 at 10:01:12PM +0200, Devid Antonio Filoni wrote: > > [...] > > ?Devid: please send me the .deb and its directions when done. > DONE! You can find it at https://launchpad.net/~d.filoni/+archive/ppa > . However I found an error checking my package using lintian: > > E: dillo: possible-gpl-code-linked-with-openssl > N: > N: This package appears to be covered by the GNU GPL but depends on the > N: OpenSSL libssl package and does not mention a license exemption or > N: exception for OpenSSL in its copyright file. The GPL (including version > N: 3) is incompatible with some terms of the OpenSSL license, and therefore > N: Debian does not allow GPL-licensed code linked with OpenSSL libraries > N: unless there is a license exception explicitly permitting this. > N: > N: If only the Debian packaging, or some other part of the package not > N: linked with OpenSSL, is covered by the GNU GPL, please add a lintian > N: override for this tag. Lintian currently has no good way of > N: distinguishing between that case and problematic packages. > N: > N: Severity: serious, Certainty: wild-guess > > Can you please fix it? AFAIS, the only program that links to OpenSSL is the https dpi. i.e. The ssl-enabled dillo binary doesn't link to it. https.filter.dpi links to it. IANAL, but it looks like giving permission for this dpi is enough, and it's already done in its sources (dpi/https.c): * [...] * As a special exception permission is granted to link the code of * the https dillo plugin with the OpenSSL project's "OpenSSL" * library, and distribute the linked executables, without including * the source code for OpenSSL in the source distribution. You must * obey the GNU General Public License, version 3, in all respects * for all of the code used other than "OpenSSL". * */ Please let me know if this is _really_ enough or if some extra legal formula must be added somewhere else. TIA. -- Cheers Jorge.-

15 years, 4 months

Re: [Dillo-dev]Caching

by Jorge Arellano Cid

Brian, On Fri, Oct 22, 2004 at 09:00:27AM -0400, Brian Hechinger wrote: > > > ok, i will volunteer to do the caching portion. > > > > Good! We need developer power. > > and i need more experience. this'll be good for me. ;) > > > Read the docs, and when in the code, after the normal path, > > follow the End2End reload flag. You can also look how it is > > handled with plugins. > > i will do that today, i'll let you know what i can figure out on my own. > > > Beware: don't dig inside the CCC or you'll ge lost. I'm > > preparing a document on it, and without this material, it'd be > > almost impossible to figure it out. > > ok, then i'll be very careful to avoid it for now. ;) > > > It looks like a good idea to start with. Flexible and simple. > > that's what i was striving for. no need to add extra complexity for no good > reason. ;) > > > Caching is complex. Pragma inside meta whithin HTML is just one > > way. HTTP has several others (for instance you'll have to start > > reading at section 13 of rfc2068.txt (aka HTTP1.1). > > ok, in that case i propse to add Pragma first and once i get that working i'll > add the other methods as well. > > > To make things more interesting, if an RFC-compliant user agent > > (browser) is built, then it's very easy to abuse it. By sending > > no-cache directives for advertising for instance. > > hence the need for cacherc so that we can specify which servers we will honor > the no cache directive from. this is something we need to certain things to > work right, but like you said, we don't want to get abused by it either. > > > I hope this gets you started. When in doubt, please ask. > > i still have to go through End2End, but real quick, how would i go about > parsing the header looking for Pragma? what's the best place to do that? Look inside Cache_parse_header(). :-) -- Cheers Jorge.-

20 years

Connection problems on Mac OS X 10.6.7

by rf.opensource＠gmail.com

Well after 2 days of chasing the non-connection bug, I'm still not successful in locating the bug. But first a few points: 1. Mac-Fltk 1.3 indeed contains code for "select"ing socket events. I found this myself and later Manolo verified it. The comment that Jorge mentioned is a leftover, but the code is there. In fact it runs in a pthread, and the whole system wouldn't work without it anyway. 2. So I'm now convinced the problem is somewhere in Dillo. Here is what I have nailed it down to so far: It seems to me that the problem might have to do with "repush". I run the program as: $src/dillo | grep Nav_, and I can get no connection regardless of the websites until I enter a URL that forces a repush. I have a list of websites that do not entice a repush (some of the times): www.yahoo.com, www.google.com, http://www.maketemplate.com/htmlgenerator/htmlout.php autos.yahoo.com, and as long as I keep entering any of these addresses after a fresh start and I don't see a repush message in terminal, I will get nothing in my tabs. As soon as I enter a URL that does entice a repush, the whole system works, including the previous blocked tabs. If later on again a tab doesn't load up, I can make the system work by opening other tabs and entering URLs until a repush happens. So, what is this repush business? And do you think it can have anything to do with the bug I'm seeing? By the way, the busy wait issue seems to be a different bug and just happens to coincide. No matter which website I enter, the first tab (whether I enter URL manually or on command line) never connects and always forces a busy wait. As soon as I open another tab and enter any URL, regardless of whether it will do a repush and open the clog or not, the busy-wait ends. P.S. In my opinion (and ignoring this pesky bug) the single most important feature lacking in dillo is support for floating elements. As soon as we have it, dillo is as good as NetSurf (http://www.netsurf-browser.org/) in functionality with half the memory footprint. As far as I can tell NetSurf is the current champ of low resource + good enough functionality, while IMHO dillo has more potential. -Reza On Fri, May 27, 2011 at 7:11 PM, reza farivar <rf.opensource(a)gmail.com>wrote: > > > On Fri, May 27, 2011 at 3:53 PM, Jorge Arellano Cid <jcid(a)dillo.org>wrote: > >> On Fri, May 27, 2011 at 03:25:32PM -0500, reza farivar wrote: >> > On Fri, May 27, 2011 at 3:18 PM, Jorge Arellano Cid <jcid(a)dillo.org> >> wrote: >> > >> > > On Fri, May 27, 2011 at 01:53:08PM -0500, reza farivar wrote: >> > > > 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) >> > > >> > > Good! >> > > >> > > If you can see the html page from the bookmarks, it means the >> > > whole dpi framework is working on Mac; they communicate using >> > > sockets. >> > > >> > > So it seems the main thing pending is socket support in fl_wait >> > > for Mac (see my previous email). >> > > >> > >> > Yes, I also think it's the source of this problem (see my other email). >> > >> > But what really perplexes me is that this happens only when I enter a >> URL >> > manually. When I follow links from one page to another it never happens. >> Are >> > you guys using different (FLTK) functions when opening a new page or >> > following a links (whether in the same tab or in a new tab)? >> >> No, but when you hit ENTER, FLTK has a chance to queue events >> and zero-wait timeouts for the widget callback and necessary >> stuff. OTOH, clicking a link goes another path (inside dillo). >> >> Can you point me to parts of code for either of these two code paths? > Filename / line number should suffice. > > >> >> > And it seems that as Dillo "warms up" I get less of this problem... >> >> Timimg issues are moody. >> e.g. Have you tried dillo listening a good mp3? :-) >> >> BTW, good you asked Manolo G. >> (FWIW, FLTK2 has code for socket events in Mac). >> >> -- >> Cheers >> Jorge.- >> >> _______________________________________________ >> Dillo-dev mailing list >> Dillo-dev(a)dillo.org >> http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev >> > >

13 years, 5 months

Dillo-dev search results for query "plugin"