- Dillo-dev - lists.mailman3.com

Re: [Dillo-dev]Memory leak bug (was dillo-0.8.3)

by brownh＠hartford-hwp.com

I've tried to get myself unsubscribed to this list (to which someone kindly subscribed me without my knowledge or permission), by emailing the admistrator, but it seems my letter ended up on hold somewhere. Would somone kindly suggest an alternative method for me to unsubscribe? There's no facility on the web page for doing so. Haines Brown

Oct. 29, 2004

Re: [Dillo-dev]meta refresh patch for 0.8.2

by Jorge Arellano Cid

Hi Brian, Sorry for the delayed answer, I had a lot of work with the release and now I'm trying to catch up. On Thu, Oct 28, 2004 at 12:17:29PM -0400, Brian Hechinger wrote: > On Thu, Oct 28, 2004 at 04:20:29PM +0200, Diego S?enz wrote: > > What is the difference between CACHE_ACCEPT and CACHE_ACCEPT_SESSION? > > nothing, i just wanted to keep the code as identical to the original cookie > version for now until it is decided what is going to be done with that hunk > of code. Cookies will most probably end being a dpi server (to solve the problem of enabling cookies in multiple Dillo instances). This was planned long ago and hasn't been realized because of lack of manpower (aka priorities :-). The configuration data problem (cacherc, cookiesrc, dillorc, <dpi-name>rc) is also a general issue that we're considering with Sebastian. Maybe it will all end in a generic preferences dpi; this needs some further thought. Soon a prioritized task list will be available in dillo-dev (I just sent back a good draft to Seb.). This account for what we, the core developers, will be doing the next months. The good news is that tasks that get lower priorities can be advanced by the interested volunteers. Please stay tuned, we're trying to cope with all the work we have, by organizing the work. The cache issues intersect with SSL (needs cache control), preferences handling, cookies dpi server, and the universal CCC branch idea). When the commented task list is posted, you'll get the idea. -- Cheers Jorge.-

Oct. 29, 2004

[Dillo-dev]Proper XHTML (was Re: dillo patch: anchor names)

by Kelson Vibber

Jorge Arellano Cid wrote: > BTW, it's hard to find a site that serves XHTML as > "application/xhtml+xml", that's not intended for testing. I think within the web design/web standards blogging community, you're more likely to find them. There was a "hall of fame"-type list someone did a while back, though I can't remember what it was called or where it was. Wordpress generates valid XHTML by default and sends it as text/html -- but some of the more standards-zealous and/or technically-inclined WP users have modified their sites to send the proper mime type when appropriate. (I haven't since I still don't quite trust user-supplied text not to break the XHTML -- but several sections of my site do.) Also, XHTML sites are going to be hard to find with a browser that doesn't support it, because most sites that *do* use the proper mime type use content negotiation to decide which mime type to send. This is the only way to keep the site visible to HTML-only browsers like that IE thing some people still use ;-). So unless your UA's HTTP Accept: header includes application/xhtml+xml, it won't see many sites using that mime type. > Maybe a partial validation can serve the standards compliance > objective. I mean, for instance: proper nesting, lowercase tags, > tag names in the XHTML namespace. Not much more than that. I don't recall exactly what the spec states, but from experience with Gecko browsers the main issue with broken XHTML appears to be with pages that aren't *well-formed*. So tossing in an unfamiliar attribute may break validation, but it's still well-formed XML (all tags nested and closed properly, including <img/>, <br/>, <meta/>, etc.) so the page will still display. The main errors I've noticed Mozilla complaining about are misnesting, missing closing tags, and undefined character entities. On a related note: is there a reason Dillo doesn't send an Accept: header? I'd think that something basic like "text/html, image/png, image/jpeg, image/gif, text/plain;q=0.9" with an optional ", */*;q=0.1" at the end would be about right. -- Kelson Vibber www.hyperborea.org

Oct. 29, 2004

Re: [Dillo-dev]Memory leak bug (was dillo-0.8.3)

by Roberto A. Foglietta

Jorge Arellano Cid wrote: > On Wed, Oct 27, 2004 at 07:58:36PM +0100, robert w hall wrote: > >>In article <417FCFE6.8040306(a)sad.it>, Roberto A. Foglietta >><roberto.foglietta(a)sad.it> writes >> >>>[...] >>>Sorry to inform you but v0.8.3 (far from, at least v0.8.2) has a >>>memory leak bug. >>> >>>Clicking on reload button used memory increase around 4kb for each >>>click. Stop clicking make used memory increasing stop too. So increase >>>memory size of dillo depends on reloads but not following links. >> >> >>Hmm - could this be distro/kernel dependent? > > > I don't think so. > > On the same machine, my testing shows no leak with 'http', but > leaks with 'file' and 'hello'. It looks like a leak in the dpi > branch. I'm working hard on it but it'very difficult... ...IMHO could be a_Web_free(web); in a_Capi_url_uses_dpi because moving out of that function the free (who make malloc, make free - policy) I see a lot of strange behaviure e segmentation fault in about:splash. The reason is because not all pointer freed are immediately set to NULL value. 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. 29, 2004

Re: [Dillo-dev]Memory leak bug (was dillo-0.8.3)

by Jorge Arellano Cid

On Wed, Oct 27, 2004 at 07:58:36PM +0100, robert w hall wrote: > In article <417FCFE6.8040306(a)sad.it>, Roberto A. Foglietta > <roberto.foglietta(a)sad.it> writes > > [...] > > Sorry to inform you but v0.8.3 (far from, at least v0.8.2) has a > >memory leak bug. > > > > Clicking on reload button used memory increase around 4kb for each > >click. Stop clicking make used memory increasing stop too. So increase > >memory size of dillo depends on reloads but not following links. > > > Hmm - could this be distro/kernel dependent? I don't think so. On the same machine, my testing shows no leak with 'http', but leaks with 'file' and 'hello'. It looks like a leak in the dpi branch. Does anyone know whether g_mem_profile can help to track this down? -- Cheers Jorge.-

Oct. 29, 2004

Re: [Dillo-dev]news about memory leak

by Roberto A. Foglietta

Riccardo Mottola wrote: > Hey, > > I am on a NetBSD/ppc system. DIllo 0.8.3 and can reproduce the leak. I > noted however that: > > - clicking the reload button in thight succession gets an increment of > about 4K every time > - the leak is consitent, you can make the amount of leaked memory > skyrocket to megabytes. > - clicking slowly, waitning 10 seconds each time does NOT make dillo > leak > > I suspect the leak happens if you click reload before dillo has > "finished" the page and the "stop button" is disabled. > What is the best way to check if a page has been load completely? I mean checking BrowserWidows or DilloUrl structures... 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. 29, 2004

Re: [Dillo-dev]Protocol Handlers

by Jorge Arellano Cid

Hi, On Thu, Oct 28, 2004 at 04:07:06AM -0230, Lee Bigelow wrote: > Hello there, I was playing with the dpi's and > made one for ed2k:// links (based on the Hello > World example). It was just a quicky, and not > generally useful, but I was wondering if anyone > was working on a general protocol handler. This is a good idea and some prototypes have been tried in the past. It'd be very good to implement this as a dpi. Please read: http://lists.auriga.wearlab.de/pipermail/dillo-dev/2004-October/002278.html and ask Matthias (and Lars IIRC). If you're interested I can answer/develop/help with the dpi part. > > Along these lines: > > - Dillo doesn't recognize the protocol so sends it > to say external.dpi > > - external.dpi reads an external.conf file that > has a list of protocols and respective > external handlers. > > - If it finds a matching protocol it sends > the url(%s), or just the url data (%r), to > the handler. > > - If there's no matching > protocol it could show an edit page (like > bookmarks modify) for the external.conf. > > This could be used for mailto:, nntp:, telnet:, > etc.. > > Anyhow, I starting playing with it, and I > thought I should check to see if anyone else was > also working on it before I went any further. > > Also, if there's any advice on the approach, or > code I should look at, that would be cool. I am > no expert C programer, I'm just reading the docs > and modifying the code the other fellows already > did. (I hope that's ok) Yes, that's OK, and good for the project. :-) -- Cheers Jorge.-

Oct. 28, 2004

[Dillo-dev]CYGWIN compatibility

by Jorge Arellano Cid

Hi, Sometime ago I forwarded this message to dillo-dev: http://lists.auriga.wearlab.de/pipermail/dillo-dev/2004-October/002295.html <q> Hi anyone, I successfully compiled and installed dillo-0.8.2 on an AMD K7 600MHz: $ uname -a CYGWIN_NT-5.0 fermat 1.5.11(0.116/4/2) 2004-09-04 23:17 i686 unknown unknown Cygwin It runs very well, so you can update your compatibility file ;) Greetings, Marianne </q> Has anyone contacted Marianne to know the recipe? -- Cheers Jorge.-

Oct. 28, 2004

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

by Jorge Arellano Cid

Matthias, Please excuse me for the delayed answer. I had a hard time fixing release candidates for the dillo-0.8.3 release... On Tue, Oct 19, 2004 at 12:03:17PM +0200, Matthias Franz wrote: > Hi Richard, > > thanks for your comments! Yes, very interesting. > > 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. Could be... As the suggested document explains, there's not a big gain in serving XHTML as such, and nowadays most of it is served as "text/html". BTW, it's hard to find a site that serves XHTML as "application/xhtml+xml", that's not intended for testing. In our case the "detection" was just to try to provide a hintful HTML/XHTML warning. The easy solution is not to raise a warning or to send it to extra warnings ;). What worries me a bit more is what to do with XHTML served with the proper MIME type. Currently it's not rendered at all, though Dillo can perfectly cope with it. The reason is that the XHTML SPEC requires a validating client, and as Dillo doesn't include a formal XML parser this is not possible. Today this is not a problem because such sites are very seldom found. Maybe a partial validation can serve the standards compliance objective. I mean, for instance: proper nesting, lowercase tags, tag names in the XHTML namespace. Not much more than that. Perhaps MIME type detection, plus some doctype sniffing (to have "an idea" of whether we are dealing with HTML 2.0, 3.2, 4.0, 4.1 or XHTML), and having that information in a structure like the one suggested in the former mail could serve to fine tune a bit the warning messages (or parser behaviour). For instance having that info, in the case of anchor names can lead to something as simple as: if (!isalpha(val[0]) && doctype == DOCTYPE_XHTML) MSG_HTML("first character of '%s' value is outside" " the [A-Za-z] set\n", attrname); Just make the patch with comment where this messages should go. With the fuzzy detection code in place it'll be a matter of binding. Not the highest priority, but easy to merge. -- Cheers Jorge.-

Oct. 28, 2004

Re: [Dillo-dev]meta refresh patch for 0.8.2

by Brian Hechinger

On Thu, Oct 28, 2004 at 04:20:29PM +0200, Diego S?enz wrote: > What is the difference between CACHE_ACCEPT and CACHE_ACCEPT_SESSION? nothing, i just wanted to keep the code as identical to the original cookie version for now until it is decided what is going to be done with that hunk of code. -brian -- IHTFP: I firmly believe that people dumber than me exist solely for my amusement. IHTFP: Okay, maybe not solely for my amusement. Some of them make good cake.

Oct. 28, 2004