- Dillo-dev - lists.mailman3.com

memory use

by jcid＠dillo.org

Hi, On Fri, Mar 27, 2009 at 02:05:23PM -0600, Scott Scriven wrote: > * Jorge Arellano Cid <jcid(a)dillo.org> wrote: > > BTW, it'd be good to have some memory usage data for dillo-2.1. > > A while ago, I noticed that dillo was using a lot of memory on a > specific page, and I didn't remember it doing that before. So I > tested a few versions and found that dillo2 uses more memory > initially, but less memory for large tables. Specifically: > > Memory use (in KiB) (on ubuntu 7.10 x86_64) > dillo-0.8.6/src/dillo: > 3692 file:///nothing > 4900 http://dillo.org/ > 45204 http://idlerpg.net/db.php > dillo-2.0/src/dillo: > 4700 file:///nothing > 6564 http://dillo.org/ > 36408 http://idlerpg.net/db.php > hg/dillo/src/dillo: > 4812 file:///nothing > 6684 http://dillo.org/ > 36756 http://idlerpg.net/db.php > > > Note: I remmeber having an awful memory footprint on 64bit > > Ubuntu. It didn't happen with 32bit. What's the current status, > > I don't know. > > I have both 64-bit and 32-bit ubuntu systems here, if you need > measurements. For example, I tried the above on my 32-bit box: > > Memory use (in KiB) (on ubuntu 8.04 i686) > dillo-0.8.6/src/dillo: > 4916 file:///nothing > 6504 http://dillo.org/ > 36824 http://idlerpg.net/db.php > dillo-2.0/src/dillo: > 3972 file:///nothing > 5732 http://dillo.org/ > 25144 http://idlerpg.net/db.php > hg/dillo/src/dillo: > 4036 file:///nothing > 5760 http://dillo.org/ > 25296 http://idlerpg.net/db.php Yes, 64bit uses more memory. I've collected the following numbers: (Ubuntu 8.10, 32bit) dillo-2.1: VSZ RSS COMMAND 8148 3872 ./dillo (empty) 26936 19196 ./dillo DragonFly.html (1.1MB HTML) 178684 174620 ./dillo MySQL-6.0.html (13MB HTML) 119788 113096 ./dillo MySQL-6.0.html (no IMG) f=7.2 dillo-0.8.6 VSZ RSS COMMAND 16592 3960 ./d086 83784 35748 ./d086 DragonFly.html (1.1MB HTML) 357320 293796 ./d086 MySQL-6.0.html (13MB HTML) 297224 234344 ./d086 MySQL-6.0.html (no IMG) f=16.3 firefox-3.0.8 VSZ RSS COMMAND 100884 37572 ./firefox 123184 59688 ./firefox DragonFly.html (1.1MB HTML) 312652 241016 ./firefox MySQL-6.0.html (13MB HTML) 328352 237560 ./firefox MySQL-6.0.html (no IMG) f=15 The 13MB page can be found at: http://dillo.org/test/mysql-6.0.doc.tar.bz2 The 1.1MB page can be found at: http://dillo.org/test/DragonFly.html.bz2 This numbers are the basis to claim that dillo2 uses half the memory footprint of dillo1. The "f" factor is the RSS for the MySQL manual (with no images), minus the empty RSS, minus 13MB, all divided by 13MB. The memory-cached page is substracted to get a clean HTML to Widgets factor. This is, if you have a 130KB html page, f*130KB will be used for rendering. It'd be good to have some wall-clock numbers too. Then the data can be tabulated and shown in the web site. Suggestions are highly welcomed. The VSZ and RSS numbers come from ps. I don't know of a better way to measure memory usage. The general idea is to have reproduceable numbers that show how dillo differs in memory and speed with other browsers. -- Cheers Jorge.-

April 21, 2009

towards a dillo-2.1 release

by jcid＠dillo.org

Hi there, It'd be very good if we can complete these points for the 2.1 release. Listed in no particular order: 1.- Dw documentation: online and as tarball. We have good docs. but to generate them there's a need to have: doxygen, graphviz, dot, latex and friends. That's why having it online and as a tarball is a good idea. 2.- Mapcity segfault In www.mapcity.cl playing with the "Tipo Calle" while the page is loading makes dillo segfault. If "Remote CSS" is disabled, it doesn't happen (also OK in dillo-2.0). 3.- New web site design We have a new banner and after finding a good color palette it may be ready to renew the site before 2.1 is announced. 4.- Debian/Ubuntu packages (after 2.1 final is ready) 5.- Update "8 years" page (it's nine) Yes, I should have done it already... 6.- Configurable key bindings. I'm reviewing this with Tim. Hopefully it will make it into the 2.1 release. 7.- Memory usage statistics Scott has posted some data on this, in another thread. I'll answer there. I'd be working on 5, 6 and 3. Volunteers please assign yourselves to the pending points. BTW, if you have important points to add to the list, please say so. Of course any segfaults or regressions have high priority too. TIA. -- Cheers Jorge.-

April 20, 2009

[Patch 2/4] Refactoring src/prefs.c and src/dir.c

by tim.nieradzik＠gmx.de

> What's the main point of dParser_parse_rc_line()? The main difference to the current implementation is that equal signs are interpreted as separator. Besides, it requires that ``line'', ``name'' and ``value'' are initialised with a specific length (in dpid/dpid.c it is set to 1024). The major advantage is that corrupt files (with very long lines) would not congest the RAM since we abort after 1024 characters. This is very unlikely though. > The comment says it extracts type, name and value, but it doesn't > extract type. Sorry, I had forgotten to update the description. In a previous version of my patch there has been a ``type'' attribute. As proposed, I removed it later on. Since then this function does basically the same job as dParser_get_rc_pair(). --Tim

April 20, 2009

[Patch 2/4] Refactoring src/prefs.c and src/dir.c

by jcid＠dillo.org

Hi Tim, On Fri, Apr 10, 2009 at 03:23:12PM +0000, Tim Nieradzik wrote: > This patch cleans up src/prefs.c and introduces the PrefsParser > (src/prefsparser.cc). With this patch I hesitate. What's the main point of dParser_parse_rc_line()? The comment says it extracts type, name and value, but it doesn't extract type. It introduces the need for separate buffers to copy the values, and more or less does the same. Please give some examples of the needed funcionality over the current implementation. -- Cheers Jorge.-

April 20, 2009

Instant client-side redirects (META refresh with delay=0)

by jcid＠dillo.org

Hi there, Please excuse me for being silent. Life has poured a few other important things to do over me (e.g. next week I have to move to another apartment). A patch for Instant client-side redirects is fresh in the repo. It took some time to develop because the whole idle/timeout mechanism needs a new API that allows to cancel queued functions. I didn't change the old API (the next release will keep it) but took some time to analyze and it may help with the redraw issue Johannes worked with, and also with hard-to-reproduce crashes. IIRC, Tim asked why several functions trigger from timeouts. Dillo is async. and the main driving function for I/O is Cache_process_queue(). This function is not reentrant, thus timeouts/idle calls allow for it to finish before a new action is taken. In general, there're several parts of dillo that need a more formal working definition or API. They've come to be with the implementation and it'd be good to define and document them, and hence not to have to go through all the involved code to find out how to implement something. I'll review the custom-keys patch series next, and try to re-start the work for the 2.1 release. Please test the patch. I've found it works well with the links in: http://git.kernel.org/gitweb.cgi -- Cheers Jorge.-

April 18, 2009

[Patch] add middle_click_closes_tab option fixed

by Christian.Kellermann＠nefkom.net

Skipped content of type multipart/mixed

April 12, 2009

[Patch] add middle_click_closes_tab option

by Christian.Kellermann＠nefkom.net

Sorry for the css.hh patch, this slipped through. If this is a problem I will resend a clean patch. Cheers, Christian

April 12, 2009

[Patch] add middle_click_closes_tab option

by Christian.Kellermann＠nefkom.net

Skipped content of type multipart/mixed

April 12, 2009

Dillo + Partial Javascript Support

by matopoftheworld＠live.co.uk

I've looked into this a little more and what I had originally proposed is not possible for the simple reason that so many of these sites use Javascript for Dynamic HMTL purposes for example displaying login errror messages and the actual login form . It would make sense to try and implement full javascript support. To get Javascript support, Dillo would have to have DOM (Document Object Model) implemented into it. I've had a look at the dpi documentation and from what I can gather is if there was a javascript dpi, Dillo would send a page to a dpi, the dpi does processing and then send the modified page back to Dillo to display. It poses the question whether it put been more efficient to put javascript into a dpi or into Dillo itself? I've had a quick look at the spidermonkey document and I think I know how it works although I'll have to tinker around with the code to get my heard round it Hopefully, I can then have a better picture on what would be required to implement it into Dillo. I just want to say that after looking through some of other document and I'm impressed with the way Dillo is being taken forward especially the documenation which has helped me understand how the program works. _________________________________________________________________ View your Twitter and Flickr updates from one place ? Learn more! http://clk.atdmt.com/UKM/go/137984870/direct/01/

April 11, 2009

[Patch 4/4] Reloading in navigation bar

by tim.nieradzik＠gmx.de

This patch allows reloading by just pressing enter in the navigation bar. --Tim

April 10, 2009

[Patch 3/4] Key bindings

by tim.nieradzik＠gmx.de

This patch adds support for configurable key bindings. --Tim

April 10, 2009

[Patch 2/4] Refactoring src/prefs.c and src/dir.c

by tim.nieradzik＠gmx.de

This patch cleans up src/prefs.c and introduces the PrefsParser (src/prefsparser.cc). Furthermore, src/dir.c is now C++-based as in C this declaration would have been problematic: bool Paths::getPrefs(const char* rcFile, FILE* &fp) --Tim

April 10, 2009

[Patch 1/4] Camel case in src/dillo.cc

by tim.nieradzik＠gmx.de

As I have had some time, I finally split the monolithic patch into four independent ones. However, they must be applied in the correct order. This first patch deals with renaming all method names in src/dillo.cc their camel case notation.

April 10, 2009

Dillo + Partial Javascript Support

by matopoftheworld＠live.co.uk

Justus wrote: There are several free ecmascript interpreters available, choosing one of them and putting it into a dillo plugin is the easy part. But in order to be useful the script needs the ability to manipulate the page content. And designing that part right is hard... ... Thanks Justus, corvid also sent an email. I found another thread about Javascript support in the dillo archives: http://lists.auriga.wearlab.de/pipermail/dillo-dev/2005-March/002614.html As I mentioned, I am not interested in the parts of Javascript that does dynamic HTML but the ones that allow logins which I assume is network based (sorry for lack of knowledge, I had done some basic Javascript a year or two ago). Hopefully this will not require too much change to Dillo as my C skills are a bit rusty and would like to concentrate on something small like a plugin while I get up to speed. I've got some time off work so if I don't get distracted I'll have a look how you could go about it. _________________________________________________________________ View your Twitter and Flickr updates from one place ? Learn more! http://clk.atdmt.com/UKM/go/137984870/direct/01/

April 9, 2009

http authentication: http digest

by Johannes.Hofmann＠gmx.de

On Thu, Apr 09, 2009 at 11:29:14AM +0200, Justus Winter wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hofmann Johannes wrote: > > I've just one minor comment for now: It would be nice if the > > password dialog would show the authentication method used. > > Or can one already see what is going to happen? > You are absolutely right, and this is in fact on my wishlist as well > (grep 'inform the user' src/auth.c). I am going to fix that next week. > Ah nice! Johannes

April 9, 2009

http authentication: http digest

by 4winter＠informatik.uni-hamburg.de

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hofmann Johannes wrote: > I've just one minor comment for now: It would be nice if the > password dialog would show the authentication method used. > Or can one already see what is going to happen? You are absolutely right, and this is in fact on my wishlist as well (grep 'inform the user' src/auth.c). I am going to fix that next week. Justus -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkndv+oACgkQoPmwNWhsaZbJtACgoi7ELkYRm22j+iJE0RNfSvda TMsAnikrxyb4oo4iArMf1kYgoTePpR5c =f6d9 -----END PGP SIGNATURE-----

April 9, 2009

http authentication: http digest

by Johannes.Hofmann＠gmx.de

On Thu, Apr 09, 2009 at 09:59:53AM +0200, Justus Winter wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > corvid wrote: > > Justus wrote: > >> On Wed, Apr 08, 2009 at 03:42:46AM +0000, corvid wrote: > >>> Justus wrote: > >>>> corvid wrote: > >>>>>> * http digest can provide integrity protection for the request body > >>>>>> by computing a hash over the request body, but I have no pointer to > >>>>>> the request body, only the request URL. We might need to pass the > >>>>>> whole request object (is there such a thing?) to the auth code instead > >>>>>> of just the url. The code is there, just the pointer is missing. The > >>>>>> code in auth.c will select the method without integrity protection for > >>>>>> now, hoping that the server will accept both auth and auth-int. > >>> *snip* > > Does URL_DATA(url)->str have what you might expect for POST? > I think you are right. > > >> I think that we should abandon auth-int, as noone else supports it (apache > >> doesn't [0] and neither does mozilla [1]. libneon once supported it, but > >> the code in question was removed in 2005 [2]). > >> > >> I am gonna update my code to reflect that fact. Any more thoughts? > I commented out the code in question (in case anyone wants to implement > it) and left a comment explaining the situation. > > If corvid is right and url->data->str contains all the information we > need this should be trivial to implement. I also located one server side > implementation of http digest auth with auth-int support written in PHP > [0]. I am going to set it up next week and give it a try. > > I published my http digest feature branch at [1] for your (and my) > convenience. If you have access to a site that uses http digest > authentication please give it a try. I'd also appreciate any comments > regarding the inclusion of the bsd licensed md5 implementation. Is that > an acceptable practice? I've just one minor comment for now: It would be nice if the password dialog would show the authentication method used. Or can one already see what is going to happen? Cheers, Johannes

April 9, 2009

http authentication: http digest

by 4winter＠informatik.uni-hamburg.de

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 corvid wrote: > Justus wrote: >> On Wed, Apr 08, 2009 at 03:42:46AM +0000, corvid wrote: >>> Justus wrote: >>>> corvid wrote: >>>>>> * http digest can provide integrity protection for the request body >>>>>> by computing a hash over the request body, but I have no pointer to >>>>>> the request body, only the request URL. We might need to pass the >>>>>> whole request object (is there such a thing?) to the auth code instead >>>>>> of just the url. The code is there, just the pointer is missing. The >>>>>> code in auth.c will select the method without integrity protection for >>>>>> now, hoping that the server will accept both auth and auth-int. >>> *snip* > Does URL_DATA(url)->str have what you might expect for POST? I think you are right. >> I think that we should abandon auth-int, as noone else supports it (apache >> doesn't [0] and neither does mozilla [1]. libneon once supported it, but >> the code in question was removed in 2005 [2]). >> >> I am gonna update my code to reflect that fact. Any more thoughts? I commented out the code in question (in case anyone wants to implement it) and left a comment explaining the situation. If corvid is right and url->data->str contains all the information we need this should be trivial to implement. I also located one server side implementation of http digest auth with auth-int support written in PHP [0]. I am going to set it up next week and give it a try. I published my http digest feature branch at [1] for your (and my) convenience. If you have access to a site that uses http digest authentication please give it a try. I'd also appreciate any comments regarding the inclusion of the bsd licensed md5 implementation. Is that an acceptable practice? Justus 0: http://www.xiven.com/sourcecode/digestauthentication.php 1: http://teythoon.cryptobitch.de/devel/dillo/http-digest -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkndqvgACgkQoPmwNWhsaZYNpQCgtClBdvKwhcIR2gw61K2kUWpj jEIAoJNVBmQtfEKt3WUSNSxqsKYMb++I =rmhj -----END PGP SIGNATURE-----

April 9, 2009

Dillo + Partial Javascript Support

by 4winter＠informatik.uni-hamburg.de

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 alsa F wrote: > Rather than somebody trying to get full Javascript suport for Dillo, I was thinking along the lines of partial Javascript support. The bare minimum would be to access websites that use Javascript to allow logins to forums etc. If any more functionality could be added so that for example social network sites like facebook or bebo then that would be great.On a personal note, I don't mind the lack of CSS when displaying pages on Dillo due to the small screen size of the minibook so any Javascript concerning that is not necessary. There are several free ecmascript interpreters available, choosing one of them and putting it into a dillo plugin is the easy part. But in order to be useful the script needs the ability to manipulate the page content. And designing that part right is hard... Justus -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkndo70ACgkQoPmwNWhsaZYfHgCeIIA+fSBS9AZJTk93OeAUpIiG OIAAn38AnWLOAm1BgrHjKWkLLkexgIvM =USWg -----END PGP SIGNATURE-----

April 9, 2009

http authentication: http digest

by corvid＠lavabit.com

Justus wrote: > On Wed, Apr 08, 2009 at 03:42:46AM +0000, corvid wrote: > > Justus wrote: > > > corvid wrote: > > > >> * http digest can provide integrity protection for the request body > > > >> by computing a hash over the request body, but I have no pointer to > > > >> the request body, only the request URL. We might need to pass the > > > >> whole request object (is there such a thing?) to the auth code instead > > > >> of just the url. The code is there, just the pointer is missing. The > > > >> code in auth.c will select the method without integrity protection for > > > >> now, hoping that the server will accept both auth and auth-int. > > > > > > > > It sounds like entity-body is what you get _after_ dealing with the > > > > transfer coding (chunked) but _before_ dealing with the content > > > > coding (gzip). How annoying. It sounds like it would be necessary to > > > > hack some special field into the cache entry to be used when we see > > > > a WWW-Authenticate header, at least if it was gzipped... > > > Any hints on that one? > > > > The ever-growing CacheEntry_t would need an EntityBody field, and > > in a_Cache_process_dbuf, it would go something like > > if (entry->TransferDecoder) { > > dstr1 = a_Decode_process(entry->TransferDecoder, str, len); > > str = dstr1->str; > > len = dstr1->len; > > } > > if (entry->Auth) > > Dstr_append_l(entry->EntityBody, str, len); > > > > if (entry->ContentDecoder) { > > dstr2 = a_Decode_process(entry->ContentDecoder, str, len); > > str = dstr2->str; > > len = dstr2->len; > > } > > > > And then your code will need to call something like > > a_Cache_get_entity_body(url). > > Maybe I am the one being completly wrong here, but we're talking about the > request body, right? I wouldn't expect to find that that one in the cache... Oh, oh the request... (I don't really know the mechanics of auth at all yet, having felt content to have Jeremy and Justus as the auth experts :) Does URL_DATA(url)->str have what you might expect for POST? > I think that we should abandon auth-int, as noone else supports it (apache > doesn't [0] and neither does mozilla [1]. libneon once supported it, but > the code in question was removed in 2005 [2]). > > I am gonna update my code to reflect that fact. Any more thoughts? > > Justus > > 0: http://httpd.apache.org/docs/2.2/mod/mod_auth_digest.html#authdigestqop > 1: https://bugzilla.mozilla.org/show_bug.cgi?id=168942 > 2: $ grep -A 3 r462 neon27-0.28.2/ChangeLog > r462 | joe | 2005-01-27 22:04:44 +0000 (Thu, 27 Jan 2005) | 7 lines > > * src/ne_auth.c: Drop qop=auth-int support, sice it is universally > unimplemented by servers and comes with too much baggage. (struct

April 8, 2009

CSS @import

by Johannes.Hofmann＠gmx.de

On Sun, Apr 05, 2009 at 04:49:16PM +0000, corvid wrote: > Johannes wrote: > > But first I'd like to fix the cyclic dependency. Maybe we can move > > a_Html_load_stylesheet() from html.cc to some other place? > > Perhaps some code could move to the bw. I've just committed my CSS @import work. It seems to work reliably here. The cyclic dependency is still unsolved. But I came to the conclusion that the whole concept of @import is somewhat cyclic :) Nevertheless I will try to move some code to bw as corvid suggested. Cheers, Johannes PS: Thanks for the reviews, corvid!

April 8, 2009

http authentication: http digest

by 4winter＠informatik.uni-hamburg.de

On Wed, Apr 08, 2009 at 03:42:46AM +0000, corvid wrote: > Justus wrote: > > corvid wrote: > > >> * http digest can provide integrity protection for the request body > > >> by computing a hash over the request body, but I have no pointer to > > >> the request body, only the request URL. We might need to pass the > > >> whole request object (is there such a thing?) to the auth code instead > > >> of just the url. The code is there, just the pointer is missing. The > > >> code in auth.c will select the method without integrity protection for > > >> now, hoping that the server will accept both auth and auth-int. > > > > > > It sounds like entity-body is what you get _after_ dealing with the > > > transfer coding (chunked) but _before_ dealing with the content > > > coding (gzip). How annoying. It sounds like it would be necessary to > > > hack some special field into the cache entry to be used when we see > > > a WWW-Authenticate header, at least if it was gzipped... > > Any hints on that one? > > The ever-growing CacheEntry_t would need an EntityBody field, and > in a_Cache_process_dbuf, it would go something like > if (entry->TransferDecoder) { > dstr1 = a_Decode_process(entry->TransferDecoder, str, len); > str = dstr1->str; > len = dstr1->len; > } > if (entry->Auth) > Dstr_append_l(entry->EntityBody, str, len); > > if (entry->ContentDecoder) { > dstr2 = a_Decode_process(entry->ContentDecoder, str, len); > str = dstr2->str; > len = dstr2->len; > } > > And then your code will need to call something like > a_Cache_get_entity_body(url). Maybe I am the one being completly wrong here, but we're talking about the request body, right? I wouldn't expect to find that that one in the cache... I think that we should abandon auth-int, as noone else supports it (apache doesn't [0] and neither does mozilla [1]. libneon once supported it, but the code in question was removed in 2005 [2]). I am gonna update my code to reflect that fact. Any more thoughts? Justus 0: http://httpd.apache.org/docs/2.2/mod/mod_auth_digest.html#authdigestqop 1: https://bugzilla.mozilla.org/show_bug.cgi?id=168942 2: $ grep -A 3 r462 neon27-0.28.2/ChangeLog r462 | joe | 2005-01-27 22:04:44 +0000 (Thu, 27 Jan 2005) | 7 lines * src/ne_auth.c: Drop qop=auth-int support, sice it is universally unimplemented by servers and comes with too much baggage. (struct

April 8, 2009

http authentication: http digest

by corvid＠lavabit.com

Justus wrote: > corvid wrote: > >> * http digest can provide integrity protection for the request body > >> by computing a hash over the request body, but I have no pointer to > >> the request body, only the request URL. We might need to pass the > >> whole request object (is there such a thing?) to the auth code instead > >> of just the url. The code is there, just the pointer is missing. The > >> code in auth.c will select the method without integrity protection for > >> now, hoping that the server will accept both auth and auth-int. > > > > It sounds like entity-body is what you get _after_ dealing with the > > transfer coding (chunked) but _before_ dealing with the content > > coding (gzip). How annoying. It sounds like it would be necessary to > > hack some special field into the cache entry to be used when we see > > a WWW-Authenticate header, at least if it was gzipped... > Any hints on that one? The ever-growing CacheEntry_t would need an EntityBody field, and in a_Cache_process_dbuf, it would go something like if (entry->TransferDecoder) { dstr1 = a_Decode_process(entry->TransferDecoder, str, len); str = dstr1->str; len = dstr1->len; } if (entry->Auth) Dstr_append_l(entry->EntityBody, str, len); if (entry->ContentDecoder) { dstr2 = a_Decode_process(entry->ContentDecoder, str, len); str = dstr2->str; len = dstr2->len; } And then your code will need to call something like a_Cache_get_entity_body(url). > corvid wrote: > > Oh, also...somewhere in there I noticed that an int was > > being set from a test for equality, with the result assumed > > to be 0 or 1. I might be wrong here, but I think C only > > specifies that you get 0 or nonzero. > Auth_unquote_value contained that assumption which I fixed. Was that the > part in question? Probably. > Any more comments on my patch? Just that I asked the search engine for "digest authentication 'entity-body'" and it gave me a bunch of people wondering what's supposed to happen when the entity-body is empty. So there's a weird test case for you.

April 8, 2009

Dillo + Partial Javascript Support

by matopoftheworld＠live.co.uk

Hi I have a cnm minibook which is part of a little Linux laptop family of mini laptops that use low powered Mipsel processors running Lnux. An unofficial site is here: http://linuxlaptopforum.ark2webdesign.co.uk/index.php One of the users has come up with a Linux distro called 3MX which uses IceWeseal but has also Dillo. The reason for this is because IceWeasel is a bit slow due to the low spec processor. Dillo runs far better than IceWeasel and would be an ideal replacement if it had the functionality of Javascript. Rather than somebody trying to get full Javascript suport for Dillo, I was thinking along the lines of partial Javascript support. The bare minimum would be to access websites that use Javascript to allow logins to forums etc. If any more functionality could be added so that for example social network sites like facebook or bebo then that would be great.On a personal note, I don't mind the lack of CSS when displaying pages on Dillo due to the small screen size of the minibook so any Javascript concerning that is not necessary. It is theoritcally possible as I use the noscript plugin on Firefox on my home PC which blocks javascript from certain 3rd party sites from running. I was wondering if anybody had any thoughts if the above is achievable and if so what would be the best Javascript engine to use with Dillo to achive this? Thanks in advance alsaf. _________________________________________________________________ Share your photos with Windows Live Photos ? Free. http://clk.atdmt.com/UKM/go/134665338/direct/01/

April 7, 2009

http authentication: http digest

by 4winter＠informatik.uni-hamburg.de

Skipped content of type multipart/mixed

April 7, 2009

CSS @import

by Johannes.Hofmann＠gmx.de

On Sun, Apr 05, 2009 at 04:49:16PM +0000, corvid wrote: > Johannes wrote: > > But first I'd like to fix the cyclic dependency. Maybe we can move > > a_Html_load_stylesheet() from html.cc to some other place? > > Perhaps some code could move to the bw. Yes, but maybe it isn't as bad as I initially thought anyway... Attached is an improved version of the patch that avoids looping on recursive @import and resolves relative urls properly. Cheers, Johannes

April 5, 2009

CSS @import

by corvid＠lavabit.com

Johannes wrote: > But first I'd like to fix the cyclic dependency. Maybe we can move > a_Html_load_stylesheet() from html.cc to some other place? Perhaps some code could move to the bw.

April 5, 2009

CSS @import

by Johannes.Hofmann＠gmx.de

On Sat, Apr 04, 2009 at 03:19:06PM +0000, corvid wrote: > Johannes wrote: > > for quite some while I've been trying to add support for the @import > > directive in CSS. The problem is that it creates a cyclic dependency > > between CssParser and DilloHtml: > > CssParser now calls a_Html_load_stylesheet(). > > > > This is extremely ugly and needs to be decoupled somehow. > > > > Anyway, attached is what I currently have - cleanup ideas welcome. > > > > Note, that we also need to use the URL of the current stylesheet to > > resolve relative URLs in @import. This is not implemented yet. > > Good! > > - Is strcat safe here? Argh, no of course not. And I was wondering why dillo was crashing all the time :-) > - strcasecmp -> dStrcasecmp Yes. > - needs a check for prefs.load_stylesheets That should probabely go into a_Html_load_stylesheet(). > - Can we get into loops if an imported stylesheet imports itself > (directly or indirectly) Yes, we need to detect such loops. Should be not too hard. But first I'd like to fix the cyclic dependency. Maybe we can move a_Html_load_stylesheet() from html.cc to some other place? Thanks for having a look! Johannes

April 4, 2009

CSS @import

by corvid＠lavabit.com

Johannes wrote: > for quite some while I've been trying to add support for the @import > directive in CSS. The problem is that it creates a cyclic dependency > between CssParser and DilloHtml: > CssParser now calls a_Html_load_stylesheet(). > > This is extremely ugly and needs to be decoupled somehow. > > Anyway, attached is what I currently have - cleanup ideas welcome. > > Note, that we also need to use the URL of the current stylesheet to > resolve relative URLs in @import. This is not implemented yet. Good! - Is strcat safe here? - strcasecmp -> dStrcasecmp - needs a check for prefs.load_stylesheets - Can we get into loops if an imported stylesheet imports itself (directly or indirectly)

April 4, 2009

CSS @import

by Johannes.Hofmann＠gmx.de

Hi, for quite some while I've been trying to add support for the @import directive in CSS. The problem is that it creates a cyclic dependency between CssParser and DilloHtml: CssParser now calls a_Html_load_stylesheet(). This is extremely ugly and needs to be decoupled somehow. Anyway, attached is what I currently have - cleanup ideas welcome. Note, that we also need to use the URL of the current stylesheet to resolve relative URLs in @import. This is not implemented yet. Cheers, Johannes

April 4, 2009

bugg 903, correcting problems

by corvid＠lavabit.com

Johannes wrote: > On Fri, Apr 03, 2009 at 09:41:00PM +0200, Fredrik Gustafsson wrote: > > Hi, > > after submitting bug 903 I started to work an a solution. (bugg desc. > > added below for your convinience). > > 903 > > Impact: feature fault > > At: run time > > Type: misbehaviour > > Comments: <textarea> doesn't wrap lines (should be an option i dillorc) > > HTReproduce: visit a <textarea> and start typing a really long line > > without any linebreaks > > WorkedBy: nobody > > Submitter: iveqy*iveqy*com > > > > My solution was to add > > text->wrap_mode(true,0); > > on line 678 in dw/fltkui.cc > > > > This worked fine. The line is now wrapped. But after a post, dillo will > > crash (after sending the post, a post sent will be recieved by the > > webbserver before dillo crashes). I can't find where and why dillo > > crash. Does anyone have an id?? > > On deletion we remove the buffer from the fltk:TextEditor class > which seems to cause the crash if wrap_mode is switched on. > Attached patch simply resets wrap_mode on deletion. > It seems to work fine here. Please give it a try. > > Not sure if we want a dillorc option or if we switch this on > generally? What does the spec say and what do other browsers? The spec lets the user agent do as it wishes: cols = number [CN] This attribute specifies the visible width in average character widths. Users should be able to enter longer lines than this, so user agents should provide some means to scroll through the contents of the control when the contents extend beyond the visible area. User agents may wrap visible text lines to keep long lines visible without the need for scrolling.

April 4, 2009

bugg 903, correcting problems

by Johannes.Hofmann＠gmx.de

On Fri, Apr 03, 2009 at 09:41:00PM +0200, Fredrik Gustafsson wrote: > Hi, > after submitting bug 903 I started to work an a solution. (bugg desc. > added below for your convinience). > 903 > Impact: feature fault > At: run time > Type: misbehaviour > Comments: <textarea> doesn't wrap lines (should be an option i dillorc) > HTReproduce: visit a <textarea> and start typing a really long line > without any linebreaks > WorkedBy: nobody > Submitter: iveqy*iveqy*com > > My solution was to add > text->wrap_mode(true,0); > on line 678 in dw/fltkui.cc > > This worked fine. The line is now wrapped. But after a post, dillo will > crash (after sending the post, a post sent will be recieved by the > webbserver before dillo crashes). I can't find where and why dillo > crash. Does anyone have an id?? On deletion we remove the buffer from the fltk:TextEditor class which seems to cause the crash if wrap_mode is switched on. Attached patch simply resets wrap_mode on deletion. It seems to work fine here. Please give it a try. Not sure if we want a dillorc option or if we switch this on generally? What does the spec say and what do other browsers? Cheers and thanks for Your contribution, Johannes > -- > Med v?nliga h?lsningar > Fredrik Gustafsson > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev

April 3, 2009

bugg 903, correcting problems

by iveqy＠iveqy.com

Hi, after submitting bug 903 I started to work an a solution. (bugg desc. added below for your convinience). 903 Impact: feature fault At: run time Type: misbehaviour Comments: <textarea> doesn't wrap lines (should be an option i dillorc) HTReproduce: visit a <textarea> and start typing a really long line without any linebreaks WorkedBy: nobody Submitter: iveqy*iveqy*com My solution was to add text->wrap_mode(true,0); on line 678 in dw/fltkui.cc This worked fine. The line is now wrapped. But after a post, dillo will crash (after sending the post, a post sent will be recieved by the webbserver before dillo crashes). I can't find where and why dillo crash. Does anyone have an id?? -- Med v?nliga h?lsningar Fredrik Gustafsson

April 3, 2009

Warnings in src/IO/dpi.c and lout/misc.hh

by Johannes.Hofmann＠gmx.de

On Wed, Apr 01, 2009 at 11:53:29PM +0200, Michal Nowak wrote: > On Wed, Apr 01, 2009 at 10:16:41PM +0200, Hofmann Johannes wrote: > > On Fri, Mar 27, 2009 at 01:07:14PM +0100, Hofmann Johannes wrote: > > > Hi, > > > > > > On Fri, Mar 27, 2009 at 12:00:46AM +0100, Michal Nowak wrote: > > > > Found this three warnings when compiling with gcc-4.3.2-7.i386: > > > > > > > > gcc -DHAVE_CONFIG_H -I. -I../.. -I/usr/local/include -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i386 -mtune=generic -fasynchronous-unwind-tables -g -O2 -DD_DNS_THREADED -D_REENTRANT -D_THREAD_SAFE -Wall -W -Waggregate-return -MT dpi.o -MD -MP -MF .deps/dpi.Tpo -c -o dpi.o dpi.c > > > > dpi.c: In function ?Dpi_get_dpid_uds_dir?: > > > > dpi.c:382: warning: ignoring return value of ?fgets?, declared with attribute warn_unused_result > > > > dpi.c: In function ?a_Dpi_bye_dpid?: > > > > dpi.c:733: warning: ignoring return value of ?write?, declared with attribute warn_unused_result > > > > > > > > g++ -DHAVE_CONFIG_H -I. -I.. -DDILLORC_SYS='"/usr/local/etc/dillorc"' -I/usr/local/include -I.. -I/usr/include/libpng12 -I/usr/include/freetype2 -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i386 -mtune=generic -fasynchronous-unwind-tables -Wno-non-virtual-dtor -g -O2 -Wall -W -Wno-unused-parameter -fno-rtti -fno-exceptions -MT styleengine.o -MD -MP -MF .deps/styleengine.Tpo -c -o styleengine.o styleengine.cc > > > > ../lout/misc.hh: In member function ?void StyleEngine::apply(dw::core::style::StyleAttrs*, CssPropertyList*)?: > > > > ../lout/misc.hh:181: warning: assuming signed overflow does not occur when assuming that (X - c) > X is always false > > > > > > Can you please check whether attached patches fix the warnings? > > > > Michal, do the patches fix the warnings for you? > > > > Cheers, > > Johannes > > Yes, the mentioned warnings are fixed now, thanks Johannes! Ok, also committed the second part now. Cheers, Johannes

April 2, 2009

http.c:500: warning: unused parameter ???Data2???

by jcid＠dillo.org

On Thu, Apr 02, 2009 at 12:11:27AM +0200, Michal Nowak wrote: > gcc -DHAVE_CONFIG_H -I. -I../.. -I/usr/local/include -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i386 -mtune=generic -fasynchronous-unwind-tables -g -O2 -DD_DNS_THREADED -D_REENTRANT -D_THREAD_SAFE -Wall -W -Waggregate-return -MT http.o -MD -MP -MF .deps/http.Tpo -c -o http.o http.c > http.c: In function ???a_Http_ccc???: > http.c:500: warning: unused parameter ???Data2??? > > gcc-4.3.2-7.i386 > > Emerged in recent days. Yes, it's visible since the addition of the "-W" flag. Data2 is a generic parameter used with CCC that is not used by http.c. No real problem here. -- Cheers Jorge.-

April 2, 2009

[PATCH] startup window

by jcid＠dillo.org

On Wed, Apr 01, 2009 at 08:11:32PM +0200, Hofmann Johannes wrote: > On Wed, Apr 01, 2009 at 04:49:44PM +0000, corvid wrote: > > Thomas wrote: > > > Am Wed, 1 Apr 2009 09:47:11 +0200 > > > schrieb Hofmann Johannes <Johannes.Hofmann(a)gmx.de>: > > > > > > > Hi, > > > > attached patch adds a proper startup screen for dillo. > > > > > > Oh, is dillo slow enough now that it needs a splash screen distracting the user while waiting for startup? > > > I sort of like the "instant startup" behaviour. A splash startup screen reminds you of the startup _not_ being instant. > > > Especially opening an extra window wastes CPU cycles, even in X11, that could be used on doing the actual work... > > > Of course I'll have to check out a current dillo2 to see how eminent the issue really is. But when we reach the startup speed of e.g. the GIMP with it's endless loading of plugins etc., one can safely declare dillo "just another bloated browser". > > > I don't want to be offensive, just voice my concern... > > > > I agree with Thomas here. > > > > me too - check the date :) Good one! I should have suggested using Gecko... :-) -- Cheers Jorge.-

April 2, 2009

[PATCH] startup window

by jcid＠dillo.org

On Wed, Apr 01, 2009 at 04:49:44PM +0000, corvid wrote: > Thomas wrote: > > Am Wed, 1 Apr 2009 09:47:11 +0200 > > schrieb Hofmann Johannes <Johannes.Hofmann(a)gmx.de>: > > > > > Hi, > > > attached patch adds a proper startup screen for dillo. > > > > Oh, is dillo slow enough now that it needs a splash screen distracting the user while waiting for startup? > > I sort of like the "instant startup" behaviour. A splash startup screen reminds you of the startup _not_ being instant. > > Especially opening an extra window wastes CPU cycles, even in X11, that could be used on doing the actual work... > > Of course I'll have to check out a current dillo2 to see how eminent the issue really is. But when we reach the startup speed of e.g. the GIMP with it's endless loading of plugins etc., one can safely declare dillo "just another bloated browser". > > I don't want to be offensive, just voice my concern... > > I agree with Thomas here. Me too. -- Cheers Jorge.-

April 2, 2009

Segfault on sites requiring authentication

by corvid＠lavabit.com

Tim wrote: > It is curious that we > loop two times over ClientQueue though. Probably because the > function is called every x received bytes, right? a_Cache_process_dbuf calls Cache_process_queue once for each packet and once when it's done (IOClose). > Looking for http://puppyisos.org/miniicons/kfm_home.png... > Looking for http://puppyisos.org/miniicons/ark.png... > Found (id=1). > HTTP warning: unhandled MIME type: "text/html; charset=iso-8859-1" > Looping over ClientQueue... > Looking for http://puppyisos.org/miniicons/kfm_home.png... > Looking for http://puppyisos.org/miniicons/ark.png... > Found (id=1). > Removing client (id=1) > > We should add support for charsets within MIME types anytime. As far > as I know, Dillo only depends on meta-tags when deciding which > encoding to go with. This notation is officially approved, see: > http://www.w3.org/International/tutorials/tutorial-char-enc/#Slide0270 Charsets in MIME types are supported. It's probably complaining because it expected an image/png and got the text/html; charset=iso-8859-1 401 Auth page which can't be displayed as an image. > PS: Having applied the patch, the iterations of the ClientQueue loop > will now stop after the URL has matched. Previously, the iteration > for the same entry item was then repeated again (if AbortEntry is > true). Is there a reason for keeping it as-is? In case multiple clients were waiting for this data. Now I _am_ getting the crash. Maybe I accidentally typed in the main page instead. Don't think I did, but...whatever...anyway... in Cache_auth_callback(), a_Nav_reload(data->bw) does not sound at all like what we want for images on a page. We'd want something more along the lines of Cache_entry_remove() on the image and a_Nav_repush() on the page, but I think in either case that would remove clients for other images while we're trying to get their data, causing...what we're seeing. (Is dillo turning into a snarled knot?) If the last image comes in while there's no client, I wouldn't know what bw to repush.

April 2, 2009

Segfault on sites requiring authentication

by tim.nieradzik＠gmx.de

> It would be good to find out what it's doing exactly for you. > - I'd expect a client to be waiting for it in this case. The client does not exist anymore because it has been destroyed too early. That is why I removed the timer in the previous patch. Debugging asynchronous code is difficult. I compiled Dillo with debugging symbols and added some printf()'s to see what is going on in detail. Afterwards I ran the binary through gdb. When visiting http://puppyisos.org/isos, everything looks alright in the beginning. The dialog pops up as expected. It is curious that we loop two times over ClientQueue though. Probably because the function is called every x received bytes, right? [New Thread 0xf760bb90 (LWP 14474)] [Thread 0xf760bb90 (LWP 14474) exited] Looping over ClientQueue... Looking for http://puppyisos.org/isos... Found (id=0). Looping over ClientQueue... Looking for http://puppyisos.org/isos... Found (id=0). Removing client (id=0) It seems that after confirming the authentication dialog, the page is being reloaded but without the header that is necessary for the HTTP authentication... Reloading page with authentication credentials... Looping over ClientQueue... Looking for http://puppyisos.org/isos... Found (id=0). Looping over ClientQueue... Looking for http://puppyisos.org/isos... Found (id=0). Removing client (id=0) At least this would explain, why the client for http://puppyisos.org/isos was deleted. Now the page is reloaded again because suddenly there is a client for http://puppyisos.org/isos/ again (with id=0): Looping over ClientQueue... Looking for http://puppyisos.org/isos/... Found (id=0). Looping over ClientQueue... Looking for http://puppyisos.org/isos/... Found (id=0). Looping over ClientQueue... Looking for http://puppyisos.org/isos/... Found (id=0). Looping over ClientQueue... Looking for http://puppyisos.org/isos/... Found (id=0). Looping over ClientQueue... Looking for http://puppyisos.org/isos/... Found (id=0). Removing client (id=0) Looping over ClientQueue... Looking for http://puppyisos.org/miniicons/kfm_home.png... Looking for http://puppyisos.org/miniicons/ark.png... Found (id=1). HTTP warning: unhandled MIME type: "text/html; charset=iso-8859-1" Looping over ClientQueue... Looking for http://puppyisos.org/miniicons/kfm_home.png... Looking for http://puppyisos.org/miniicons/ark.png... Found (id=1). Removing client (id=1) We should add support for charsets within MIME types anytime. As far as I know, Dillo only depends on meta-tags when deciding which encoding to go with. This notation is officially approved, see: http://www.w3.org/International/tutorials/tutorial-char-enc/#Slide0270 Reloading page with authentication credentials... Looping over ClientQueue... Looking for http://puppyisos.org/isos/... Not found! Looping over ClientQueue... Looking for http://puppyisos.org/isos/... Not found! Looping over ClientQueue... Looking for http://puppyisos.org/isos/... Not found! Looping over ClientQueue... Looking for http://puppyisos.org/isos/... Not found! Looping over ClientQueue... Looking for http://puppyisos.org/isos/... Not found! Looping over ClientQueue... Looking for http://puppyisos.org/isos/... Not found! Reloading page with authentication credentials... Why was the site reloaded again? Interestingly, no new client has been created for /isos this time. I am a bit astonished how often Cache_auth_callback() is called even though the dialog only appears once. Everything looks a bit asynchronous. An evidence might be the following lines: Looking for http://puppyisos.org/miniicons/kfm_home.png... Looking for http://puppyisos.org/miniicons/ark.png... In general, there should be a "Found (id=...)." or at least a "Not found!'" but they just follow after each other. And now it crashes: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0xf79bf6d0 (LWP 14340)] 0x0805ba14 in a_Nav_cancel_expect (bw=0x0) at nav.c:250 250 if (bw->nav_expecting) { Here is the back trace: (gdb) bt #0 0x0805ba14 in a_Nav_cancel_expect (bw=0x0) at nav.c:250 #1 0x0805c098 in a_Nav_reload (bw=0x0) at nav.c:474 #2 0x0805dd4e in Cache_auth_callback (vdata=0x8252208) at cache.c:971 #3 0xf7f23e75 in fltk::wait () from /usr/lib/libfltk2.so #4 0xf7f23f88 in fltk::run () from /usr/lib/libfltk2.so #5 0x0804f686 in main (argc=1, argv=0xffdf7b74) at dillo.cc:333 > - I think a client shouldn't ever have a NULL bw. I agree. > - The case where there are no clients waiting for the URL > does sound like a bug, although I think I'd be tempted > just not to call Cache_auth_entry() if the bw was NULL. Unfortunately, that did not really help. Well, Dillo does not crash anymore but no images on this page are shown and it reloads several times before anything gets displayed. > Reloading doesn't crash it for me. > Yes, I'm using the latest code. In contrast to /isos, the main page (http://puppyisos.org/) is working alright here. No crashes, all images are displayed properly. There are some other directory listings on that site which are working, too even though there syntax is quite similar to /isos'. > You mentioned the other day that you get a lot of crashes in general, > and I was surprised because I've had a total of three random crashes > since 2.0 was released. The situation has improved since I am browsing with the latest trunk. Nevertheless, I still experience non-reproducible crashes sometimes: It happens frequently that dpid ``crashes'' (100% CPU consumption). This happens mostly when domain names cannot be resolved correctly. Trying to reload the page does not solve it. I have to kill the process manually. PS: Having applied the patch, the iterations of the ClientQueue loop will now stop after the URL has matched. Previously, the iteration for the same entry item was then repeated again (if AbortEntry is true). Is there a reason for keeping it as-is? --Tim

April 2, 2009

http.c:500: warning: unused parameter ‘Data2’

by newman.x＠gmail.com

gcc -DHAVE_CONFIG_H -I. -I../.. -I/usr/local/include -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i386 -mtune=generic -fasynchronous-unwind-tables -g -O2 -DD_DNS_THREADED -D_REENTRANT -D_THREAD_SAFE -Wall -W -Waggregate-return -MT http.o -MD -MP -MF .deps/http.Tpo -c -o http.o http.c http.c: In function ?a_Http_ccc?: http.c:500: warning: unused parameter ?Data2? gcc-4.3.2-7.i386 Emerged in recent days. -- Regards, Michal Nowak

April 2, 2009

Warnings in src/IO/dpi.c and lout/misc.hh

by newman.x＠gmail.com

On Wed, Apr 01, 2009 at 10:16:41PM +0200, Hofmann Johannes wrote: > On Fri, Mar 27, 2009 at 01:07:14PM +0100, Hofmann Johannes wrote: > > Hi, > > > > On Fri, Mar 27, 2009 at 12:00:46AM +0100, Michal Nowak wrote: > > > Found this three warnings when compiling with gcc-4.3.2-7.i386: > > > > > > gcc -DHAVE_CONFIG_H -I. -I../.. -I/usr/local/include -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i386 -mtune=generic -fasynchronous-unwind-tables -g -O2 -DD_DNS_THREADED -D_REENTRANT -D_THREAD_SAFE -Wall -W -Waggregate-return -MT dpi.o -MD -MP -MF .deps/dpi.Tpo -c -o dpi.o dpi.c > > > dpi.c: In function ?Dpi_get_dpid_uds_dir?: > > > dpi.c:382: warning: ignoring return value of ?fgets?, declared with attribute warn_unused_result > > > dpi.c: In function ?a_Dpi_bye_dpid?: > > > dpi.c:733: warning: ignoring return value of ?write?, declared with attribute warn_unused_result > > > > > > g++ -DHAVE_CONFIG_H -I. -I.. -DDILLORC_SYS='"/usr/local/etc/dillorc"' -I/usr/local/include -I.. -I/usr/include/libpng12 -I/usr/include/freetype2 -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i386 -mtune=generic -fasynchronous-unwind-tables -Wno-non-virtual-dtor -g -O2 -Wall -W -Wno-unused-parameter -fno-rtti -fno-exceptions -MT styleengine.o -MD -MP -MF .deps/styleengine.Tpo -c -o styleengine.o styleengine.cc > > > ../lout/misc.hh: In member function ?void StyleEngine::apply(dw::core::style::StyleAttrs*, CssPropertyList*)?: > > > ../lout/misc.hh:181: warning: assuming signed overflow does not occur when assuming that (X - c) > X is always false > > > > Can you please check whether attached patches fix the warnings? > > Michal, do the patches fix the warnings for you? > > Cheers, > Johannes Yes, the mentioned warnings are fixed now, thanks Johannes! But one more emerged due to recent clean up, see follow-up email. Michal > > > > > @all: please have a look at the dpi.c fix. > > > > Cheers, > > Johannes > > > diff -r b06377790b00 src/IO/dpi.c > > --- a/src/IO/dpi.c Thu Mar 26 23:18:02 2009 +0000 > > +++ b/src/IO/dpi.c Fri Mar 27 13:05:11 2009 +0100 > > @@ -371,7 +371,7 @@ static char *Dpi_get_dpid_uds_dir(void) > > { > > FILE *in; > > char *saved_name_filename; /* :) */ > > - char dpid_uds_dir[256], *p = NULL; > > + char buf[256], *dpid_uds_dir, *p = NULL, *p1; > > > > saved_name_filename = > > dStrconcat(dGethomedir(), "/.dillo/dpi_socket_dir", NULL); > > @@ -379,14 +379,16 @@ static char *Dpi_get_dpid_uds_dir(void) > > dFree(saved_name_filename); > > > > if (in != NULL) { > > - fgets(dpid_uds_dir, 256, in); > > + dpid_uds_dir = fgets(buf, sizeof(buf), in); > > fclose(in); > > - if ((p = strchr(dpid_uds_dir, '\n'))) { > > - *p = 0; > > - } > > - if (access(dpid_uds_dir, F_OK) == 0) { > > - p = dStrdup(dpid_uds_dir); > > - _MSG("Dpi_get_dpid_uds_dir:: %s\n", p); > > + if (dpid_uds_dir) { > > + if ((p1 = strchr(dpid_uds_dir, '\n'))) { > > + *p1 = 0; > > + } > > + if (access(dpid_uds_dir, F_OK) == 0) { > > + p = dStrdup(dpid_uds_dir); > > + _MSG("Dpi_get_dpid_uds_dir:: %s\n", p); > > + } > > } > > } > > > > @@ -730,7 +732,9 @@ void a_Dpi_bye_dpid() > > MSG("%s\n", sa.sun_path); > > } > > DpiBye_cmd = a_Dpip_build_cmd("cmd=%s", "DpiBye"); > > - (void) write(new_socket, DpiBye_cmd, strlen(DpiBye_cmd)); > > + if (write(new_socket, DpiBye_cmd, strlen(DpiBye_cmd)) != > > + (ssize_t) strlen(DpiBye_cmd)) > > + MSG_WARN("Failed to send DpiBye\n"); > > dFree(DpiBye_cmd); > > Dpi_close_fd(new_socket); > > } > > > diff -r b06377790b00 lout/misc.hh > > --- a/lout/misc.hh Thu Mar 26 23:18:02 2009 +0000 > > +++ b/lout/misc.hh Fri Mar 27 12:52:36 2009 +0100 > > @@ -178,7 +178,7 @@ public: > > */ > > inline T get (int i) { > > if (BOUND_CHECKING) > > - assert (i >= 0 && i < this->num); > > + assert (i >= 0 && this->num - i > 0); > > return this->array[i]; > > } > > > > @@ -192,7 +192,7 @@ public: > > */ > > inline void set (int i, T t) { > > if (BOUND_CHECKING) > > - assert (i >= 0 && i < this->num); > > + assert (i >= 0 && this->num - i > 0); > > this->array[i] = t; > > } > > }; > > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev -- Regards, Michal Nowak

April 1, 2009

Warnings in src/IO/dpi.c and lout/misc.hh

by Johannes.Hofmann＠gmx.de

On Fri, Mar 27, 2009 at 01:07:14PM +0100, Hofmann Johannes wrote: > Hi, > > On Fri, Mar 27, 2009 at 12:00:46AM +0100, Michal Nowak wrote: > > Found this three warnings when compiling with gcc-4.3.2-7.i386: > > > > gcc -DHAVE_CONFIG_H -I. -I../.. -I/usr/local/include -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i386 -mtune=generic -fasynchronous-unwind-tables -g -O2 -DD_DNS_THREADED -D_REENTRANT -D_THREAD_SAFE -Wall -W -Waggregate-return -MT dpi.o -MD -MP -MF .deps/dpi.Tpo -c -o dpi.o dpi.c > > dpi.c: In function ?Dpi_get_dpid_uds_dir?: > > dpi.c:382: warning: ignoring return value of ?fgets?, declared with attribute warn_unused_result > > dpi.c: In function ?a_Dpi_bye_dpid?: > > dpi.c:733: warning: ignoring return value of ?write?, declared with attribute warn_unused_result > > > > g++ -DHAVE_CONFIG_H -I. -I.. -DDILLORC_SYS='"/usr/local/etc/dillorc"' -I/usr/local/include -I.. -I/usr/include/libpng12 -I/usr/include/freetype2 -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i386 -mtune=generic -fasynchronous-unwind-tables -Wno-non-virtual-dtor -g -O2 -Wall -W -Wno-unused-parameter -fno-rtti -fno-exceptions -MT styleengine.o -MD -MP -MF .deps/styleengine.Tpo -c -o styleengine.o styleengine.cc > > ../lout/misc.hh: In member function ?void StyleEngine::apply(dw::core::style::StyleAttrs*, CssPropertyList*)?: > > ../lout/misc.hh:181: warning: assuming signed overflow does not occur when assuming that (X - c) > X is always false > > Can you please check whether attached patches fix the warnings? Michal, do the patches fix the warnings for you? Cheers, Johannes > > @all: please have a look at the dpi.c fix. > > Cheers, > Johannes > diff -r b06377790b00 src/IO/dpi.c > --- a/src/IO/dpi.c Thu Mar 26 23:18:02 2009 +0000 > +++ b/src/IO/dpi.c Fri Mar 27 13:05:11 2009 +0100 > @@ -371,7 +371,7 @@ static char *Dpi_get_dpid_uds_dir(void) > { > FILE *in; > char *saved_name_filename; /* :) */ > - char dpid_uds_dir[256], *p = NULL; > + char buf[256], *dpid_uds_dir, *p = NULL, *p1; > > saved_name_filename = > dStrconcat(dGethomedir(), "/.dillo/dpi_socket_dir", NULL); > @@ -379,14 +379,16 @@ static char *Dpi_get_dpid_uds_dir(void) > dFree(saved_name_filename); > > if (in != NULL) { > - fgets(dpid_uds_dir, 256, in); > + dpid_uds_dir = fgets(buf, sizeof(buf), in); > fclose(in); > - if ((p = strchr(dpid_uds_dir, '\n'))) { > - *p = 0; > - } > - if (access(dpid_uds_dir, F_OK) == 0) { > - p = dStrdup(dpid_uds_dir); > - _MSG("Dpi_get_dpid_uds_dir:: %s\n", p); > + if (dpid_uds_dir) { > + if ((p1 = strchr(dpid_uds_dir, '\n'))) { > + *p1 = 0; > + } > + if (access(dpid_uds_dir, F_OK) == 0) { > + p = dStrdup(dpid_uds_dir); > + _MSG("Dpi_get_dpid_uds_dir:: %s\n", p); > + } > } > } > > @@ -730,7 +732,9 @@ void a_Dpi_bye_dpid() > MSG("%s\n", sa.sun_path); > } > DpiBye_cmd = a_Dpip_build_cmd("cmd=%s", "DpiBye"); > - (void) write(new_socket, DpiBye_cmd, strlen(DpiBye_cmd)); > + if (write(new_socket, DpiBye_cmd, strlen(DpiBye_cmd)) != > + (ssize_t) strlen(DpiBye_cmd)) > + MSG_WARN("Failed to send DpiBye\n"); > dFree(DpiBye_cmd); > Dpi_close_fd(new_socket); > } > diff -r b06377790b00 lout/misc.hh > --- a/lout/misc.hh Thu Mar 26 23:18:02 2009 +0000 > +++ b/lout/misc.hh Fri Mar 27 12:52:36 2009 +0100 > @@ -178,7 +178,7 @@ public: > */ > inline T get (int i) { > if (BOUND_CHECKING) > - assert (i >= 0 && i < this->num); > + assert (i >= 0 && this->num - i > 0); > return this->array[i]; > } > > @@ -192,7 +192,7 @@ public: > */ > inline void set (int i, T t) { > if (BOUND_CHECKING) > - assert (i >= 0 && i < this->num); > + assert (i >= 0 && this->num - i > 0); > this->array[i] = t; > } > };

April 1, 2009

Segfault on sites requiring authentication

by corvid＠lavabit.com

Tim wrote: > > I'm not seeing this crash. Is it going through the for loop and > > getting set to NULL in Client_bw = ClientWeb->bw;, or is it > > NULL because there weren't any clients and it didn't execute that code? > > Yes, it is going through the loop. Probably comparing Client->Url > with entry->Url fails. As a result, ClientWeb and Client_bw do not > get set. It would be good to find out what it's doing exactly for you. - I'd expect a client to be waiting for it in this case. - I think a client shouldn't ever have a NULL bw. - The case where there are no clients waiting for the URL does sound like a bug, although I think I'd be tempted just not to call Cache_auth_entry() if the bw was NULL. > Have you also tried reloading the page? Sometimes it does not get > loaded properly here. Anyway, it is odd that Dillo does not crash > for you. Are you using the latest trunk? Reloading doesn't crash it for me. Yes, I'm using the latest code. You mentioned the other day that you get a lot of crashes in general, and I was surprised because I've had a total of three random crashes since 2.0 was released.

April 1, 2009

[PATCH] startup window

by tim.nieradzik＠gmx.de

Heh, that is what I had in mind all the time. However, nice idea for an April Fool's hoax. :) --Tim

April 1, 2009

Segfault on sites requiring authentication

by tim.nieradzik＠gmx.de

> I'm not seeing this crash. Is it going through the for loop and > getting set to NULL in Client_bw = ClientWeb->bw;, or is it > NULL because there weren't any clients and it didn't execute that code? Yes, it is going through the loop. Probably comparing Client->Url with entry->Url fails. As a result, ClientWeb and Client_bw do not get set. Have you also tried reloading the page? Sometimes it does not get loaded properly here. Anyway, it is odd that Dillo does not crash for you. Are you using the latest trunk? --Tim

April 1, 2009

[PATCH] startup window

by Johannes.Hofmann＠gmx.de

On Wed, Apr 01, 2009 at 04:49:44PM +0000, corvid wrote: > Thomas wrote: > > Am Wed, 1 Apr 2009 09:47:11 +0200 > > schrieb Hofmann Johannes <Johannes.Hofmann(a)gmx.de>: > > > > > Hi, > > > attached patch adds a proper startup screen for dillo. > > > > Oh, is dillo slow enough now that it needs a splash screen distracting the user while waiting for startup? > > I sort of like the "instant startup" behaviour. A splash startup screen reminds you of the startup _not_ being instant. > > Especially opening an extra window wastes CPU cycles, even in X11, that could be used on doing the actual work... > > Of course I'll have to check out a current dillo2 to see how eminent the issue really is. But when we reach the startup speed of e.g. the GIMP with it's endless loading of plugins etc., one can safely declare dillo "just another bloated browser". > > I don't want to be offensive, just voice my concern... > > I agree with Thomas here. > me too - check the date :)

April 1, 2009

[PATCH] startup window

by corvid＠lavabit.com

Thomas wrote: > Am Wed, 1 Apr 2009 09:47:11 +0200 > schrieb Hofmann Johannes <Johannes.Hofmann(a)gmx.de>: > > > Hi, > > attached patch adds a proper startup screen for dillo. > > Oh, is dillo slow enough now that it needs a splash screen distracting the user while waiting for startup? > I sort of like the "instant startup" behaviour. A splash startup screen reminds you of the startup _not_ being instant. > Especially opening an extra window wastes CPU cycles, even in X11, that could be used on doing the actual work... > Of course I'll have to check out a current dillo2 to see how eminent the issue really is. But when we reach the startup speed of e.g. the GIMP with it's endless loading of plugins etc., one can safely declare dillo "just another bloated browser". > I don't want to be offensive, just voice my concern... I agree with Thomas here.

April 1, 2009

Segfault on sites requiring authentication

by corvid＠lavabit.com

Tim wrote: > Whenever I visit http://puppyisos.org/isos (puppy / linux), Dillo > segfaults. The reason is that in some cases the variable Client_bw > is NULL. However, some functions depend on it and access its member > variables. > > Client_bw is initialized in Cache_process_queue() (src/cache.c). > When authentication is required, this variable is passed over to > Cache_auth_entry() which sets a timeout. Its callback > (Cache_auth_callback()) opens up a dialog asking for the credentials > and then calls a_Nav_reload() with the Client_bw as its first > parameter. Finally in a_Nav_cancel_expect() Client_bw's member > variable nav_expecting is used and as bw is NULL, Dillo segfaults. I'm not seeing this crash. Is it going through the for loop and getting set to NULL in Client_bw = ClientWeb->bw;, or is it NULL because there weren't any clients and it didn't execute that code? > I came up with a small patch that removes Cache_auth_callback() and > Cache_auth_entry() as I have not seen any advantages in delaying the > authentication popup. The next thing I did was to show the dialog on > condition that Client_bw is not NULL and that we have finished the > transfer (At least I hope CA_Close is the proper flag for doing so). > > There were various unnecessary checks in src/nav.c. They compared bw > with NULL. In my opinion the affected functions (a_Nav_expect_done, > a_Nav_push and a_Nav_repush) should never be called if you cannot be > sure that bw is not NUL. What is your view on this subject? > > Unfortunately, my approach does not solve the original problem that > caused Client_bw being NULL. Furthermore, the patch introduces a new > bug: The dialog pops up when reloading the site but after having > entered the correct credentials or having pressed the ``Cancel'' > button, it appears again. Any ideas? > > While digging deeper into the code, I noticed that we make heavy use > of timers for popups and reloading pages? Is there any special > reason for it? If the calling code needs to go back to whatever it was doing rather than waiting around for the user to interact with a popup, a timer is used.

April 1, 2009

[PATCH] startup window

by thomas-forum＠orgis.org

Am Wed, 1 Apr 2009 09:47:11 +0200 schrieb Hofmann Johannes <Johannes.Hofmann(a)gmx.de>: > Hi, > attached patch adds a proper startup screen for dillo. Oh, is dillo slow enough now that it needs a splash screen distracting the user while waiting for startup? I sort of like the "instant startup" behaviour. A splash startup screen reminds you of the startup _not_ being instant. Especially opening an extra window wastes CPU cycles, even in X11, that could be used on doing the actual work... Of course I'll have to check out a current dillo2 to see how eminent the issue really is. But when we reach the startup speed of e.g. the GIMP with it's endless loading of plugins etc., one can safely declare dillo "just another bloated browser". I don't want to be offensive, just voice my concern... Alrighty then, Thomas.

April 1, 2009

[PATCH] startup window

by Johannes.Hofmann＠gmx.de

Hi, attached patch adds a proper startup screen for dillo. Cheers, Johannes

April 1, 2009