October 2004 - Dillo-dev - lists.mailman3.com

[Dillo-dev]Is dillo-dev back? (test mail)
by Jorge Arellano Cid 18 Oct '04

18 Oct '04

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

1 0

[Dillo-dev]anchors_table not cleared
by Matthias Franz 15 Oct '04

15 Oct '04

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

2 2

[Dillo-dev][marianne@mathematicians.de: Compatibility]
by Jorge Arellano Cid 15 Oct '04

15 Oct '04

-- Cheers Jorge.-

1 0

[Dillo-dev]testing dillo-0.8.3-rc1
by Bjoern Brill 15 Oct '04

15 Oct '04

Hello, I've tried out dillo-0.8.3-rc1 for a few days on a Debian GNU/Linux 3.0 "woody"/i386 system. It compiled and installed cleanly, and I did not encounter any regressions against 0.8.2 yet. The parser changes are a real improvement -- several formerly problematic sites I've tried work now, and the "Detected HTML errors" view produces much more meaningful results. 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. 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. - 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. Best regards, Björn Brill -- Bj"orn Brill <brill(a)fs.math.uni-frankfurt.de> Frankfurt am Main, Germany --- dillo-0.8.3-rc1/src/html.c.orig Tue Sep 21 17:42:12 2004 +++ dillo-0.8.3-rc1/src/html.c Tue Oct 5 19:21:42 2004 @@ -3101,7 +3101,11 @@ static void Html_tag_open_meta(DilloHtml /* Send a custom HTML message */ html_msg = g_strdup_printf(meta_template, content, delay_str); - Html_write_raw(html, html_msg, strlen(html_msg), 0); + { + DilloHtmlProcessingState SaveFlags = html->InFlags; + Html_write_raw(html, html_msg, strlen(html_msg), 0); + html->InFlags = SaveFlags; + } g_free(html_msg); } }

2 4

[Dillo-dev]Crash on fast reload for dpi pending...
by Jorge Arellano Cid 14 Oct '04

14 Oct '04

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

1 0

[Dillo-dev]dillo-0.8.3-rc1.tar.bz2
by Jorge Arellano Cid 14 Oct '04

14 Oct '04

Hi there, The release of dillo-0.8.3 is very close now. Today I prepared the release candidate tarball for it. Please test and send some feedback; the last request for feedback on the CVS had a single answer. !? Get rc1 from: http://www.dillo.org/download/dillo-0.8.3-rc1.tar.bz2 It should be out in early September. -- Cheers Jorge.-

4 10

[Dillo-dev]Webmails compatibility with Dillo 0.8.3rc1
by Florent BERANGER 12 Oct '04

12 Oct '04

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)

1 0

[jcid@dillo.org: Re: [Dillo-dev]Caching]
by Jorge Arellano Cid 12 Oct '04

12 Oct '04

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

1 0

[Dillo-dev][illegal content type in doc/Dpid.txt]
by Jorge Arellano Cid 10 Oct '04

10 Oct '04

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

2 1

RE: [Dillo-dev]which version does this patch file patch
by Linda J. Laubenheimer 10 Oct '04

10 Oct '04

> -----Original Message----- > From: dillo-dev-admin(a)lists.auriga.wearlab.de > [mailto:dillo-dev-admin@lists.auriga.wearlab.de] On Behalf Of > Jeremy Henty > Sent: Tuesday, October 05, 2004 1:18 AM > To: dillo-dev(a)lists.auriga.wearlab.de > Subject: Re: [Dillo-dev]which version does this patch file patch > > On Mon, Oct 04, 2004 at 11:37:33AM -0700, Linda J. Laubenheimer wrote: > > > *Headdesk* So that's why it won't compile with glib2 and gtk2. It > > always ended up linking against libmodule 1.2, libglib 1.2, etc., > > Yes. Despite the names, gtk+-1 and gtk+-2 are different > libraries. You can't build against one and link against the > other, any more than you can build a KDE app and expect it to > link against GNOME. Which is why I tried to build it against gtk2. > > Oh, well, no Dillo on my thin box. > > Why not? Gtk+-2 is designed to work alongside gtk+-1 with no > problems. I have had them both installed for a couple of > years, running dillo and other gtk+-1 and gtk+-2 > applications. It's all worked out of the box with no problems. One word: space. When you are working on embedded systems with limited space, you have to chose your libraries carefully, not pile in double libraries that are just slightly different. > > If you have to install two versions of a library, you've done > > something wrong. > > I agree, but that doesn't apply here. Gtk+-1 and gtk+-2 are > *different* libraries. Since no application built against > one of them will even look at the other there's no problem. > Version hell only happens when an application can link > against more than one library on your system and runs the > risk of picking the wrong one. The design of > Gtk+-2 ensures that this won't happen. Technically, two version of a library are different libraries. The fact is, when you have to pick which one of two similar libraries to include, just adding the second isn't an option. We're talking about fitting everything, including printing, on a 32M or 64M flash, and every redundancy counts against you. The whole idea behind looking at Dillo is to obtain a nicely featured browser with a small disk footprint. > > 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. ljl

4 3