- Dillo-dev - lists.mailman3.com

[Dillo-dev]Hello to all and first question

by Roberto A. Foglietta

Hi, first of all: thank you very much for you great job in doing Dillo! Actually I'm trying to use it to display bus time table in a station. What I'm looking here? A /deprecated/ features! I need to reload _automatically_ pages on the bus-station screens, there are some ways to do that: 1) use deprecated meta refresh tag (not work, even in previous vers.) 2) modify Dillo code to accept a -r <n> flag which force him to reload every <n> seconds 3) writing a dpi plugin (???) The way n.1 could be the best for me because I could choose reload delay just from server inserting that deprecated flag in HTML code. But old version of Dillo like 0.2.4 - 0.6.1 don't do that. Simply moved on the specified url and nothing else about reload. I would find a solution should be usefull for everybody and quite simple to do. Like put a flag which enable that deprecated tag and do it working. Or it could be better do something else? Automatically reload should be very usefull in all embedded (but not pda) system which aim to keep some information on the screen refreshed. That for all. Cheers, -- Roberto A. Foglietta Analista Programmatore GNU/Linux SAD Trasporto Locale S.p.a. Corso Italia 13/N 39100 BOLZANO (I) Tel. +39/0471-450.261 Fax +39/0471-450.253

Oct. 20, 2004

[Dillo-dev]interesting link about browsers security tests

by Florent BERANGER

Hi, http://www.securityfocus.com/archive/1/378632/2004-10-15/2004-10-21/2 Best regards, Florent ************************ ADSL ILLIMITE TISCALI + TELEPHONE GRATUIT ************************ Surfez 40 fois plus vite pour 30EUR/mois seulement ! Et téléphonez partout en France gratuitement, vers les postes fixes (hors numéros spéciaux). Tarifs très avantageux vers les mobiles et l'international ! Pour profiter de cette offre exceptionnelle, cliquez ici : http://register.tiscali.fr/adsl (voir conditions sur le site)

Oct. 20, 2004

Re: [Dillo-dev]Bug #364

by Jorge Arellano Cid

On Wed, Oct 20, 2004 at 08:18:20PM +0800, Russell J. Wood wrote: > Hello Dilldoers =b Ehrmm, Dillodoers I'd say... :-) > > Would the said bug be because the Set-Cookie entity sent from advogato.org is > not RFC compliant? > > Here is what I received: > > Set-Cookie: id=<data>; path=/; Expires=Thursday, 20-Oct-2005 11:57:18 GMT > > I'm under the impression the Expires attribute is meant to be as: > > Wdy, DD-MM-YYYY HH:MM:SS GMT > > Therefore, because the Weekday isn't in an abbreviated form it is being > discarded? Most probably. The timestamp parsing routine in cookies.c accepts: RFC-1123 | RFC-850 | ANSI asctime. Reviewing the SPECS though, it's interesting to note that the date format is not defined with precision inside them, especially the weekday. RFC2109 states it as: Wdy, DD-MM-YYYY HH:MM:SS GMT but it doesn't say whether 'Wdy' is three chars long... Netscape's original SPEC: http://www.danbbs.dk/~erikoest/hello.htm (this page has a quote at the bottom) says: <q> The date string is formatted as: Wdy, DD-Mon-YYYY HH:MM:SS GMT This is based on RFC 822, RFC 850, RFC 1036, and RFC 1123, with the variations that the only legal time zone is GMT and the separators between the elements of the date must be dashes. </q> Nothing about 'Wdy' length. Finally RFC 822 goes into the depth of defining the day format, and it does so as three chars long: <q> day = "Mon" / "Tue" / "Wed" / "Thu" / "Fri" / "Sat" / "Sun" </q> A long weekday is understandable as an interpretation of the SPEC (where it isn't defined). Moreover, the above mentioned URL, uses a long weekday as an example: <q> expires=Wednesday, 09-Nov-99 23:12:40 GMT </q> As you see, I'm not sure whether this long day is a SPEC violation or not. I'm more inclined to think it is an acceptable interpretation. Shall you find more evidence, or feel confident enough to modify Cookies_create_timestamp(), it may be included in 0.8.3. Comments, anyone? -- Cheers Jorge.-

Oct. 20, 2004

[Dillo-dev]Dillo Bug #577

by Russell J. Wood

Hello Jason, I'm not sure how long ago you posted that bug, but it isn't a Dillo bug. The reason /usr/bin/dpid was executed is because it would have been before /usr/home/jason/bin in the PATH variable. Try moving your ~/bin directory before /usr/bin and see if you get the same results. Regards, Russell

Oct. 20, 2004

[Dillo-dev]Bug #514

by Russell J. Wood

Hello all. Bug number 514 isn't really a bug, per-se, due to the fact that an XHTML style script tag (<script src="java.js" type="text/javascript" />) isn't permitted in the head. Rendering it would be the bug, in my opinion. Regards, Russell

Oct. 20, 2004

[Dillo-dev]Bug #364

by Russell J. Wood

Hello Dilldoers =b Would the said bug be because the Set-Cookie entity sent from advogato.org is not RFC compliant? Here is what I received: Set-Cookie: id=<data>; path=/; Expires=Thursday, 20-Oct-2005 11:57:18 GMT I'm under the impression the Expires attribute is meant to be as: Wdy, DD-MM-YYYY HH:MM:SS GMT Therefore, because the Weekday isn't in an abbreviated form it is being discarded? Regards, Russell

Oct. 20, 2004

Re: [Dillo-dev]Possible RPM delays

by Jorge Arellano Cid

On Mon, Oct 18, 2004 at 10:39:24PM -0700, Kelson Vibber wrote: > My main computer at home has been having problems lately. I *hope* > it's just the video card (I would expect worse problems if it were the > motherboard, CPU, or memory), but I think it's fair to warn you that if > 0.8.3 final comes out before I've resolved the issues, I might not be > able to build all the RPMs immediately. Thanks for the notice Kelson. Can it be ready for an Oct 25 or 27 release? (I still have to prepare rc3 with the fix to the redirection CPU hog. I'm hands on it today, so hopefully rc3 will be ready before Friday and after some redirection specific tests, 0.8.3 can be finally released near those dates). -- Cheers Jorge.-

Oct. 20, 2004

Re: [Dillo-dev]dillo-0.8.3-rc2 ready for download

by Jorge Arellano Cid

On Wed, Oct 20, 2004 at 12:09:38AM +0100, Jeremy Henty wrote: > > On Mon, Oct 18, 2004 at 04:15:01PM -0300, Jorge Arellano Cid wrote: > > > ... please beware and remove: > > > > /usr/local/lib/dillo/dpi/file/file.filter.dpi or > > /usr/lib/dillo/dpi/file/file.filter.dpi > > Arrgh! This breaks for me. If I don't remove this file everything > works wonderfully. If I rename it then accessing a file:... URL gives > me "ERROR: can't start dipd daemon!". This shouldn't happen... > > I am running Linux From Scratch 4.1, kernel 2.4.27 , glibc-2.3.1 , > gcc-3.2.1 , glib-1.2.10 , gtk+-1.2.10 . The file:... URL is my home > as set in dillorc, so I get the above error simply by clicking the > home button. No other changes have been made to dillorc. > > How can I investigate this further? ps aux | grep dpid Kill every old dpid that may be running. 'dpidc stop' or 'kill <pids>' ps aux | grep dpi remove any dpi server that may linger. chmod -x /usr/lib/dillo/dpi/file/file.filter.dpi Be sure the new file.dpi is in /usr/lib/dillo/dpi/file/, this happens after 'make install'. Test again. -- Cheers Jorge.-

Oct. 20, 2004

Re: [Dillo-dev]dillo-0.8.3-rc2 ready for download

by Jeremy Henty

On Mon, Oct 18, 2004 at 04:15:01PM -0300, Jorge Arellano Cid wrote: > ... please beware and remove: > > /usr/local/lib/dillo/dpi/file/file.filter.dpi or > /usr/lib/dillo/dpi/file/file.filter.dpi Arrgh! This breaks for me. If I don't remove this file everything works wonderfully. If I rename it then accessing a file:... URL gives me "ERROR: can't start dipd daemon!". I am running Linux From Scratch 4.1, kernel 2.4.27 , glibc-2.3.1 , gcc-3.2.1 , glib-1.2.10 , gtk+-1.2.10 . The file:... URL is my home as set in dillorc, so I get the above error simply by clicking the home button. No other changes have been made to dillorc. How can I investigate this further? Cheers, Jeremy

Oct. 19, 2004

Re: [Dillo-dev]Re: comment from ps2 group on 0.8.x

by Jorge Arellano Cid

On Tue, Oct 19, 2004 at 08:54:06PM +0100, robert w hall wrote: > In article <20041019201134.GC2745(a)dillo.org>, Jorge Arellano Cid > <jcid(a)dillo.org> writes > >On Tue, Oct 19, 2004 at 07:33:18PM +0100, robert w hall wrote: > >> > >> > >> > >> Jorge > >> This from playstation2 group - I've asked him to ty the rc2 version > >> and/or clarify which 0.8.x version didn't render properly > >> Bob Hall > > > > Thanks. > > > > I received this email and the former on my personal email > >address. AFAIU you're on dillo-dev so I answered there, and to be > >sure this one goes to dillo-dev and to your address. > > > > > Please use dillo-dev in the future. > > > OK - but I rather presumed there was no point in filling up the list > with 'OK' from 60 different obscure machine-types 60 different obscure machine-types? > and besides, I like anonymity :-) Me too! But that's life! :) -- Cheers Jorge.- PS: Please excuse the repeated answers. My MTA said timeout, so I resent them. There you have the results...

Oct. 19, 2004

Re: [Dillo-dev]dillo-0.8.3-rc2 ready for download

by Johannes Hofmann

Hi, compiles and runs nicely on DragonFly BSD (including file DPI). Thanks, Johannes On Mon, Oct 18, 2004 at 04:15:01PM -0300, Jorge Arellano Cid wrote: > Hi there, > > The new dillo-0.8.3-rc2 is ready for download and testing! > > It's basically the same as rc1, but with the race condition on > the file dpi solved. It also uses a dpi server instead of a dpi > filter so please beware and remove: > > /usr/local/lib/dillo/dpi/file/file.filter.dpi or > /usr/lib/dillo/dpi/file/file.filter.dpi > > Actually it can work with both, but as we want to test the dpi > server in the tarball (default) please be careful and be sure to > remove the file filter dpi to be testing the file server dpi. > > (the other change is a minor improvement on the visited link > color choosing algorithm). > > Feedback is very welcomed. After you say it's OK, it will be > officially announced as dillo-0.8.3. > > Download URL: > > http://www.dillo.org/download/dillo-0.8.3-rc2.tar.bz2 > > -- > Cheers > Jorge.- > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)lists.auriga.wearlab.de > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev >

Oct. 19, 2004

[Dillo-dev]Re: comment from ps2 group on 0.8.x

by Jorge Arellano Cid

On Tue, Oct 19, 2004 at 07:33:18PM +0100, robert w hall wrote: > > > > Jorge > This from playstation2 group - I've asked him to ty the rc2 version > and/or clarify which 0.8.x version didn't render properly > Bob Hall Thanks. I received this email and the former on my personal email address. AFAIU you're on dillo-dev so I answered there, and to be sure this one goes to dillo-dev and to your address. Please use dillo-dev in the future. The main problem with writing directly to me is that I end being the only one that knows what's going on! :-) (Ah, and there's also the problem of duplicate answers...) > > ________________________________________________________________________ > > Read and respond to this message at: > https://playstation2-linux.com/forum/message.php?msg_id=45864 > By: deesaid Oh, please forward this in my name to that group. > > I have a problem with 0.8.x versions in PS2: some pages that look > correct with > the older dillo (the one that's precompiled here), when I try them with > the > newer 0.8.x versions look unformatted. The simplest example is doing a > search > on google: at the search results page, in a regular browser you can see > the > google logo at the top, the search form to the right, and below the logo > and > the form, the search results. In 0.8.x versions the results page is > composed > by the Google logo at the left top and the search form at the right, but > the > results are shown just below the search form, leaving a hughe blank > margin below > the google logo. > > Is there a way to fix it? Yes, the new parser (W3C + heuristics) solves this problem. RC2 will work and so 0.8.3. -- Cheers Jorge.-

Oct. 19, 2004

Re: [Dillo-dev]dillo-0.8.3-rc2 ready for download

by Jorge Arellano Cid

On Tue, Oct 19, 2004 at 10:16:34AM +0100, robert w hall wrote: > In article <20041018191501.GM9792(a)dillo.org>, Jorge Arellano Cid > <jcid(a)dillo.org> writes > >Hi there, > > > > The new dillo-0.8.3-rc2 is ready for download and testing! > > > > It's basically the same as rc1, but with the race condition on > >the file dpi solved. It also uses a dpi server instead of a dpi > >filter so please beware and remove: > > > > /usr/local/lib/dillo/dpi/file/file.filter.dpi or > > done - :-) :-) > > [...] > > Feedback is very welcomed. After you say it's OK, it will be > >officially announced as dillo-0.8.3. > > > > Download URL: > > > > http://www.dillo.org/download/dillo-0.8.3-rc2.tar.bz2 > > > > > seems to compile OK on a playstation2 with https enabled > > dpi_parse_token gives an ERROR from open_url each time when trying to > read the filename, > before successfully executing start_send_page... > I presume this is an intended untidyness ? Yes. Before sending the dpi request to the server, a tentative connection is made to be sure it is running. If it's not, a new server is launched. Notwithstanding the untidiness exists ;), essentially it consists in giving a scary message instead of a more meaningful one. > Keep up the good work Thanks. We hope to. -- Cheers Jorge.-

Oct. 19, 2004

Re: [Dillo-dev]Re: comment from ps2 group on 0.8.x

by robert w hall

In article <20041019201134.GC2745(a)dillo.org>, Jorge Arellano Cid <jcid(a)dillo.org> writes >On Tue, Oct 19, 2004 at 07:33:18PM +0100, robert w hall wrote: >> >> >> >> Jorge >> This from playstation2 group - I've asked him to ty the rc2 version >> and/or clarify which 0.8.x version didn't render properly >> Bob Hall > > Thanks. > > I received this email and the former on my personal email >address. AFAIU you're on dillo-dev so I answered there, and to be >sure this one goes to dillo-dev and to your address. > > Please use dillo-dev in the future. OK - but I rather presumed there was no point in filling up the list with 'OK' from 60 different obscure machine-types and besides, I like anonymity :-) -- robert w hall

Oct. 19, 2004

[Dillo-dev]Re: Dillo potential DOS via redirect loop

by Jorge Arellano Cid

Hi Kelson, On Mon, Oct 18, 2004 at 04:39:34PM -0700, Kelson Vibber wrote: > I was attempting to pull up the bug database for Wordpress > <http://mosquito.wordpress.org/> in Dillo 0.8.3rc2, and noticed that the > browser froze when I clicked on the "View bugs" link. After I killed it > and re-launched it from a command line, I saw it spewing Nav_open_url > messages over and over, alternating between these two lines: > > Nav_open_url: Url=>http://mosquito.wordpress.org/view_all_bug_page.php< > Nav_open_url: Url=>http://mosquito.wordpress.org/view_all_set.php?type=0< Yes, it happens... > > I'm not entirely sure what the site is trying to do, but Firefox, Opera > and IE all seem to make it through okay. I suspect it's something like > this: > > 1. view_all_bug_page.php checks for a cookie. It doesn't find it, so it > redirects (302) to view_all_set.php?type=0 > 2. view_all_set.php sets the cookie, then sends the browser back to the > original page. > 3. Either Dillo hasn't accepted the cookie and view_all_bug_page.php > sends the redirect again, or Dillo has already cached the 302 response > and jumps to view_all_set.php anyway. > > Adding mosquito.wordpress.org to cookiesrc doesn't make a difference. Currently Dillo's cache is handling HTTP 30x answers as cacheable redirections. This is more a lack of implementation than a BUG (there's no code to handle 302 answers now). > > Based on the libwww-perl HEAD utility (which breaks out of the loop > after 7 redirects) and just telnetting to port 80, I've found the following: > > - They're using a 302 (temporary) redirect on both scripts > - They're setting a cookie on view_all_set.php. > - They're using relative URLs in the Location header (which I think is > technically not allowed, but has been used in practice for years.) Dillo handles relative locations. > Regardless of whether this setup is valid, it *does* make Dillo stop > responding. There is at least one bug here -- Dillo isn't detecting the > redirect loop and breaking out of it -- and possibly two (if it's > caching the 302/temporary status). Yes, there're two problems. Dillo hogging the CPU is a BUG that'd be better fixed for 0.8.3. The caching problem is a large issue that needs much more time to tackle. The cache problem is very interesting: if a browser happens to follow the SPEC, it becomes easy to abuse (e.g. pragma: no-cache advertising). OTOH, some sites can require to refresh some page contents in order to keep some meaningful state (HTTPS services usually use cache directives). Maybe as it happens with cookies, just allowing certain cites and honoring HTTP cache directives from that set only, is a good solution in the long term. I'll try to find a way to catch the redirection loop hog... -- Cheers Jorge.-

Oct. 19, 2004

Re: [Dillo-dev]Re: anchor names

by Sebastian Geerken

On Tue, Oct 19, Matthias Franz wrote: > Dear Sebastian, > > thanks for the quick bugfix. > > On Sun, Oct 17, 2004 at 04:32:09PM +0200, Sebastian Geerken wrote: > > The changes also make the viewport check, whether anchor names are > > unique. If not, g_return_if_fail is called, which messages should not > > be printed normally (and "normally" includes faulty web pages), > > instead, normal HTML error messages should be shown. Probably, the > > best solution is to add a function a_Dw_gtk_viewport_check_anchor(), > > which returns, whether an anchor is already defined. If it returns > > TRUE, an appropriate message is shown, and the anchor is not added. > > Why don't you let a_Dw_gtk_viewport_add_anchor return a result: > FALSE = ok, TRUE = anchor already defined and not changed > Then a_Dw_page_add_anchor could pass this on to html.c, where > my patch would produce the HTML warning. > Otherwise one would look up the hash table twice, once in > a_Dw_gtk_viewport_check_anchor and once in a_Dw_gtk_viewport_add_anchor. See latest commitment, something like this has been added. There are also now HTML warnings, if equal anchors have been added twice. For those, who are interested, I've attached the changes as patch. Sebastian

Oct. 19, 2004

Re: [Dillo-dev]Re: dillo patch: anchor names

by Matthias Franz

Hi Richard, thanks for your comments! On Fri, Oct 15, 2004 at 04:35:29PM -0400, Richard Page-Wood wrote: > I do know a bit about HTML and XHTML, though, and I was wondering > about your doctype-sniffing patch. As I understand it, you're trying > to distinguish between HTML 4.01 and XHTML 1.x by sniffing the doctype > and giving appropriate warnings for invalid markup. Are you also going > to alter the rendering for XHTML? Certainly not as part of my patch. It's origin was simply the observation that Dillo refused anchor names like "Dürst" which are allowed in HTML if defined with the "name" attribute (see Section 12.2.3 of the HTML 4.01 spec). > There's a good article here: > > http://www.hixie.ch/advocacy/xhtml > > which talks amongst other things about the impossibility of correctly > identifying an XHTML document which might be of interest to you. Having looked at this article and the references given therein, I don't feel anymore that it would be a good idea to try and figure out whether the document type is HTML or XHTML. I still like the idea of supporting XHTML in some way, mostly because XML lacks many of the strange features of SGML that make parsing difficult. For example, "<" and "&" are not allowed as ordinary characters in XML. But this has nothing to do with anchor names, so I will remove the XHTML parts of the patch (unless someone complains). Jorge: Are you still interested in evaluating <!DOCTYPE> to figure out the HTML version? Maybe it would be ok for a small browser like Dillo to stick to HTML 4.01. All the best, -- Matthias Franz Section de Mathématiques, Université de Genève, Suisse

Oct. 19, 2004

[Dillo-dev]Re: anchor names

by Matthias Franz

Dear Sebastian, thanks for the quick bugfix. On Sun, Oct 17, 2004 at 04:32:09PM +0200, Sebastian Geerken wrote: > The changes also make the viewport check, whether anchor names are > unique. If not, g_return_if_fail is called, which messages should not > be printed normally (and "normally" includes faulty web pages), > instead, normal HTML error messages should be shown. Probably, the > best solution is to add a function a_Dw_gtk_viewport_check_anchor(), > which returns, whether an anchor is already defined. If it returns > TRUE, an appropriate message is shown, and the anchor is not added. Why don't you let a_Dw_gtk_viewport_add_anchor return a result: FALSE = ok, TRUE = anchor already defined and not changed Then a_Dw_page_add_anchor could pass this on to html.c, where my patch would produce the HTML warning. Otherwise one would look up the hash table twice, once in a_Dw_gtk_viewport_check_anchor and once in a_Dw_gtk_viewport_add_anchor. All the best, -- Matthias Franz Section de Mathématiques, Université de Genève, Suisse

Oct. 19, 2004

[Dillo-dev]Possible RPM delays

by Kelson Vibber

My main computer at home has been having problems lately. I *hope* it's just the video card (I would expect worse problems if it were the motherboard, CPU, or memory), but I think it's fair to warn you that if 0.8.3 final comes out before I've resolved the issues, I might not be able to build all the RPMs immediately. Kelson Vibber www.hyperborea.org

Oct. 19, 2004

[Dillo-dev]dillo-0.8.3-rc2 ready for download

by Jorge Arellano Cid

Hi there, The new dillo-0.8.3-rc2 is ready for download and testing! It's basically the same as rc1, but with the race condition on the file dpi solved. It also uses a dpi server instead of a dpi filter so please beware and remove: /usr/local/lib/dillo/dpi/file/file.filter.dpi or /usr/lib/dillo/dpi/file/file.filter.dpi Actually it can work with both, but as we want to test the dpi server in the tarball (default) please be careful and be sure to remove the file filter dpi to be testing the file server dpi. (the other change is a minor improvement on the visited link color choosing algorithm). Feedback is very welcomed. After you say it's OK, it will be officially announced as dillo-0.8.3. Download URL: http://www.dillo.org/download/dillo-0.8.3-rc2.tar.bz2 -- Cheers Jorge.-

Oct. 18, 2004

Re: [Dillo-dev]Re: race condition patch]

by Jorge Arellano Cid

-- Cheers Jorge.-

Oct. 18, 2004

[Dillo-dev]Re: anchor names

by Jorge Arellano Cid

Hi there, This is half an email forward and half an answer. On Sun, Oct 17, 2004 at 04:32:09PM +0200, Sebastian Geerken wrote: > Hi, > > the dillo-dev mailing list does not seem to work, I always get an 550 > error, so I forward you the mail, which I did not succeed to send to > the list. > > Sebastian Now, 18 Oct, it works for me. I'm answering to dillo-dev because my test mail succeeded. > Date: Sun, 17 Oct 2004 15:54:40 +0200 > From: Sebastian Geerken <sgeerken(a)dillo.org> > Subject: Re: [Dillo-dev]anchors_table not cleared > To: dillo-dev(a)auriga.wearlab.de > Mail-Followup-To: Sebastian Geerken <sgeerken(a)dillo.org>, > dillo-dev(a)auriga.wearlab.de > > On Fri, Oct 15, Matthias Franz wrote: > > I'm writing a patch for a better treatment of anchor names in HTML pages. > > During this, I've come across the following bug in Dillo. > > > > Jorge: I think this is what produced the bug in the patch I sent you. > > > > Entries are never removed from the hash table anchors_table, which stores > > the anchors of a page (see dw_gtk_viewport.c). This means that whenever a > > new page is displayed in the same viewport, the old anchors remain in > > the hash table, but their keys are overwritten. Like in this example: > > (The "###" lines are debug information I've inserted.) > > > > [...] > > > > Obviously, the anchors_table must be cleared whenever a new page is > > displayed. I don't know the dw* part of Dillo very well, and the > > connection between the html structure and the viewport seems to be quite > > indirect. Can anyone suggest a fix? > > The latest commitment in CVS fixes this, the patch is also > attached. Jorge, I'm not sure, whether this should be included into > the release, since the changes are rather big, and currently, it only > fixes a memory leak. I'd prefer to leave it out of rc2. It's been more than four months since our last release. The one following 0.8.3 is going to have the new abstraction layer for Dw, and other changes, so just in case it takes some time to stabilize it, it'd be very good to have a solid 0.8.3 out there. I'll prepare the dillo-0.8.3-rc2 tarball ASAP and write back when it's ready for download... > > The changes also make the viewport check, whether anchor names are > unique. If not, g_return_if_fail is called, which messages should not > be printed normally (and "normally" includes faulty web pages), > instead, normal HTML error messages should be shown. Probably, the > best solution is to add a function a_Dw_gtk_viewport_check_anchor(), > which returns, whether an anchor is already defined. If it returns > TRUE, an appropriate message is shown, and the anchor is not added. Agreed. -- Cheers Jorge.-

Oct. 18, 2004

[Dillo-dev]Is dillo-dev back? (test mail)

by Jorge Arellano Cid

Hi, If this is readable, dillo-dev is up! -- Cheers Jorge.-

Oct. 18, 2004

Re: [Dillo-dev]Re: dillo patch: anchor names

by Richard Page-Wood

Firstly, hello - I'm a fan and user of Dillo, as well as being a web developer, but I am in no way a coder and I don't have any experience in building web browsers or any other programs - so bear with me if I am talking rubbish. I do know a bit about HTML and XHTML, though, and I was wondering about your doctype-sniffing patch. As I understand it, you're trying to distinguish between HTML 4.01 and XHTML 1.x by sniffing the doctype and giving appropriate warnings for invalid markup. Are you also going to alter the rendering for XHTML? I know that the big browsers such as Gecko or IE6 do doctype-sniffing to switch between a "quirks" mode or a "standards-compliant" mode - are you thinking of doing this, or is it just for showing an error dialog? > > > > * First of all, it evaluates the <!doctype> tag to find out whether > > the document is HTML or XHTML. If the tag is wrong or missing, an > > error is raised. > > Parsing <!doctype ...> is a good idea. > There's a good article here: http://www.hixie.ch/advocacy/xhtml which talks amongst other things about the impossibility of correctly identifying an XHTML document which might be of interest to you. > > You see that is still work to do in html.c, all the more because know > > one could add error messages based on the distinction between HTML and > > XHTML. (E.g., "&#X40;" is illegal in XHTML because of the uppercase "X".) > > Would this kind of changes be welcome? In my personal and certainly very humble opinion, if an XHTML 1.x document is served with the mime-type text/html (as virtually all are, and anyway Dillo doesn't do application/xhtml+xml), it should simply be parsed as HTML 4.01 - precisely because the mime type is a clear indication that it is supposed to be a HTML 4.01 compatible document. If you are doing doctype sniffing in the Gecko way to switch rendering modes, then I'm sure you'll do it better than IE6 and not assume that the doctype can only occur on the first line (IE6 messes up if there's an xml prolog or even a comment). Hey, it'll just be another reason why Dillo is better than IE6! Of course, the currently accepted convention for other browsers is that HTML 4.01 doctypes which include a full w3c DTD url and treated as standards-compliant, but 4.01 without the url and HTML 4.0 and earlier are not. XHTML doctypes are always standards-compliant whether or not an url is present. Finally, and most importantly, I'd like to add my word of thanks to the developers of this really excellent little browser - and having subscribed recently to this list, I can see the level of dedication for making Dillo even better. Richard Page-Wood

Oct. 15, 2004

[Dillo-dev]Re: dillo patch: anchor names

by Jorge Arellano Cid

Matthias, Maybe the most important guideline in this answer is that we're trying to provide good hint-messages for common HTML bugs, not being as picky (or correct) as the W3C's validator. The two main reasons behind this are that first, we do not want to (nor can) complicate too much the code inside dillo (some big browsers have several parsers inside), and we want to help to fix the most problematic HTML bugs (mainly nesting), not all. BTW, inside Dillo all the HTML-like content is currently parsed as HTML-4.01 with a few minor exceptions. HTML-4.01 is a good default because it tries hard to be backwards compatible. The third reason is that if the need for a formal validation arises, the W3C does a great job on it! :) On Wed, Oct 13, 2004 at 06:20:36PM +0200, Matthias Franz wrote: > Dear Jorge, > > here is the anchor name patch I promised you long time ago. > It does the following: > > * First of all, it evaluates the <!doctype> tag to find out whether > the document is HTML or XHTML. If the tag is wrong or missing, an > error is raised. Parsing <!doctype ...> is a good idea. Putting that info in a structure like this one: typedef enum { DT_NONE, DT_HTML, DT_XHTML } DocumentType; typedef struct { DocumentType Type; float Version; } DocumentInfo; allows for having all the information in one place, and to later decide whether to take some action or not. e.g. DT_NONE + DT_HTML + 4.01 means no doctype was given and that HTML-4.01 is assumed as default. DT_HTML + 4.01 means it was stated explicitly in doctype. > > * Dillo now distinguishes more carefully between head and body section There was a bug in dillo (up to rc1). A patch is now in CVS. When the HTML meta refresh warning was sent, it switched from IN_HEAD to IN_BODY. Note that for HTML-4.01: BODY: Start tag: optional, End tag: optional HEAD: Start tag: optional, End tag: optional > * The errors "<...> not allowed in body section" are now centralised > in Html_process_tag Could be. > Moreover, errors are raised in the following situations: > (After all, this was the goal!) > > * if an anchor name (defined by "name" or "id") is already defined OK. > For performance reasons, I have changed (very) few lines in dw_page.c > and dw_gtk_viewport.c. (pending as for the latest bugs found...) > > * if (in HTML mode) the "name" and "id" tags of <a> differ OK. > * if <a> tags are nested OK. > * extra_warning if an anchor name (defined by "name") was illegal for "id" OK. > > > NOT DONE: > > * warning if in XHTML <a> is used with "name" and no "id" > (according to the spec, this has no effect, which is probably not intended) OK. > * the "refresh" warning causes (like before) an error if further > head elements follow the <meta> Fixed in CVS now (Björn Brill). > > * I've discovered that some parts of the TagInfo structure are not used > any more, for example TagLevel and bits 2^0 = 1 and 2^2 = 4 of Flags. TagLevel is used extensively by the W3C+heuristics mode. Look at Html_tags_get_taglevel() calls. Yes, bits 0 and 2 are not yet used, but there they are just in case they're needed. > In particular, I didn't know how to define them for <!doctype> on line 4281. HTML elements can be of type 'block' or 'inline' (well, also 'flow'). And they can be containers of 'inline' or containers of 'blocks'. This is what the flags are. I'll comment that inside the code. For instance, <address> is an 'block' element, and a cointainer of 'inline' elements. address B8(0110) |||`- inline element ||`-- block element |`--- inline container `---- block container This is well defined here: http://www.cs.tut.fi/~jkorpela/html/nesting.html Now, as !doctype isn't there, an inline element that's a block container can appear almost anywhere (i.e. B8(0101)), and help to tackle the issue. > * IN_BUTTON in html.h is also not used any more; I've replaced it by the > new IN_A. Let IN_BUTTON be. As buttons can't be nested, it was meant to catch that one (not implemented yet). > * One change in Html_process_tag is more of a hack; I didn't want to > start rewriting everything without contacting you first. > > > You see that is still work to do in html.c, all the more because know > one could add error messages based on the distinction between HTML and > XHTML. (E.g., "&#X40;" is illegal in XHTML because of the uppercase "X".) > Would this kind of changes be welcome? Hmmm, I think this is too much by now. > I hope this patch can still make it into rc2. If you have comments or > questions, please let me know. As explained before, it better not be in rc2. Just bug-fixes. -- Regards Jorge.-

Oct. 15, 2004

[Dillo-dev]Re: race condition patch

by Matthias Franz

On Fri, Oct 15, 2004 at 10:16:54AM -0300, Jorge Arellano Cid wrote: > BTW, did you had the time to test the race condition patch in > the CVS? Yes, but not very much. I've tested several critical pages, and there were no problems at all. I want to test it more thoroughly during the weekend. All the best, -- Matthias Franz Section de Mathématiques, Université de Genève, Suisse

Oct. 15, 2004

Re: [Dillo-dev]anchors_table not cleared

by Jorge Arellano Cid

On Fri, Oct 15, 2004 at 02:51:21PM +0200, Matthias Franz wrote: > Hi everybody, > > I'm writing a patch for a better treatment of anchor names in HTML pages. > During this, I've come across the following bug in Dillo. > > Jorge: I think this is what produced the bug in the patch I sent you. Thanks for the tip. (more on this later). But keep on reading... ;) > > > Entries are never removed from the hash table anchors_table, which stores > the anchors of a page (see dw_gtk_viewport.c). This means that whenever a > new page is displayed in the same viewport, the old anchors remain in > the hash table, but their keys are overwritten. Like in this example: > (The "###" lines are debug information I've inserted.) > > ~$ dillo http://www.google.de > dillo_dns_init: Here we go! > Disabling cookies. > ### Dw_gtk_viewport_init: anchors_table init > Nav_open_url: Url=>about:splash< > Nav_open_url: Url=>http://www.google.de< > Dns_server [0]: www.google.de is 0x8100ea8 > Connecting to 66.102.9.99 > ### size(anchors_table) = 0 > ### entries: > ### Html_add_anchor: adding anchor 1a > ### size(anchors_table) = 1 > ### entries: <1a> > ### Html_add_anchor: adding anchor 2a > ### size(anchors_table) = 2 > ### entries: <2a> <1a> > ### Html_add_anchor: adding anchor 3a > ### size(anchors_table) = 3 > ### entries: <3a> <2a> <1a> > ### Html_add_anchor: adding anchor 4a > ### size(anchors_table) = 4 > ### entries: <4a> <3a> <2a> <1a> > ### Html_add_anchor: adding anchor all > ### size(anchors_table) = 5 > ### entries: <4a> <all> <3a> <2a> <1a> > ### Html_add_anchor: adding anchor lgr > ### size(anchors_table) = 6 > ### entries: <4a> <all> <3a> <2a> <1a> <lgr> > ### Html_add_anchor: adding anchor cty > Nav_open_url: Url=>http://www.google.de/imghp?hl=de&tab=wi&ie=UTF-8< > Connecting to 66.102.9.99 > ### size(anchors_table) = 7 > ### entries: <> <> <h3> <> <¸1> <À(> <> > ### Html_add_anchor: adding anchor 0a > ### size(anchors_table) = 8 > ### entries: <0a> <> <> <h3> <> <¸1> <> <> > ### Html_add_anchor: adding anchor 2a > ### size(anchors_table) = 9 > ### entries: <0a> <> <> <h3> <> <2a> <¸1> <> <> > ### Html_add_anchor: adding anchor 3a > ### size(anchors_table) = 10 > ### entries: <0a> <> <> <h3> <3a> <> <2a> <¸1> <> <> > ### Html_add_anchor: adding anchor 4a > Dillo: normal exit! > > > Obviously, the anchors_table must be cleared whenever a new page is > displayed. I don't know the dw* part of Dillo very well, and the > connection between the html structure and the viewport seems to be quite > indirect. Can anyone suggest a fix? Please wait for Sebastian to answer this one. I remember being through the handling code for anchors in the past, and it has its subtleties for sure. I'll review the patch you sent me in detail now, and send you my comments on the approach. I'm busy with the rc2 work now. This patch shouldn't go in because this stage is a bugfix only (and the dillo-0.8.3 release is very delayed now :( ). BTW, did you had the time to test the race condition patch in the CVS? -- Cheers Jorge.-

Oct. 15, 2004

[Dillo-dev]anchors_table not cleared

by Matthias Franz

Hi everybody, I'm writing a patch for a better treatment of anchor names in HTML pages. During this, I've come across the following bug in Dillo. Jorge: I think this is what produced the bug in the patch I sent you. Entries are never removed from the hash table anchors_table, which stores the anchors of a page (see dw_gtk_viewport.c). This means that whenever a new page is displayed in the same viewport, the old anchors remain in the hash table, but their keys are overwritten. Like in this example: (The "###" lines are debug information I've inserted.) ~$ dillo http://www.google.de dillo_dns_init: Here we go! Disabling cookies. ### Dw_gtk_viewport_init: anchors_table init Nav_open_url: Url=>about:splash< Nav_open_url: Url=>http://www.google.de< Dns_server [0]: www.google.de is 0x8100ea8 Connecting to 66.102.9.99 ### size(anchors_table) = 0 ### entries: ### Html_add_anchor: adding anchor 1a ### size(anchors_table) = 1 ### entries: <1a> ### Html_add_anchor: adding anchor 2a ### size(anchors_table) = 2 ### entries: <2a> <1a> ### Html_add_anchor: adding anchor 3a ### size(anchors_table) = 3 ### entries: <3a> <2a> <1a> ### Html_add_anchor: adding anchor 4a ### size(anchors_table) = 4 ### entries: <4a> <3a> <2a> <1a> ### Html_add_anchor: adding anchor all ### size(anchors_table) = 5 ### entries: <4a> <all> <3a> <2a> <1a> ### Html_add_anchor: adding anchor lgr ### size(anchors_table) = 6 ### entries: <4a> <all> <3a> <2a> <1a> <lgr> ### Html_add_anchor: adding anchor cty Nav_open_url: Url=>http://www.google.de/imghp?hl=de&tab=wi&ie=UTF-8< Connecting to 66.102.9.99 ### size(anchors_table) = 7 ### entries: <> <> <h3> <> <¸1> <À(> <> ### Html_add_anchor: adding anchor 0a ### size(anchors_table) = 8 ### entries: <0a> <> <> <h3> <> <¸1> <> <> ### Html_add_anchor: adding anchor 2a ### size(anchors_table) = 9 ### entries: <0a> <> <> <h3> <> <2a> <¸1> <> <> ### Html_add_anchor: adding anchor 3a ### size(anchors_table) = 10 ### entries: <0a> <> <> <h3> <3a> <> <2a> <¸1> <> <> ### Html_add_anchor: adding anchor 4a Dillo: normal exit! Obviously, the anchors_table must be cleared whenever a new page is displayed. I don't know the dw* part of Dillo very well, and the connection between the html structure and the viewport seems to be quite indirect. Can anyone suggest a fix? Thanks in advance, -- Matthias Franz Section de Mathématiques, Université de Genève, Suisse

Oct. 15, 2004

[Dillo-dev][marianne@mathematicians.de: Compatibility]

by Jorge Arellano Cid

-- Cheers Jorge.-

Oct. 15, 2004

Re: [Dillo-dev]testing dillo-0.8.3-rc1

by Jorge Arellano Cid

On Wed, Oct 06, 2004 at 03:47:32PM +0200, Bjoern Brill wrote: > Hello, > > [...] > - This one is not new, but I fixed it a while ago for myself and then > forgot about it: the "This page uses the NON-STANDARD meta refresh > tag..." warning usually occurs inside <head>, but is immediately > sent to the parser, which in turn switches its HTML processing state > from IN_HEAD to IN_BODY prematurely. After that, head-only tags like > <title> and <base> are ignored. A minimal fix is at the end of the > mail. Done. -- Cheers Jorge.-

Oct. 15, 2004

[Dillo-dev]Crash on fast reload for dpi pending...

by Jorge Arellano Cid

Hi there, Please note that hitting reload as a mad man over a dpi-handled URL can crash Dillo. This happens because currently there's no code to account for this case (as there is for the HTTP branch). Thinking about it, there's a possibility of merging the CCC branches into a couple of generic and very powerful ones (much like what the dpi is now). If this design is possible, and succeeds, it would mean much simpler handling of IO, the elimination of a lot of complexity, more stability (all the data would use it and thus be more tested). I'll give it some thought. Not for the next release though... :-) -- Cheers Jorge.-

Oct. 14, 2004

Re: [Dillo-dev]dillo-0.8.3-rc1.tar.bz2: bug

by Jorge Arellano Cid

On Wed, Oct 13, 2004 at 02:01:01PM +0200, Matthias Franz wrote: > On Tue, Oct 12, 2004 at 12:49:21PM -0300, Jorge Arellano Cid wrote: > > Well, I've devoted several days to this BUG. > > Dear Jorge, > > the time and energy you have been spending on this bug shows me > how much you are dedicated to high quality software. > > Thanks a lot! > > PS: Once you have a bugfix, I'd be happy to test it. A patch is in the CVS! Finally I figured it out: there were two race conditions, one on closing the write end of the socket (the easy one) and another on the thin time-slice between server FD close and the IO watch for it being scheduled inside Dillo. The problem was very hard to spot as it wasn't on a variable shared explicitly among threads, but on a file descriptor. If somewhere inside the above mentioned time-slice, Dillo requested for a new FD and the kernel noticed, and decided to reuse the FD, then there were problems. I say there were problems because the data transfer had a good chance to succeed on a fascinatingly wicked way! (covering up the BUG). The patch makes changes in several places, the most interesting of them being the threads list being sorted by a primary key other than the FD (this allows handling the CCCs for both, the just closed and the just openned one). I left the thread list's debug messages for checking purposes. If you see two identical FDs in the list, that was the bug (handled now). It worked OK on all my tests for the file dpi server and also for the file dpi filter. I left the dpi server option as default because it spawns less processes. If you want to test the file filter dpi, just compile dillo and run from the command line. To test the file dpi server, do a: make install-strip and remove, or 'chmod -x', the file.filter.dpi. (usually /usr/local/lib/dillo/dpi/file/file.filter.dpi). ... and tell us how it works. -- Cheers Jorge.-

Oct. 14, 2004

Re: [Dillo-dev]dillo-0.8.3-rc1.tar.bz2: bug

by Matthias Franz

On Tue, Oct 12, 2004 at 12:49:21PM -0300, Jorge Arellano Cid wrote: > Well, I've devoted several days to this BUG. Dear Jorge, the time and energy you have been spending on this bug shows me how much you are dedicated to high quality software. Thanks a lot! PS: Once you have a bugfix, I'd be happy to test it. -- Matthias Franz Section de Mathématiques, Université de Genève, Suisse

Oct. 13, 2004

[Dillo-dev]Webmails compatibility with Dillo 0.8.3rc1

by Florent BERANGER

Hi, Here a little test result about webmails compatibility : Read Compose Horde : ok nok Squirrel : ok ok -> you just have to select a frame and it's ok:) Tiscali : nok nok Ms hotmail: nok nok Google gmail: nok nok Yahoo mail: nok nok Best regards, Florent ************************ ADSL ILLIMITE TISCALI + TELEPHONE GRATUIT ************************ Surfez 40 fois plus vite pour 30EUR/mois seulement ! Et téléphonez partout en France gratuitement, vers les postes fixes (hors numéros spéciaux). Tarifs très avantageux vers les mobiles et l'international ! Pour profiter de cette offre exceptionnelle, cliquez ici : http://register.tiscali.fr/adsl (voir conditions sur le site)

Oct. 12, 2004

[jcid@dillo.org: Re: [Dillo-dev]Caching]

by Jorge Arellano Cid

Hi, Here's an email that I mistakenly replied personally instead of to dillo-dev. -- Cheers Jorge.-

Oct. 12, 2004

Re: [Dillo-dev]dillo-0.8.3-rc1.tar.bz2: bug

by Jorge Arellano Cid

On Wed, Oct 06, 2004 at 01:52:40PM +0200, Matthias Franz wrote: > Hi everybody, > > the rendering is really much better in the 0.8.3 version. Well done! > > Unfortunately, I'm experiencing problems with the new version that > I've never had with 0.8.2: > > 1. Dillo displays a page without the embedded GIF image, showing the > alternate text instead. It starts consuming all cpu time, but still > responds to keyboard and mouse input (history navigation; no new pages > are displayed). > > 2. Dillo doesn't display a page at all. Cpu/input behaviour as before. > > The problems only occur with certain local files, not http pages. > Moreover, they don't occur deterministically. They seem to happen > somewhat more often if one follows a link instead of loading a page > from the command line. > [...] Well, I've devoted several days to this BUG. It's one of the hard kind to find and fix. It has to do with race conditions due to threading and communication with external processes. Sometimes it shows, some others not. I'm very advanced on it. Porting the file dpi to a dpi server helped me to reproduce the bug (and to discard the multiple random scheduled external processes as the root of the problem). I know the exact line where it crashes, and I'm in the process of trying to understand how it gets there. Shall "the force" be with me, a bug fix may come soon! :-) -- Cheers Jorge.-

Oct. 12, 2004

Re: [Dillo-dev][illegal content type in doc/Dpid.txt]

by Diego Sáenz

Sorry. If it is for me, i do not write that example. And it is true, the example send "text" instead "text/plain" as content type Diego/DarkSpirit. El Fri, 8 Oct 2004 09:26:23 -0400 Jorge Arellano Cid <jcid(a)dillo.org> escribio: > Hi, > > Diego, IIRC you wrote the below mentioned example. Please give > it a review. > > -- > Cheers > Jorge.- >

Oct. 10, 2004

Re: [Dillo-dev]which version does this patch file patch

by Riccardo Mottola

"Linda J. Laubenheimer" wrote: > I'm not a C programmer, otherwise I'd fix it and send it to you. > > > > Believe me, there's nothing to fix. Just install both gtk+-1 and > > gtk+-2 and live happily ever after. I did! > > Not going to happen. I stated, I thought clearly, that this was an > embedded project. You can't just go willy-nilly installing extra > libraries because an application only compiles against version 1, but > not version 2. The rest of the items in the project are compiled > against gtk2. So yes, in order to use Dillo, it would need to be fixed > to be compiled against glib2 and gtk2, because just installing another > set of libraries is not an option. well, I wouldn't use the bloat of gtk2/glib2 in an embedded system and I hope dillo stays gtk1, which is faster, more portable and consumes less resources (and besides,muchmore portable across different operating systems). I could rephrase saying that it is your problem using gtk2! Of course you have choosen your tools and libraries in your project... Personally I hope the independence of the dillo core will enable to port it to different UIs and different toolkits (think of motif or fltk or even other, fast toolkits) instead of binding us to gtk. Of course you can object that gtk2 is actively developed and gtk1 not, but I really agree with other saying here that the two are quite "different" beasts. Just my 2 cents, -R

Oct. 10, 2004

Re: [Dillo-dev]Caching

by Brian Hechinger

On Wed, Oct 06, 2004 at 09:37:48AM -0400, Jorge Arellano Cid wrote: > > It'd be good to have a way to control caching. Unfortunately > not for the next release. It has its complexities that need > careful design and time. > > We're sorting a large task list by priorities now with > Sebastian. I'd say in advance we'd need a volunteer developer to > look on this topic. We're far surpassed by the amount of work. ok, i will volunteer to do the caching portion. i need to finish reading Cache.txt and pick through capi.c and cache.c a bit more, but before i know everything i should know, here is what i'm planning so far: we go into cache.c as normal, if the page isn't cache, we initiate the connection and cache the page as normal. the only difference is now we search the header for the Pragma: no-cache meta tag. if we find it, we set a flag (i'm assuming Url->flags is a vector?) in the cache entry. the next time we go to that page, since it's in the cache, the first thing we check is for that no-cache flag. if it exists, we look at nocacherc (which will be structured exactly like cookiesrc) and if we have an ACCEPT match there, we simply behave as if the item doesn't exist in cache. does this sound like the proper way to do it to you guys? also, what is the proper no-cache system to honor? the Pragma meta tag? or is there something else we should look for? i'm not completely up on my HTML standards quite yet. -brian -- "The cats tend to administer themselves, and contrary to the expected facts, the house and everything in it was installed for their benefit." -- Nic Clews

Oct. 9, 2004

Re: [Dillo-dev]Starting with a blank page

by Jorge Arellano Cid

On Fri, Oct 08, 2004 at 11:57:02AM +0300, Joonas Saarinen wrote: > With 0.8.2 I could use "file:/dev/null" as start_page to begin with a blank > page. However, it seems that using the same trick with 0.8.3-rc1 leads Dillo > to complain that it "can't start dpid daemon". Should this be fixed or should > there rather be something like "about:blank" to start with an empty page? Try setting "start_page in dillorc. e.g.: start_page="file:/home/user/custom.html" -- Cheers Jorge.-

Oct. 8, 2004

[Dillo-dev][illegal content type in doc/Dpid.txt]

by Jorge Arellano Cid

Hi, Diego, IIRC you wrote the below mentioned example. Please give it a review. -- Cheers Jorge.-

Oct. 8, 2004

Re: [Dillo-dev]dillo-0.8.3-rc1.tar.bz2: bug

by Jorge Arellano Cid

On Wed, Oct 06, 2004 at 01:52:40PM +0200, Matthias Franz wrote: > Hi everybody, > > the rendering is really much better in the 0.8.3 version. Well done! > > Unfortunately, I'm experiencing problems with the new version that > I've never had with 0.8.2: > > 1. Dillo displays a page without the embedded GIF image, showing the > alternate text instead. It starts consuming all cpu time, but still > responds to keyboard and mouse input (history navigation; no new pages > are displayed). Yesterday I was able to reproduce this. Attaching gdb to the process showed that the CPU hog is produced outside Dillo's code (between gtk and glib with intermediate calls to libc). This most probably is an IO watch without its callback. Not an easy to debug sceneray, but at least a starting point. -- Cheers Jorge.-

Oct. 8, 2004

Re: [Dillo-dev]Invoke application upon clicking a link

by Diego Sáenz

I think i have an easier solution than that. First install the exec dpi that i atach. Read the dpi spec in dillo page for more info. Then use links to dpi:/exec/dillo to start dillo or dpi:/exec//usr/local/bin/dillo to start /usr/local/bin/dillo. With this dpi you can not pass parameters. If you make it understand %20 in the url passed, so commands can have parameters, please send the cahnges. Diego/DarkSpirit El Fri, 8 Oct 2004 12:08:05 +0200 Matthias Franz <Matthias.Franz(a)ujf-grenoble.fr> escribio: > On Fri, Aug 20, 2004 at 09:05:13PM -0700, huy wrote: > > I would like to be able to click on a link and invoke a local executable. > > [...] > > Is there a way I can do this with dillo (short of modifying the source code). > > Dear huy, > > using the external viewers patch (see my posting to this list) and > the Dillo dpi framework, there is a short solution to your problem: > > Save the attached shell scipt to ~/.dillo/dpi/runcmd/runcmd.filter.dpi > and put the line > > application/x-runcmd; %{cmd} > > into your ~/.mailcap . Then any link of the form "dpi:/runcmd/prog" starts > the program "prog". > > See the Dillo file doc/Dpid.txt for more on (filter) plugins. > > > security isn't an issue > > I hope so since otherwise you'd better forget all this! > > All the best, > -- > Matthias Franz > > Section de Mathématiques, Université de Genève, Suisse >

Oct. 8, 2004

Re: [Dillo-dev]Invoke application upon clicking a link

by Matthias Franz

On Fri, Aug 20, 2004 at 09:05:13PM -0700, huy wrote: > I would like to be able to click on a link and invoke a local executable. > [...] > Is there a way I can do this with dillo (short of modifying the source code). Dear huy, using the external viewers patch (see my posting to this list) and the Dillo dpi framework, there is a short solution to your problem: Save the attached shell scipt to ~/.dillo/dpi/runcmd/runcmd.filter.dpi and put the line application/x-runcmd; %{cmd} into your ~/.mailcap . Then any link of the form "dpi:/runcmd/prog" starts the program "prog". See the Dillo file doc/Dpid.txt for more on (filter) plugins. > security isn't an issue I hope so since otherwise you'd better forget all this! All the best, -- Matthias Franz Section de Mathématiques, Université de Genève, Suisse

Oct. 8, 2004

[Dillo-dev]external viewers patch

by Matthias Franz

Hi everybody, I have extended Lars Clausen's external viewers patch and ported it to Dillo 0.8.3. While it is still under development (it doesn't use the dpi framework yet), it is already a stable and essentially complete implementation of RFC 1524, and at least to me Dillo is much more useful if it can display PS and PDF files, for instance. If you are interested, you can download the patch at http://www-fourier.ujf-grenoble.fr/~franz/dillo/ . Comments are welcome! All the best, -- Matthias Franz Section de Mathématiques, Université de Genève, Suisse

Oct. 8, 2004

[Dillo-dev]Starting with a blank page

by Joonas Saarinen

With 0.8.2 I could use "file:/dev/null" as start_page to begin with a blank page. However, it seems that using the same trick with 0.8.3-rc1 leads Dillo to complain that it "can't start dpid daemon". Should this be fixed or should there rather be something like "about:blank" to start with an empty page?

Oct. 8, 2004

[Dillo-dev]about gtk2.diff.gz

by Calvin Yu

I used this patch file, tried dillo-0.7.3 and dillo-0.8.0. But when they were patched, both of them occured errors. Is there another version between 0.7.3 and 0.8.0 that can be patched with gtk2.diff.gz exactly. Who can send me that version, i just want to have a test. i will be very grateful for your help. My mail box is yuzenghui(a)people.com.cn Or yuzenghui(a)hotmail.com Thank you!!

Oct. 8, 2004

Re: [Dillo-dev]testing dillo-0.8.3-rc1

by Bjoern Brill

On Thu, 7 Oct 2004, Jorge Arellano Cid wrote: > On Wed, Oct 06, 2004 at 03:47:32PM +0200, Bjoern Brill wrote: [...] > > > > > Two small problems I've encountered: > > > > - It seems that, if a pair of <a href="..."> </a> tags contains > > something illegal, like <div>, then the <a> tags are ignored, > > rather than the illegal stuff inside. That's suboptimal. > > Can you elaborate on "suboptimal"? > If a heuristic tries to repair broken stuff, then the repair method with the likely most useable result is optimal. As things are now, <a><div>click here</div></a> ends up as <a></a><div>click here</div>, i.e. the link is empty and thus inaccessible. > The reason why <a> is closed is that INLINE elements can't > contain BLOCK elements, so any inline elements left open are > closed. This cleanup has proven very healthy. > [...] Yes, I fully agree here. My point is just that, since no visible trace of <a> is left, and links are a rather important part of page contents, another cleanup method may be better in this case. > > > As an example, look at http://www.kmelektronik.de/ (admittedly a very > > broken site, standards-wise). The text fragments "Light-Version > > Versand" and "Light-Version Shop" near the page bottom should really > > be links. If this is hard to fix, then don't bother. > > Yes. The only other site I've found is www.lynucs.org which I > expect to correct the problem when told. > > I tried a small hack, but it has the side effect of not > cleaning-up any INLINE element upon <div> openings. This solves > the problem with the above mentioned pages, but may create bigger > problems than what it solves. > [...] > Maybe a good solution is to only allow an exception when <a> > precedes the <div>. This would be much safer. > > Of course it would'n work with <a ...><b><div> </div></b></a>. > > Now, considering the small amount of sites doing this, it may > be an overkill. Please share your thoughts. > What about this: before forcibly closing <a> (no matter why), render some text like "[...]" or "[HTML bug]" to the page, so that the user can see what's going on? Special-casing <a><div> would likely be overkill. Special-casing <a><block_element> would not be, as long as the workaround is easy, simple and reasonably safe. If such a workaround does not exist, the issue isn't really worth more effort. Regards, Björn -- Bj"orn Brill <brill(a)fs.math.uni-frankfurt.de> Frankfurt am Main, Germany

Oct. 7, 2004

[Dillo-dev][sylvinus@lynucs.org: Re: Easy to solve problem in the HTML]

by Jorge Arellano Cid

Hi there, This is what you MUST expect from a good webmaster! -- Cheers Jorge.-

Oct. 7, 2004

Re: [Dillo-dev]testing dillo-0.8.3-rc1

by Jorge Arellano Cid

Björn, I commited a commented workaround to CVS (alongside with an enhancement for the color choosing algorithm for visited links). If you want to test it, get into html.c:4394 and uncomment the code there. -- Cheers Jorge.-

Oct. 7, 2004