- Dillo-dev - lists.mailman3.com

[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